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

[Vasr]

I would rather prefer the audio industry to adopt one of the already existing Audio over IP standards (AES-67 / Dante / Ravenna / AVB).

Extend, I might agree but adopt, I am not sure.

Have no problem if they extend an existing technology but make sure that

1. It is agnostic to number of channels (other than physical limitations of cable) and scales to 16-32 channels and bi-directional
2. Has a single cable to carry multiple channels
3. Does not require a hub in the middle for point-point interconnects
4. Have latency guarantees (not best-effort requiring buffering on either end)

Which of those technologies is best suited for the above requirements?

 

[q3cpma]

I know people think we already have USB but we need a better solution for exclusive audio use

Why not replace the Toslink/Optical/AES/Coax/USB/ mess each with its own limitations and no universal plug and play capability

You don't want USB but you want something with "universal plug and play capability" and wide establishment? I say make up your mind. Anyway, in a perfect world, we'd only have something like AES/EBU with more channels and a power pin but still keeping the great XLR connector general shape and protocol simplicity (unlike AES67/Dante and other AoIP monstruosities of complexity); maybe ADAT or even MADI with a new XLR-like (robust, locking and long enough to have the connector support the weight of the cable) optical connection?

 

[Aerith Gainsborough]

I wonder why they never bothered to beef up the SPDIF ports.
Optical connections should be able to handle multichannel PCM w/o problems. Just make the connections accept both, the basic standard we have now for backward compatibility and the new 2.0 extended one for uncompressed multichannel.

No need to re-invent the wheel, just upgrade what is already there.

 

[waynel]

This is part of the problem. The multi-channel interconnect is being led by the industry with DRM concerns, not the rest of the audio industry which is using a mess of interconnect technologies. So, it is not a surprise they find HDMI eminently unsuitable.

I can't think of anything sillier than using a separate AES cable (or a connector in the back panel) for every 2 channels you want to carry between two units. Not a scalable solution for multi-channel.

How about USB?

 

[Vasr]

You don't want USB but you want something with "universal plug and play capability" and wide establishment? I say make up your mind. Anyway, in a perfect world, we'd only have something like AES/EBU with more channels and a power pin but still keeping the great XLR connector general shape and protocol simplicity (unlike AES67/Dante and other AoIP monstruosities of complexity); maybe ADAT with a new XLR-like (robust, locking and long enough to have the connector support the weight of the cable) optical connection?

False choice. You can have both as long as it is an industry standardized protocol that has no downside compared to the ones it is replacing and satisfies the requirements I have written in my previous post. Over time it would acquire broad traction. Just like USB-C, Thunderbolt, etc., when they served a useful purpose.

Problem with AES is the need to get a cable/connector for every pair of channels and not bi-directional (may be there is a way to do that with a single cable). It is too heavyweight a solution for multi-channel use with a very large panel real estate requirement on equipment.

 

[Vasr]

I wonder why they never bothered to beef up the SPDIF ports.
Optical connections should be able to handle multichannel PCM w/o problems. Just make the connections accept both, the basic standard we have now for backward compatibility and the new 2.0 extended one for uncompressed multichannel.

No need to re-invent the wheel, just upgrade what is already there.

I am OK with that but I think a more robust solution is needed for clock sync across all channels to prevent complexity at either end. If the legacy aspects don't interfere with that, then it might work. I always thought copper should be replaced by optical for interconnects with automatic galvanic isolation.

The other benefit of a new or extended protocol is the ability to add out-of-band meta-information that would make processing much easier such as sample rate, codec info if one is used for data allowing multiple codecs to work, more robust hand-shake than existing systems, auto-sync when equipment wakes up from stand-by, etc.

 

[q3cpma]

False choice. You can have both as long as it is an industry standardized protocol that has no downside compared to the ones it is replacing and satisfies the requirements I have written in my previous post. Over time it would acquire broad traction. Just like USB-C, Thunderbolt, etc., when they served a useful purpose.

"Good enough" is the worst enemy of "better" combined with industry/academic inertia exist. As seen in the OS world with Microsoft Singularity or Plan 9 from Bell Labs.

It looks like Plan 9 failed simply because it fell short of being a compelling enough improvement on Unix to displace its ancestor. Compared to Plan 9, Unix creaks and clanks and has obvious rust spots, but it gets the job done well enough to hold its position. There is a lesson here for ambitious system architects: the most dangerous enemy of a better solution is an existing codebase that is just good enough.

— Eric S. Raymond

or just read the gloomy but realistic Systems Software Research is Irrelevant short paper by Rob Pike, one of the men behind Plan 9.

Problem with AES is the need to get a cable/connector for every pair of channels and not bi-directional (may be there is a way to do that with a single cable)

