• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Why can't audio industry standardize on a common digital audio "hdmi"?

escksu

Addicted to Fun and Learning
Joined
Jul 16, 2020
Messages
965
Likes
397
One main issue with HDMI today is noise and jitter. HDMI works fine for AVR but when you want the best possible quality for 2 channels, HDMI won't be able to do that.
 

escksu

Addicted to Fun and Learning
Joined
Jul 16, 2020
Messages
965
Likes
397

https://www.audiosciencereview.com/...s/a-deep-dive-into-hdmi-audio-performance.56/

Noise is an issue....HDMI works fine for mainstream AVR, but its not any better than exisitng coaxial or SPDIF interface. Its better for multi-channel audio when its bandwidth is clearly higher than other interface. But for 2 channels, bandwidth is not the issue.

USB has its own problems too. What I considered best? It would be TCP/IP over fiber or RJ45. I believe it will be the future esp. wireless. Streaming to amp.
 
Last edited:

mansr

Major Contributor
Joined
Oct 5, 2018
Messages
4,685
Likes
10,700
Location
Hampshire
Maybe some HDMI receivers are noisy, but this doesn't have to be so. Nothing in the spec precludes making a low-noise implementation.

When it comes to jitter, it is true that some receivers are relatively poor. Again, however, it is possible to make a good one. Of course, HDMI is source-driven just like S/PDIF, which means the receiver needs to lock its clock to that of the transmitter. Due to the way audio is transmitted between lines video, this process is a little more involved than with a simple signal like S/PDIF. It gets especially tricky if the sample rate doesn't divide nicely with the line rate of the selected video mode. That still doesn't mean it can't be done well. Don't damn an interface just because poor implementations exist.
 

escksu

Addicted to Fun and Learning
Joined
Jul 16, 2020
Messages
965
Likes
397
Maybe some HDMI receivers are noisy, but this doesn't have to be so. Nothing in the spec precludes making a low-noise implementation.

When it comes to jitter, it is true that some receivers are relatively poor. Again, however, it is possible to make a good one. Of course, HDMI is source-driven just like S/PDIF, which means the receiver needs to lock its clock to that of the transmitter. Due to the way audio is transmitted between lines video, this process is a little more involved than with a simple signal like S/PDIF. It gets especially tricky if the sample rate doesn't divide nicely with the line rate of the selected video mode. That still doesn't mean it can't be done well. Don't damn an interface just because poor implementations exist.

I do agree with you that it can be done well (the ML DAC performs very well). However, its going to be very expensive due to the additional circuitry needed. One main benefit of existing SPDIF/Coax is that technology is very mature. So, its alot easier and cheaper to resolve noise/jitter issues. And then there is analog outputs which is free from all these issues. High quality interconnects are mostly shielded, so interference is less of an issue. If not, XLR does very well to reject interference as well. Lastly, you also need to pay license fees for HDMI.
 

Atanasi

Addicted to Fun and Learning
Forum Donor
Joined
Jan 8, 2019
Messages
713
Likes
792
USB has its own problems too. What I considered best? It would be TCP/IP over fiber or RJ45. I believe it will be the future esp. wireless. Streaming to amp.
Ethernet has the benefit of a long range and galvanic isolation. However, RJ45 is not a good connector, cables break easily.
TCP/IP would not even be necessary for local connections. That would not be compatible with existing software, though.
 

escksu

Addicted to Fun and Learning
Joined
Jul 16, 2020
Messages
965
Likes
397
Ethernet has the benefit of a long range and galvanic isolation. However, RJ45 is not a good connector, cables break easily.
TCP/IP would not even be necessary for local connections. That would not be compatible with existing software, though.

The main reason why I prefer TCP/IP is that it is a reliable protocol. This means the data received is not susceptible to jitter/noise/interference etc... Because there is a checksum to prevent data corruption. So, this means that whats receive will be exactly the same as what is sent. Since TCP/IP works for wireless, we dont even need cables to transmit data. ITs also not limited to network cables. We can use optical fibre as well. Even HDMI can be used for data transmission. Some switches uses HDMI cable to link up the switches (stacking).

