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

[andymok]

The AoIP protocols are agnostic to the network topology as long as it provides the required QoS and routing/switching features in lower layers and they allow you to pick unicast or multicast depending on requirements.

If you read more, they actually do. See Ravenna / AES67 in detail

 

[Vasr]

If you read more, they actually do. See Ravenna / AES67 in detail

I don't care about insulting posts that state something and "you would know if you only did your research..".

https://medianetworkingalliance.com/faq-aes67/

If you want to discuss what exactly you disagree with in that statement, then do it.

 

[andymok]

The specifications are all open from officials first-hand, they work all the way up from L3 and yes they do allow you to choose whether to run in unicast/multicast. What else do you expect when few simple words suffice?

 

[Vasr]

yes they do allow you to choose whether to run in unicast/multicast.

The problem with "few words" is that your understanding and/or the interrpretation of the official documents could be wrong. Just pointing to "official document" isn't illuminating.

You implied that AoIP is necessarily a bus model. I explained why it isn't necessarily so, that they allow both multicast and unicast and certainly not a bus in the physical network topology. The latter is what makes this more suitable for a larger distance or a multicast application than a backplane interconnect - the subject of this thread (which even when possible in theory makes very little sense).

If you have some cogent arguments to provide an opposing view than just point vaguely to buzzwords, then it might be useful to others.

I am done with this.

 

[andymok]

They are bus model in a mix bus / aux bus sense

 

[Vasr]

They are bus model in a mix bus / aux bus sense

Boy, I don't know if you are really confused or just trolling.

The "buses" in the mixer analogy are not networks. They are assigned (typically manually) to particular group of inputs and outputs (channels) within the same console (physically) so that they can be controlled/mixed together as a group. The connections to external inputs and outputs assigned to a "bus" still need to be done point-to-point in physical mixers. In a soft mixer architecture or with adapter cards to hardware mixers you can connect to external units over IP using AoIP protocols which can be point-point unicast or multicast if more than one destination to the same content is needed (this is what I have been trying to tell you). AoIP protocols cover both as I have explained to you.

The network topology for these external connections aren't buses in any physical network sense. They typically involve a hub-spoke model withe routers/switches and as I have mentioned before, that kind of network architecture make much more sense when there is geographical distance involved (more than connecting a cd player to a DAC in an audio stack - the context of this thread) or you want to avoid multiple cables to the same destination. The mix buses as you call them in this context of connecting multiple units are virtual buses at application level as I have explained to you earlier. In addition in the mixer model, it is also a host/client relationship between the mixer and input/output devices. The individual client devices typically only send to the host (mixer) not a any-any network even though that is possible if neessary.

You are conflating the two concepts without a proper understanding.

There is a valid study on whether we can come up with a "backplane" for an audio stack that is a shared bus for communication between them. For example AES over an ATM network (AES47) established between the components that you can just slide your equipment into. More feasible for people who are doing rack based systems. Much more difficult and expensive than just universal connectors instead of a mix of optical, USB, AES/EBU, etc.

 

[mansr]

Not sure where that impression came from, but to my knowledge AoIP / VoIP is acting like a bus topology via multicast, allowing everyone to establish a stream and anyone to take individual signals from the streams.

I sure hope some random person can't listen in on my VoIP phone calls simply by joining a multicast group.

 

[bluefuzz]

2. Buy a box from any vendor to attach to another box from another vendor to set up a chain without having to worry about channels, sample rates, codecs, etc. Just plug-and-play and it works.
3. Cottage industry of small manufacturers creating specialized boxes that can be placed in the digital chain - bass management, eq, surround processing, mixing, crossovers, etc to mix and match what you need and no more and no less driving both innovation and bringing costs down. Truly take the notion of separates to a new level of functionality.

Isn't the problem with HDMI (the protocol not the connector) that 99% of multichannel content – i.e. movie soundtracks – is encrypted and DRM'ed so any device that wants to use the protocol needs expensive certification and sign NDA's promising not to perform certain kinds of processing? So if any potential new protocol/connector were to allow a 'cottage industry of small manufacturers creating specialized boxes that can be placed in the digital chain' then the current rights holders and certification bodies (i.e. film industry mafia) would not use it anyway. Which brings us back to square one ...

This seems to me to be a political problem rather than a technical one.

 

[Vasr]