Well, then there's MADI or AES67, but please remember that complexity and reliability of implementations are polar opposites; just look at the sheer size of the HDMI spec, for example.

It is too heavyweight a solution for multi-channel use with a very large panel real estate requirement on equipment.

Unless you want the same problem as "smart" devices and every garbage getting smaller and smaller, I don't see the need of reducing the size and robustness of connectors.

 

[Vasr]

Well, then there's MADI or AES67, but please remember that complexity and reliability of implementations are polar opposites; just look at the sheer size of the HDMI spec, for example.

HDMI suffers from much greater requirements - HDCP, CEC, eARC not to mention handling video itself. Audio transmission is much simpler. So cannot generalize from that.

Unless you want the same problem as "smart" devices and every garbage getting smaller and smaller, I don't see the need of reducing the size and robustness of connectors.

People who build compact boxes might disagree and if we venture out into the daylight of consumer world from our audio man-caves with dedicated rooms, things may look a little different.

We are not talking about smartphone size audio devices here. Apple faces the same criticisms from the same type of people when they make changes but after a few months to years, the world has moved on and like the new advantages.

I like the lightning connector on my iPad that can go either way far better than the original connectors and wouldn't go back.

Not all progress is bad if blanket resistance to change is managed.

 

[q3cpma]

I like the lightning connector on my iPad that can go either way far better than the original connectors and wouldn't go back.

Not all progress is bad if blanket resistance to change is managed.

Didn't address robustness or locking. Not every complaint is just "cavemen being afraid of change".

 

[Vasr]

Didn't address robustness or locking. Not every complaint is just "cavemen being afraid of change".

The lightning connector is no more less locking than the original connector. It isn't any worse than the microUSB on my phone which is a pain in the butt to attach in the dark or without line of sight.

The amount of locking depends on the purpose. Something that requires frequent plugins like a charger typically has less locking than something that is designed to stay put or there is a great consequence to it coming loose like on-stage wiring with pro-audio.

I already mentioned the locking connectors on DP that stay put on all my computers. There is no reason why you cannot have locking HDMI or use the DP connectors themselves (without the audio). The connectors and protocol are two different entities. Such a locking connector is more than enough for consumer audio stacks.

As far as your comment on resistance to change, you are right. There are many shades

Luddite: What we got is fine, don't need anything else
Jaded: I have seen my share of clunkers. Don't need to see more
Pessimistic: Look at all the problems. I don't think you can design anything better.
Sceptic: I am open to a better design but will hold my opinion until I see one
Neutral: It would be good to have X,Y, so there is a need but it would need to satisfy A,B,C, ...
Optimistic: We can do better than this and we get more this way
Pollyanna: We need the next best thing.

Take your pick.

In my line of business, neutral investors funding the optimistic entrepreneurs are the most fruitful combination. Neutrals make good engineers. Sceptics make for good QC people. The rest below them in the negative scale make for redundant middle managers.

 

[garbulky]

I agree with all of your points which is why the need to stay away from HDMI for digital audio interconnects. But nothing prevents the use of the physical connectors and cables for a different protocol for audio only. It is a much higher bandwidth interconnect than USB and the existing certifications for HDMI uses ensure some QC for high speed interconnects.

Well I don't think USB should be the standard because for the most part it only applies to computers and phones. You don't have a whole lot of blu ray players or streaming video players that have USB.
The I2S interface is the closest thing you have to HDMI without the "HDMI" format. However it has a few drawbacks like a short length limit and confusing it with HDMI? If anything that is why I would not reccomend having an HDMI appearance without the HDMI stuff that goes along with it. At the very least the next HDMI standard needs to have an HDMI video passthrough standard that can be made universal for HDMI dacs so that dacs can stay futureproof while video standards evolve.

 

[Vasr]

Well I don't think USB should be the standard because for the most part it only applies to computers and phones. You don't have a whole lot of blu ray players or streaming video players that have USB.
The I2S interface is the closest thing you have to HDMI without the "HDMI" format. However it has a few drawbacks like a short length limit and confusing it with HDMI? If anything that is why I would not reccomend having an HDMI appearance without the HDMI stuff that goes along with it. At the very least the next HDMI standard needs to have an HDMI video passthrough standard that can be made universal for HDMI dacs so that dacs can stay futureproof while video standards evolve.

There are two difference issues. One is the protocol design that takes into account new needs - scalable two-way multi-channel, clock, meta data, etc. Using HDMI protocol here makes no sense and is very problematic. Nor can we require audio equipment manufacturers to handle video. HDMI also makes audio only transmission problematic. This can be designed independent of the connector and may place requirements on the connector.

The second is what connectors to use. Ideal from a technical perspective would be a new type of connector. From a pragmatic perspective, it requires some really heavy hitters in the industry to get behind it. New certification mechanisms, etc.