UDP is good but because it does not re-request for packets that is corrupted, its not so good for audio.

Although its not compatible with existing software, its very easy to "convert" the packets into data that can be used by the device. The best thing is since all these is done within the device, its alot easier to control noise/jitter etc....
 

Atanasi

Addicted to Fun and Learning
Forum Donor
Joined
Jan 8, 2019
Messages
713
Likes
792
UDP is good but because it does not re-request for packets that is corrupted, its not so good for audio
Real-time audio cannot retransmit. If a packet is gone, it's gone. Redundant transmission is possible in order to tolerate some errors.
 
OP
Vasr

Vasr

Major Contributor
Joined
Jun 27, 2020
Messages
1,409
Likes
1,922
The main reason why I prefer TCP/IP is that it is a reliable protocol. This means the data received is not susceptible to jitter/noise/interference etc... Because there is a checksum to prevent data corruption. So, this means that whats receive will be exactly the same as what is sent. Since TCP/IP works for wireless, we dont even need cables to transmit data. ITs also not limited to network cables. We can use optical fibre as well. Even HDMI can be used for data transmission. Some switches uses HDMI cable to link up the switches (stacking).

UDP is good but because it does not re-request for packets that is corrupted, its not so good for audio.

Although its not compatible with existing software, its very easy to "convert" the packets into data that can be used by the device. The best thing is since all these is done within the device, its alot easier to control noise/jitter etc....

I think you, like a poster earlier, are mixing up two different types of "audio transmission".

One, there is the high-level streaming model in which an encoded audio/video file is streamed from a content acquisition device to a network-connected "black-box" audio/video rendering device (that takes care of decoding and processing internally requiring no cables or using current mix of interconnects when necessary). These are typically called networked processors/amps. They can use pretty much any network protocol and do it wireless. But given IP networks are the easiest and most prevalent wired or wireless, that is what it has already converged to. There is typically sufficient buffering at the application level to not be affected much by underlying network delays or re-transmissions (within reason) or clock sync issues. These aren't competing with S/PDIF or HDMI for such applications.