Isn't the problem with HDMI (the protocol not the connector) that 99% of multichannel content – i.e. movie soundtracks – is encrypted and DRM'ed so any device that wants to use the protocol needs expensive certification and sign NDA's promising not to perform certain kinds of processing? So if any potential new protocol/connector were to allow a 'cottage industry of small manufacturers creating specialized boxes that can be placed in the digital chain' then the current rights holders and certification bodies (i.e. film industry mafia) would not use it anyway. Which brings us back to square one ...

This seems to me to be a political problem rather than a technical one.

This is a great point but the film industry mafia does not need to use anything. They have control on reproduction only when it is played back via licensed HDMI which requires agreement to not provide it as digital multi-channel to non-HDCP devices. There are a number of legal ways around this if you do not use HDMI.

In the current situation, the content industry mafia joined hands with Intel who owns the patent, the big box industry mafia (Sony, D&M, Yamaha, etc), the latter seeing this is as a way to keep smaller competitors out.

It is a self-inflicted wound on the rest of the audio industry that let the above mafias control the standard that has stunted the growth of multi-channel use in music or video with or without DRM.

There is no DRM issue in legal purchasers of content music or video to make backups of their media and play it through whatever players they want. This is a fairly common use with CDs, DVDs and Blu-Rays with the availability of cheap storage using NAS. This is why there is a Dirac multi-channel for PCs, for example. But it's actual use is hobbled for two reasons.

Unfortunately, use of an audio chain in this playback requires equipment that can output multi-channel audio and the only meaningful option right now is HDMI which (1) requires a HDMI licensed product with the restrictions and (2) keeps smaller shops from providing specialized boxes because of licensing costs. Currently, people on PCs/macs use USB or even optical ports for 5.1 bitstreaming from players. But there isn't much cottage industry in the processing in the chain. A universal connector would solve both problems.

A lot of people prefer multi-channel music (either recorded in multi-channel or synthesized surround). The content production as well consumption of these is limited by the choices available for the audio chain. Going the HDMI route for this is expensive and unnecessary, so again this is fragmented over multiple connector types.

In addition, the pro audio industry with some overlap in consumer/pro-consumer space uses multi-channel audio quite extensively.

The kind of cottage industries a universal connector would enable are the smaller shops that can provide great in-line processing (Auro-like boxes, room eq boxes, flexible zone distributions, integration with home automation, etc). Think of it as blowing up the all-in-one AVRs that provide mediocre collection of things or are very expensive into separate functions done better by individual shops specializing in it. This is exactly what the big box audio industry is afraid of and so they want to protect their all-in-one oligopoly and enabling the content industry mafia.

The rest of the audio industry just wring their hands at the HDMI mafia but do very little about it. This is one way of doing something about it.

 

[win]

Useless anecdote: at my former company, a large corporation with several brands/business units that is the biggest in its industry, there were several ways to describe the exact same things.

Each business unit, some before and some after being acquired, insisted that their description language was the best for their specific needs. So we devised a master catalog to address each business unit's unique needs while still being able to reference a common language. This would have improved things like product integration, client experience, maintainability and cost efficiency by orders of magnitude.

We were able to make this argument within an environment where we controlled all the variables, not third parties and not in a way that had to be agreed upon by competitors.

Sounds great.

It didn't matter. Getting adoption was virtually impossible. It never becomes a priority, because it isn't sexy to spend money on a complex project with no immediate payoff other than making things better for the designers, developers, and product managers.

I can't even fathom trying to do it across competing standards, whether they're public domain or not is irrelevant. Everyone said theirs was already good enough and you should adopt theirs.

 

[bluefuzz]

A universal connector would solve both problems.

Perhaps I'm being dim but I don't see how a new unerversal connector solves anything. So we have a new player machine with shiny new connector that can play multichannel music discs and add various room correction processors to the chain. But it wouldn't be able to play a Dolby Atmos Blu-Ray because the movie mafia haven't licenced their content for this connector. Who would use It?

 

[Vasr]

Perhaps I'm being dim but I don't see how a new unerversal connector solves anything. So we have a new player machine with shiny new connector that can play multichannel music discs and add various room correction processors to the chain. But it wouldn't be able to play a Dolby Atmos Blu-Ray because the movie mafia haven't licenced their content for this connector. Who would use It?

First of all, the content is not licensed to a specific connector. It has a DRM inside it independent of the transport mechanism. People who use HDMI to output it need to follow the HDCP requirements to transport content with DRM. It is legal to make your personal backups of this content that you have purchased and play it through other means, or example, via USB as many do right now (perhaps not all the codecs are available yet) from their NAS based media content ripped from Blu-Rays. But then you need a USB enabled downstream equipment to receive and play it which seriously limits what you can do with it. You can standardize on USB but there are downsides which I have described in a separate earlier post, but the rationale for it is the same.