The alternative is to use an existing connector but not the protocol - DP/HDMI/USB are all good candidates but as pointed out may cause confusion if the same connector is used for different purposes.

An out of the box thinking might be to use HDMI or DP connectors but reverse male and female if possible, so no one would plug a HDMI cable into it or vice versa. All these are solvable problems if one put a mind to it.

I am sure there is enough expertise in this group itself to design such a new protocol even if as an intellectual exercise.

 

[somebodyelse]

Audio over IP is more geared towards zone distribution than equipment point-point interconnects which can guarantee latency (to keep things simple at either end).

If you're going point to point then latency won't be a problem anyway. AVB has guaranteed latency. I haven't checked the others in detail, but I think they rely on latency not being a practical problem on smallish networks when the switches have reasonably common QoS support as specified in their docs. The versatility is the major advantage to me, but I'm familiar with computers and networking, and I can see how it would scare some people off.

I can't think of anything sillier than using a separate AES cable (or a connector in the back panel) for every 2 channels you want to carry between two units. Not a scalable solution for multi-channel.

How about MADI (AES10)? Common 75R BNC coax, up to 64 channels @ 48kHz, fewer at higher sample rates.

 

[Beershaun]

https://xkcd.com/927/

 

[Vasr]

If you're going point to point then latency won't be a problem anyway. AVB has guaranteed latency. I haven't checked the others in detail, but I think they rely on latency not being a practical problem on smallish networks when the switches have reasonably common QoS support as specified in their docs.

Point-point is necessary for interconnects. The problem with relying on QoS features with a switch or router for an average consumer use is ensuring you have the right intermediate box (not the one you picked up at Best Buy necessarily). Or even know what is going on with zero configuration necessary for network transmission on the user's part. This is hard to ensure. Also, you don't necessarily want to impose the burden of a full QoS handing on the audio interface of the equipment handling this for a point-point also with zero configuration.

How about MADI (AES10)? Common 75R BNC coax, up to 64 channels @ 48kHz, fewer at higher sample rates.

I think this comes closest in available protocols. May be the next version can consider solving the clock sync (or not requiring a separate world clock).

Or some kind of a wrapper over this to include content dependent out-of-band metadata. As far as I understand it, there is no out of band data transmitted in that protocol. I could be wrong.

Also a transmission rate of 100mbs might be a limiting factor and as far as I understand it, it is not two-way.

But I would take this as the first step to standardization between consumer, pro-audio and prosumer applications. The need for a single capable protocol and then extensibility is the most critical.

 

[Vasr]

https://xkcd.com/927/

I agree with this. We don't need 14, just one specialized to audio use for emerging multi-channel applications and wider inter-operability is my thesis. Some of the requirements that made those 14 exist in the audio world are no longer relevant to include all of them.

The problem to solve really is one type of multi-channel digital audio interconnect between equipment so that everyone from a $60 DAC manufacturer to a $20k pro-audio uses the same thing. This way boutique shops like Okto don't have to straddle the line between pro-audio and consumer audio with a large number of connectors that go unused.

 

[Kal Rubinson]

That is mostly because they don't come with locking connectors. For some reason, display port connectors seem to work much better. That is an easy to solve problem.

Locking HDMI connectors are available but not common.

 

[waynel]

I agree with this. We don't need 14, just one specialized to audio use for emerging multi-channel applications and wider inter-operability is my thesis. Some of the requirements that made those 14 exist in the audio world are no longer relevant to include all of them.

The problem to solve really is one type of multi-channel digital audio interconnect between equipment so that everyone from a $60 DAC manufacturer to a $20k pro-audio uses the same thing. This way boutique shops like Okto don't have to straddle the line between pro-audio and consumer audio with a large number of connectors that go unused.

How about USB?

"USB 2.0 provides more than enough bandwidth for delivering 18 channels of audio inputs and 20 channels of audio outputs simultaneously"
https://support.focusrite.com/hc/en-gb/articles/208095469-USB-2-0-vs-USB-3-0

USB 3 can do more with the same latency, should be enough for an home AV or music system.

This is also of interest:
https://www.soundonsound.com/techniques/usb-firewire-thunderbolt-which-best-audio

 

[Colonel Bogey]

When do you need that as a stand alone device?

My interface (RME ADI-2 Pro) just has it built in.

Does your RME have AES out? My computer has USB out, my active speakers have AES in. Hence the need for a $300 USB-to-AES converter.

 

[Jinjuku]

Audio over IP is more geared towards zone distribution than equipment point-point interconnects which can guarantee latency (to keep things simple at either end).

I completely understand as a network engineer that's done live broadcast networking.