Two, there are interconnects within the processing of the audio chain. Here you have to separate short-haul interconnect requirements (within an audio/video stack of equipment) and long-haul requirements (zone distribution, large theaters, etc. HDMI, TosLink, etc., have advantages (but not issue-free) for the former - direct point-point interconnects, zero config, no QoS requirements, no thick protocol stacks, etc. Networked protocols have advantages for the latter to reduce wiring clutter, have higher redundancy, etc.

All of the second type are under strict real-time audio constraints with virtually little or no buffering at the "application-level" for these transmissions. All delays, clock sync, protocol decoding, etc., are done with transceiver cards as part of the underlying protocol. This is where direct interconnects makes more sense than thick protocol stacks at either end for short-haul interconnects where the advantages of the latter aren't as much of a need.

USB is kind of weird in that it has been used for both of the above applications (as USB audio for the second type and as simple data transmission for the first type) but it wasn't really designed for either as a peer-peer inter-connect in particular - and hence the host/controller dichotomy, etc.

Kind of pushing one technology as a solution to all the different application is more ideological and hammer-and-nail situation than the best technical solution. So, context of what is required matters.

The digital interconnects are not as obvious as analog interconnects to many because they might have all the digital processing inside a single box. But when you start experimenting with and get experience with using separate boxes (for SOTA in each function), you start to realize the mess of inter-connection requirements and why the big seriously compromised all-in-one boxes are getting a virtual monopoly in deployment in consumer markets.

The solution to breaking up this processing into separates (in the digital domain) is not pushing connection technology that requires network geeks or some technical configuration for QoS or discovery or whatever. Just plug in a cable at both ends and you are done. If you have a universal connector for this purpose to replace the mess of inter-connect types available all the better for both consumers and manufacturers.

That was the motivation for this thread.
 

patate91

Active Member
Joined
Apr 14, 2019
Messages
253
Likes
137
4. Have latency guarantees (not best-effort requiring buffering on either end)

I have 14 ms latency with a server located at 600km from my home. I doubt home audio will generate latency.
 
OP
Vasr

Vasr

Major Contributor
Joined
Jun 27, 2020
Messages
1,409
Likes
1,922
I have 14 ms latency with a server located at 600km from my home. I doubt home audio will generate latency.

Do a long enough ping and find out the min/avg/max to your server and you will find out the variation (over time) is why you need buffering for any real-time application that also requires bandwidth guarantees.

Problem with IP network isn't the best case latency or even the average but that a fixed latency isn't guaranteed except at a cost that is orders more than a simple direct interconnect between two devices. Latency isn't just the wire transmission delay, it is the congestion, retransmissions, etc., if the network is shared. In an audio stack where you are using separate components, there is already some latency introduced by the processing itself (in DSPs or whatever is in the chain). It all adds up.

Audio over IP networks is just fine at the application level streaming mp3 or whatever encoded formats where buffering is implemented. This isn't the application discussed in this thread.
 

patate91

Active Member
Joined
Apr 14, 2019
Messages
253
Likes
137
Do a long enough ping and find out the min/avg/max to your server and you will find out the variation (over time) is why you need buffering for any real-time application that also requires bandwidth guarantees.

Problem with IP network isn't the best case latency or even the average but that a fixed latency isn't guaranteed except at a cost that is orders more than a simple direct interconnect between two devices. Latency isn't just the wire transmission delay, it is the congestion, retransmissions, etc., if the network is shared. In an audio stack where you are using separate components, there is already some latency introduced by the processing itself (in DSPs or whatever is in the chain). It all adds up.

Audio over IP networks is just fine at the application level streaming mp3 or whatever encoded formats where buffering is implemented. This isn't the application discussed in this thread.

As per Dante, the default latency is 1ms

https://dev.audinate.com/GA/dante-controller/userguide/webhelp/content/latency.htm

And anyway latency and delays with audio only is not an issue. As per Audio and Video it's no longer an issue. At least not a big problem.
 
OP
Vasr

Vasr

Major Contributor
Joined
Jun 27, 2020
Messages
1,409
Likes
1,922
As per Dante, the default latency is 1ms

https://dev.audinate.com/GA/dante-controller/userguide/webhelp/content/latency.htm

And anyway latency and delays with audio only is not an issue. As per Audio and Video it's no longer an issue. At least not a big problem.

Sigh. Do you understand that the 1ms number is a minimum latency number for a Dante device (receiver) so that a sender does not attempt to send faster than that if it could and overflow the receiver? The receiver sets the number depending on its capabilities.

And this is for the Dante transceivers, not the entire function that the audio unit may be doing. The equivalent of this is the latency of a HDMI receiver (or USB or Toslink or whatever) between when it receives the signal and when it puts the received data out on the internal bus. Not the processing of that data or the transmission latency. HDMI transmission latency between devices is fixed by wire speed. In an IP network, it is determined by the network latency. You could architect a very low latency IP network at enormous costs relative to connecting a HDMI or a USB or another new connector type. But why?

To a hammer, everything looks like a nail. ;)
 

patate91

Active Member
Joined
Apr 14, 2019
Messages
253
Likes
137
Sigh. Do you understand that the 1ms number is a minimum latency number for a Dante device (receiver) so that a sender does not attempt to send faster than that if it could and overflow the receiver? The receiver sets the number depending on its capabilities.