Second, not all content viewed by people is just Dolby Atmos. The majority of the video content is still 5.1 or 7.1 on dvds and blu-rays and that is only for commercially produced content. There is plenty of indies that produce content for music and audio and they would benefit and proliferate with audio chains that can do a lot more than what they do outside the HDMI mafia.

It is the connector itself that is the silver bullet but what standardizing on it will start to bring out.

Let us say I want to bring out a specialized box with a REW based roomeq but with a much better UI and plug-in-and play capability for average consumer use. I either have to pay a HDMI license or limit myself to the universe of USB enabled boxes which is too small to be economically viable.

Useless anecdote:

I can't even fathom trying to do it across competing standards, whether they're public domain or not is irrelevant. Everyone said theirs was already good enough and you should adopt theirs.

That is what people said before every standard ever developed. You cannot just adopt "theirs" because the market is too fragmented across the options which is why people start to provide multiple types of connectors to make it economically viable. Moreover, the existing standards are too constrained to encourage new types of applications. Many new applications don't even start because of the fragmentation and limitations. If you look at the value props I have listed above for manufacturers and consumers, none of the existing protocols can extend to cater to all of that. But they can all be extended to arrive at a common protocol that satisfies all of their existing use cases and that is where the strength will be.

In addition, fighting for "their" standard will mean no resolution. This is how the mafia gets the monopoly because the rest are too short-sighted and remain within their narrow silos and unable to organize. Much easier to naysay or wring your hands on the mafia and this is what most people are capable of. But standards evolution never come from such people.

I do have some experience in my previous life creating standards playing the big company political game each of which is trying to kill others and gain advantage for themselves and all the naysaying that goes with such an endeavor. It became a very small part of the mobile telecom standards. But I was part of that industry at the time and so able to pull it off. This is why the push needs to come from within the industry (the industry outside the HDMI mafia). I can only start to evangelize needs and value props. Not much more.

 

[StefaanE]

Off the top of my head, so tell me if I’m talking drivel, but why do we even need a connector? The problem is simple — how to get a file from one computer to another. With consumer audio we’re not talking about streaming live material, unless one wants to make the source responsible for clocking the data. LANs are so fast that almost any audio track can be copied in a matter of seconds, and in any case playback can start even when the file’s not complete. As long as source and destination are computers (and at $35 a pop, adding a Raspberry Pi won’t do a lot to the price of an “audiophile” disc spinner or pre-amp), basic network support is all one needs. You don’t need a connector other than an RJ45, but WiFi will do, and be very attractive because “no-cables”. Heck, Zigbee lightbulbs are more intelligent than almost all audio equipment (with the exception of some powered speakers).

 

[Vasr]

Off the top of my head, so tell me if I’m talking drivel, but why do we even need a connector? The problem is simple — how to get a file from one computer to another. With consumer audio we’re not talking about streaming live material, unless one wants to make the source responsible for clocking the data. LANs are so fast that almost any audio track can be copied in a matter of seconds, and in any case playback can start even when the file’s not complete. As long as source and destination are computers (and at $35 a pop, adding a Raspberry Pi won’t do a lot to the price of an “audiophile” disc spinner or pre-amp), basic network support is all one needs. You don’t need a connector other than an RJ45, but WiFi will do, and be very attractive because “no-cables”. Heck, Zigbee lightbulbs are more intelligent than almost all audio equipment (with the exception of some powered speakers).

Files are the wrong paradigm and this is not just file transfers. They are real time streams from players and rendering devices. Requires latency guarantees, clock synchronization, sampling rate negotiation, etc. Audio can be stored in MP3 files but when you get to the audio chain to play, it is converted to two or more PCM streams that need to go from one processing unit to another. This is different from a file transfer.

You can do this over an IP network in theory but it is too heavyweight a solution as an interconnect between say a CD player and an external DAC in a HiFi stack. It would need a separate router/switch box, QoS provisioning in that network, a full IP stack on each of the devices, etc. Very difficult to do as a zero config plug and play for an average consumer. Much better suited for distance separated units where running special audio cables loses its advantages.

 

[win]

Not to mention that LAN is slow compared to purpose built connections. USB type C can do 10 gb/s. Rare to find a router that can support that, let alone the cat6 (?) cabling you're need to facilitate it. And most people want to just use WiFi not Ethernet. And WiFi isn't close to those speeds (yet).

 