And this is for the Dante transceivers, not the entire function that the audio unit may be doing. The equivalent of this is the latency of a HDMI receiver (or USB or Toslink or whatever) between when it receives the signal and when it puts the received data out on the internal bus. Not the processing of that data or the transmission latency. HDMI transmission latency between devices is fixed by wire speed. In an IP network, it is determined by the network latency. You could architect a very low latency IP network at enormous costs relative to connecting a HDMI or a USB or another new connector type. But why?

To a hammer, everything looks like a nail. ;)

Can you tell me what's the issue with latency with audio only?
 

patate91

Active Member
Joined
Apr 14, 2019
Messages
253
Likes
137
...latency IP network at enormous costs relative to connecting a HDMI or a USB or another new connector type. But why?

To a hammer, everything looks like a nail. ;)

Their's no enormous cost. One connector that can do almost anything cost less, and cable management is easier. RJ45 is nothing new.
 
OP
Vasr

Vasr

Major Contributor
Joined
Jun 27, 2020
Messages
1,409
Likes
1,922
Can you tell me what's the issue with latency with audio only?

No, there are plenty of times the use cases and issues have been hashed out in this thread.

I am not even sure you understand what the use cases being discussed here are. If you are still stuck in the use case of a MP3 file (or some encoded format of audio) being sent over a network to a player that does all the processing inside the box, then you are not aware of what use case is being discussed here to suggest a solution.

Their's no enormous cost. One connector that can do almost anything cost less, and cable management is easier. RJ45 is nothing new.
Do you mean a point-point connection of RJ-45 with ethernet controllers that have some audio protocol firmware at either end? Why would that be of any benefit over a USB cable and transceiver?

Or are you talking about a hub/switch in the middle with QoS capability that someone configures so that the same network can be used for multiple interconnects without any of them affecting each other? Why would you use that over just point-point USB?

If you start saying wireless, then you are in the stream audio files mindset, I am sure.

Sorry, I am not able to reply any more in this exchange because clearly we are not on the same page on the application of interest in this thread.
 

patate91

Active Member
Joined
Apr 14, 2019
Messages
253
Likes
137
No, there are plenty of times the use cases and issues have been hashed out in this thread.

I am not even sure you understand what the use cases being discussed here are. If you are still stuck in the use case of a MP3 file (or some encoded format of audio) being sent over a network to a player that does all the processing inside the box, then you are not aware of what use case is being discussed here to suggest a solution.


Do you mean a point-point connection of RJ-45 with ethernet controllers that have some audio protocol firmware at either end? Why would that be of any benefit over a USB cable and transceiver?

Or are you talking about a hub/switch in the middle with QoS capability that someone configures so that the same network can be used for multiple interconnects without any of them affecting each other? Why would you use that over just point-point USB?

If you start saying wireless, then you are in the stream audio files mindset, I am sure.

Sorry, I am not able to reply any more in this exchange because clearly we are not on the same page on the application of interest in this thread.

Distance, a whole house can be wired with Ethernet cable. The technology could certainly evolve to wireless.

There's no issues with latency and audio only.
 
OP
Vasr

Vasr

Major Contributor
Joined
Jun 27, 2020
Messages
1,409
Likes
1,922
Yeah, that is a different application than what this thread was about. Streaming audio in that context is almost always buffered to take care of variable latency.
 

signalpath

Active Member
Forum Donor
Joined
Aug 1, 2019
Messages
112
Likes
102
Dante, or the generic AVB (IEEE 802.1BA) seems like the ideal solution. Dante uses a common switch ($25). Legacy multi-channel formats (MADI, etc.) are limited to 24-bits. If someone really needs 384kHz, then suggest Ravenna, which also hosts native DSD. Audio Over Ethernet solutions are working beautifully in professional applications with dozens of audio boxes tied to the same network, robust error correction, acceptable latency, and up to 64 channels on a single RJ45 connector. Over 400 audio manufacturers now license Dante. For consumer systems, it's probably overkill, but there are very few options that carry native 32-bit integer signals (Dante/AVB/Ravenna, USB, Thunderbolt ... anything else?).
 
Top Bottom