[StefaanE]

Files are the wrong paradigm and this is not just file transfers. They are real time streams from players and rendering devices. Requires latency guarantees, clock synchronization, sampling rate negotiation, etc. Audio can be stored in MP3 files but when you get to the audio chain to play, it is converted to two or more PCM streams that need to go from one processing unit to another. This is different from a file transfer.

There are real-time streams because devices are based on the old analogue model. If course, if you want to have a separate PCM to analogue DAC you need a real-time stream, but if that DAC is in a powered speaker, just before the power amp, the only thing that needs to be sent from the storage device to the speaker is a file.

You can do this over an IP network in theory but it is too heavyweight a solution as an interconnect between say a CD player and an external DAC in a HiFi stack. It would need a separate router/switch box, QoS provisioning in that network, a full IP stack on each of the devices, etc. Very difficult to do as a zero config plug and play for an average consumer. Much better suited for distance separated units where running special audio cables loses its advantages.

CDs were, of course, designed to produce analogue signals for the audio equipment of the 1980ies. But if we read the data off the CD as a lossless file, not a PCM stream, it is easy to transmit on today’s networks. As long as the receiving device can convert the file to a suitably amplified analogue signal for the speakers, there should be no problems offering a user experience similar to connecting a smart speaker to a smartphone.

 

[Vasr]

There are real-time streams because devices are based on the old analogue model. If course, if you want to have a separate PCM to analogue DAC you need a real-time stream, but if that DAC is in a powered speaker, just before the power amp, the only thing that needs to be sent from the storage device to the speaker is a file.

This makes zero sense. I think you are confusing a DAC with a codec. A file as you probably think (like MP3) is an encoded file using the MP3 codec. You can send a file to another device for example using AirPlay and the destination can decode and play it even in real time (because encoded files can be streamed too) if all the processing is within the same box until conversion to analog. So an all-in-one AVR can and do act as a network streamer that can receive MP3 files that it can decode and play. That is not what we are talking about here.

When you separate out the digital processing that happens between decoding and conversion to analog in external boxes from multiple vendors - DACs, surround processors, zone distribution, room eq, etc. nothing necessarily to do with analog in this chain, you are doing real time inter-connects of the digital audio stream from the decoder stage. There are no "files" here as you are thinking.

It is the same difference between streaming mp4 files over the network and transferring decoded rendered video over HDMI to the TV from a Blu-Ray player. Both of those exist for a reason even if you can stream an mp4 directly to a TV if it has a decoder inside. If it does, when it extracts audio from that mp4, and wants to play it through a soundbar or through an AVR, it needs to transmit that via real time digital streams to be in sync with the video being rendered, not encode it to a mp3 file and dispatch it.

It is real time because you are hearing it in real time not because it is analog or digital. This is what happens between interconnects in an audio chain even for digital transfer. PCM is a digital format.

Please read up about what a codec does, encoded files and what happens within an audio chain to process the decoded audio for real time playing, going through DSPs, etc.

CDs were, of course, designed to produce analogue signals for the audio equipment of the 1980ies.

 

[bluefuzz]

Let us say I want to bring out a specialized box with a REW based roomeq but with a much better UI and plug-in-and play capability for average consumer use. I either have to pay a HDMI license or limit myself to the universe of USB enabled boxes which is too small to be economically viable.

And I still don't see how your new connector/protocol would change that. Either it gets the blessing of the movie mafia and thus require the same encryption, licensing and drm as HDMI does now or it won't be able to legally play the majority of existing formats through it and nobody would use it ...

 

[Vasr]

And I still don't see how your new connector/protocol would change that. Either it gets the blessing of the movie mafia and thus require the same encryption, licensing and drm as HDMI does now or it won't be able to legally play the majority of existing formats through it and nobody would use it ...

I already explained this in my previous post. Can't do any more than that. Sorry.

 

[pierre]

Not to mention that LAN is slow compared to purpose built connections. USB type C can do 10 gb/s. Rare to find a router that can support that, let alone the cat6 (?) cabling you're need to facilitate it. And most people want to just use WiFi not Ethernet. And WiFi isn't close to those speeds (yet).

thats not relevant. You can have 32 channels on usb2. You can have hundreds of channels on a 1gb connections. Latency is important for studios, not for consumers. A convolution filter for room correction will add a lot of latency (~150ms).

there is already too many connectors. Please don’t add a new one.