Physical discs are disappearing and streaming players are little computers, many with USB already. My Roku has HDMI output but there's no reason why it could not have firmware to output A/V from the USB jack.
-
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"?
- Thread starter Vasr
- Start date
Hey, nobody has recommended 5G yet...
Unless I missed it.
Then your refrigerator can interrupt the TV to tickle the multichannel-multizone multi-streaming entertainment network with a "past use by date" alert on your gallon of milk while negotiating with the UPS Delivery robot that needs a signature at the front door.
I just hope the other Standards Bodies don't make them use the standard US Emergency Alert Tone.
Can't we adopt the Japanese version (or something similarly innocuous), just to try it out? Wow, they don't even mute the audio for whatever it was to which you were initially listening as you are about to be killed.
Unless I missed it.
Then your refrigerator can interrupt the TV to tickle the multichannel-multizone multi-streaming entertainment network with a "past use by date" alert on your gallon of milk while negotiating with the UPS Delivery robot that needs a signature at the front door.
I just hope the other Standards Bodies don't make them use the standard US Emergency Alert Tone.
Can't we adopt the Japanese version (or something similarly innocuous), just to try it out? Wow, they don't even mute the audio for whatever it was to which you were initially listening as you are about to be killed.
Last edited:
OP
Vasr
Major Contributor
- Joined
- Jun 27, 2020
- Messages
- 1,409
- Likes
- 1,924
- Thread Starter
- #43
USB as a solution:
Differentiate between connector, USB protocol and USB Audio protocol.
As a connector - it has sufficient bandwidth for now (High Speed USB or better). Fairly ubiquitous in the computing world, slowly emerging for audio due to streaming services.
Main problem is that there are a lot of crappy implementations of USB stacks out there with no certification and people would expect it to work with any of them. This is one of the problems HDMI tried to solve with a new connector and certification. It becomes even more important as the complexity of the audio application increases.
Galvanic isolation can still be a problem with computers. The true galvanic isolators for USB are very expensive and they need to handle power transmission as well because of the standard even when optional.
USB protocol - because it is geared towards multi-use, it tries to do a lot of things (still has a client server model built into it for attaching peripherals rather than true peer-peer at its core) and the requirement for power transmission (shouldn't be encouraged for audio interconnects) makes it more problematic as speeds go higher and lack of certifications leads to cheaply made cables.
USB Audio - takes many of the audio needs into consideration but still is hobbled by the legacy issues from USB protocol. Gives far too much latitude on how the clocks are used with many different sync mechanisms any and all of which can be used. This is not a problem when the handling is in software in the drivers but becomes an issue when one needs to implement it in firmware on a chip (for best latency) - I am not an expert on this just what my investigations/research has surfaced so far.
Best if the USB audio protocol stack is implemented on a chip with very little expectation from the driver. That way audio equipment which aren't computing devices wouldn't need to have any drivers, just use standard chips like HDMI receivers/transmitters with the low level handshakes and retransmissions, etc., taken care off by the chip. Like TI's PCM2912A
Bottom line: It is possible to adopt USB connectors and extend the protocol for USB Audio for emerging uses but not be stuck in the current state with crappy implementations and no certifications which creates headaches for audio manufacturers that want to support this as an interconnect from any source/destination.
The audio industry also will have very little say in the evolution of the underlying connectors and protocol which could be an issue.
Differentiate between connector, USB protocol and USB Audio protocol.
As a connector - it has sufficient bandwidth for now (High Speed USB or better). Fairly ubiquitous in the computing world, slowly emerging for audio due to streaming services.
Main problem is that there are a lot of crappy implementations of USB stacks out there with no certification and people would expect it to work with any of them. This is one of the problems HDMI tried to solve with a new connector and certification. It becomes even more important as the complexity of the audio application increases.
Galvanic isolation can still be a problem with computers. The true galvanic isolators for USB are very expensive and they need to handle power transmission as well because of the standard even when optional.
USB protocol - because it is geared towards multi-use, it tries to do a lot of things (still has a client server model built into it for attaching peripherals rather than true peer-peer at its core) and the requirement for power transmission (shouldn't be encouraged for audio interconnects) makes it more problematic as speeds go higher and lack of certifications leads to cheaply made cables.
USB Audio - takes many of the audio needs into consideration but still is hobbled by the legacy issues from USB protocol. Gives far too much latitude on how the clocks are used with many different sync mechanisms any and all of which can be used. This is not a problem when the handling is in software in the drivers but becomes an issue when one needs to implement it in firmware on a chip (for best latency) - I am not an expert on this just what my investigations/research has surfaced so far.
Best if the USB audio protocol stack is implemented on a chip with very little expectation from the driver. That way audio equipment which aren't computing devices wouldn't need to have any drivers, just use standard chips like HDMI receivers/transmitters with the low level handshakes and retransmissions, etc., taken care off by the chip. Like TI's PCM2912A
Bottom line: It is possible to adopt USB connectors and extend the protocol for USB Audio for emerging uses but not be stuck in the current state with crappy implementations and no certifications which creates headaches for audio manufacturers that want to support this as an interconnect from any source/destination.
The audio industry also will have very little say in the evolution of the underlying connectors and protocol which could be an issue.
"Why can't audio industry standardize on a common digital audio "hdmi"?"
Between what and what? What's the requirement to separate the digital source from the digital to analogue conversion? I don't see the need for this unless you want to run a multichannel speaker setup with powered speakers with digital inputs. If you're going to do this, why not just use Ethernet with cheap and ubiquitous chipsets, cables and connectors?
Between what and what? What's the requirement to separate the digital source from the digital to analogue conversion? I don't see the need for this unless you want to run a multichannel speaker setup with powered speakers with digital inputs. If you're going to do this, why not just use Ethernet with cheap and ubiquitous chipsets, cables and connectors?
This is where you've lost me. Basically when you talk about a new connector...I don't see any point to doing that. Why would anybody want a new connector? What would be the benefit. So for instance USB has tremendous bandwith. So does the current HDMI connector. The only reason I would be behind you for an HDMI connector is that currently all new av gear have hdmi connectors. So it makes sense that if we can solve it where DACs have hdmi connectors they can stay relevant and connect to the HDMI gear out there.
But if we have a totally different connector, it seems like doing something just for the sake of doing it and there would be no reason for anybody to adopt it.
They have decided it’s called hdmi and they decided we shall not have unencrypted mch data to and from any consumer device 
so we are doomed to crippled AVR’s as soon as we want >2ch .
Btw.
https://imgs.xkcd.com/comics/standards.png
so we are doomed to crippled AVR’s as soon as we want >2ch .Btw.
https://imgs.xkcd.com/comics/standards.png
OP
Vasr
Major Contributor
- Joined
- Jun 27, 2020
- Messages
- 1,409
- Likes
- 1,924
- Thread Starter
- #47
Differentiating between the protocol and connector, the acceptance will be for what the protocol does not what the connector is (within reason). This differentiation must be clearly understood. A connector is just means to an end with the only requirement being it supports the protocol and that it is uniformly used.
Then there is practical issue of which connector. I am open to using existing connectors but not because nobody will adopt it otherwise. There are pros and cons to both solutions - new and existing.
If the use of the protocol is to have a single unified connector between components, I suspect manufacturers will actually want a new connector to avoid confusion with existing connectors when people try to connect with the same connector but a different protocol and blame the manufacturer for it not working. Some of these decisions are not just technical ones.
Imagine a sound card manufacturer putting a USB port (if that is decided as the connector to use) through a sound card for this new protocol and then they get a zillion phone calls asking why their USB device won't work through this port. There is a non-trivial cost associated with this confusion. Which is why I suggested solutions like taking an existing one and inverting male and female, so at least it is differentiated.
What can a new protocol do that our current connectors and/or protocols cannot? There must be an advantage to make people want to switch. And if you are trying to make it universal, then the reason for switching to a completely new (i.e. universal only to NEW gear) must be something really must have that it gets adopted. The reasons you mentioned in your previous post mean zero to the VAST majority of people. And the vast majority of people are what it's going to take to make some new proprietary thing -"universal.
OP
Vasr
Major Contributor
- Joined
- Jun 27, 2020
- Messages
- 1,409
- Likes
- 1,924
- Thread Starter
- #49
Where would progress be without naysayers. The title is "why can't the audio industry.." not "why can't consumers...". Consumers don't care what protocol nor do you need them to accept a protocol.
Rather than repeat myself, I will capture a summary of the problems and value props to the constituents and leave it here. I was hoping for more participation from technical folks and possibly industry folks.
Problem statement for consumers :
Too many inter-operability problems and connectivity issues between different units for digital audio especially from different vendors.
a. Have to check if a particular device supports optical or usb or AES or whatever to connect one to another, and use expensive dongles to convert between them if that is not the case. Okto 8 Pro is a good example. Many of the miniDSP units suffer from this. Also, some implementations do better with crappy implementations of another vendor than others (e.g., clock sync).
b. Have to deal with different connectors based on 2.0, 2.1, 7.1, 16.x, 32 channels, etc.
c. Different vendors handle clock syncs differently so you never know until you connect whether some unit will work right in your set up.
d. Limited manufacturers for specialized inexpensive digital processing boxes or have to price then high - Stand-alone DSP boxes for roomEQ, surround sound processing.
e. Solutions that work for stereo aren't available or very expensive to do with multi-channel.
f. Inconsistent handling of sampling rates requiring consumers to figure out after reading a manual of technical info to get it working right.
g. Not enough plug-and-play for use of different codecs or sample rates with the only trouble-shooting being no sound or garbage sound coming out.
h. Current solutions only cater to the tech nerds that can jump loops.
i. Multi-channel (for music or HT) remain scarce and expensive (or have to buy all-in-one boxes from mass market vendors)
j. Less than great sound from variability in implementations of different I/O options (coax works better than optical or USB works better than coax, etc)
Not all of the consumers face every problem above but collectively this is a huge problem that limits the availability of great products from a lot of vendors.
While there are specific connectivity solutions for each one of them currently, they limit what you can attach to what with huge fragmentation problem. In addition, many don't scale when one goes from stereo to multi-channel applications. Lot of existing protocols haven't changed much from their introduction and don't take advantage of improving connectivity
Value prop to consumers from a universal connectivity solution:
1. Just buy one type of cable to connect any two digital audio boxes.
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.
4. Ability for software solutions on a PC/Mac for some of the functions to make them part of the
Problem statement for manufacturers:
1. Vendors have to deal with a lot of input/output connectivity issues, often much more than the core function. Because the connectivity options are so fragmented, have to cater to all (cost, effort and panel space) or select a subset and limit the market.
2. Inter-connectivity problems between boxes from different vendors create support and maintenance headaches for manufacturers and unsatisfactory experience for customers.
3. Discourages small dedicated function inexpensive boxes for digital chain as the cost of handling the various input and output options limits the market or makes single-function boxes not economically viable.
Value prop for manufacturers:
1. Ability to bring costs down of specialized boxes for the digital chain with a plug-in and commoditized universal connectivity card of a single type while they focus on core functionality.
2. Greater inter-operability between vendors reducing support costs and improving customer satisfaction.
3. Larger target market not limited by the connectivity choices made
4. Economically viable dedicated/specialized function boxes for the digital chain to compete in innovation and price with a commoditized connector board solution.
5. No artificial silos of stereo vs multi-channel, no artificial limitation of pro-audio vs consumer gear for inter-operability.
Why a new protocol needed?
For universal connectivity to work, it must cater to multiple needs from different applications since it has to bring many different vendors together
1. Plug-and-play and zero config for customer satisfaction that requires extensive use of meta-data and handshake as part of protocol that handles sample rate negotiation, codec availability, etc.
2. Must scale uniformly from 2-ch to 16 or 32 channels at high sample rates without having to add multiple connectors to the same destination
3. Two-way communication necessary for some applications in the digital chain
4. Require a common sample rate and transmission rate clock sync that can be handled automatically by inexpensive chips in the commoditized transceiver boards to make this transparent to the upstream processing.
5. Extensibility for new applications (available headroom for bandwidth)
Is a new connector needed for the above protocol?
Not necessarily but desirable from a practical perspective to avoid confusion with existing connectors with different functionality
How can this be achieved?
Need to convince a few influential and thought-leadership industry people who aren't in the licensed connector business (HDMI), don't like what that does to the industry and have audio applications that don't need that. Get them talking to put together a working group ignoring the naysayers who will always be in the majority.
Nothing was done by people who said nothing was needed or nothing can be done.
How can you help?
If you know anyone that fits the above description, please pass the main content of this post. Awareness and stimulating thinking is the first step. Don't let the nay-saying discourage you.
The title is "why can't the audio industry.." not "why can't consumers...". Consumers don't care what protocol nor do you need them to accept a protocol.Rather than repeat myself, I will capture a summary of the problems and value props to the constituents and leave it here. I was hoping for more participation from technical folks and possibly industry folks.
Problem statement for consumers :
Too many inter-operability problems and connectivity issues between different units for digital audio especially from different vendors.
a. Have to check if a particular device supports optical or usb or AES or whatever to connect one to another, and use expensive dongles to convert between them if that is not the case. Okto 8 Pro is a good example. Many of the miniDSP units suffer from this. Also, some implementations do better with crappy implementations of another vendor than others (e.g., clock sync).
b. Have to deal with different connectors based on 2.0, 2.1, 7.1, 16.x, 32 channels, etc.
c. Different vendors handle clock syncs differently so you never know until you connect whether some unit will work right in your set up.
d. Limited manufacturers for specialized inexpensive digital processing boxes or have to price then high - Stand-alone DSP boxes for roomEQ, surround sound processing.
e. Solutions that work for stereo aren't available or very expensive to do with multi-channel.
f. Inconsistent handling of sampling rates requiring consumers to figure out after reading a manual of technical info to get it working right.
g. Not enough plug-and-play for use of different codecs or sample rates with the only trouble-shooting being no sound or garbage sound coming out.
h. Current solutions only cater to the tech nerds that can jump loops.
i. Multi-channel (for music or HT) remain scarce and expensive (or have to buy all-in-one boxes from mass market vendors)
j. Less than great sound from variability in implementations of different I/O options (coax works better than optical or USB works better than coax, etc)
Not all of the consumers face every problem above but collectively this is a huge problem that limits the availability of great products from a lot of vendors.
While there are specific connectivity solutions for each one of them currently, they limit what you can attach to what with huge fragmentation problem. In addition, many don't scale when one goes from stereo to multi-channel applications. Lot of existing protocols haven't changed much from their introduction and don't take advantage of improving connectivity
Value prop to consumers from a universal connectivity solution:
1. Just buy one type of cable to connect any two digital audio boxes.
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.
4. Ability for software solutions on a PC/Mac for some of the functions to make them part of the
Problem statement for manufacturers:
1. Vendors have to deal with a lot of input/output connectivity issues, often much more than the core function. Because the connectivity options are so fragmented, have to cater to all (cost, effort and panel space) or select a subset and limit the market.
2. Inter-connectivity problems between boxes from different vendors create support and maintenance headaches for manufacturers and unsatisfactory experience for customers.
3. Discourages small dedicated function inexpensive boxes for digital chain as the cost of handling the various input and output options limits the market or makes single-function boxes not economically viable.
Value prop for manufacturers:
1. Ability to bring costs down of specialized boxes for the digital chain with a plug-in and commoditized universal connectivity card of a single type while they focus on core functionality.
2. Greater inter-operability between vendors reducing support costs and improving customer satisfaction.
3. Larger target market not limited by the connectivity choices made
4. Economically viable dedicated/specialized function boxes for the digital chain to compete in innovation and price with a commoditized connector board solution.
5. No artificial silos of stereo vs multi-channel, no artificial limitation of pro-audio vs consumer gear for inter-operability.
Why a new protocol needed?
For universal connectivity to work, it must cater to multiple needs from different applications since it has to bring many different vendors together
1. Plug-and-play and zero config for customer satisfaction that requires extensive use of meta-data and handshake as part of protocol that handles sample rate negotiation, codec availability, etc.
2. Must scale uniformly from 2-ch to 16 or 32 channels at high sample rates without having to add multiple connectors to the same destination
3. Two-way communication necessary for some applications in the digital chain
4. Require a common sample rate and transmission rate clock sync that can be handled automatically by inexpensive chips in the commoditized transceiver boards to make this transparent to the upstream processing.
5. Extensibility for new applications (available headroom for bandwidth)
Is a new connector needed for the above protocol?
Not necessarily but desirable from a practical perspective to avoid confusion with existing connectors with different functionality
How can this be achieved?
Need to convince a few influential and thought-leadership industry people who aren't in the licensed connector business (HDMI), don't like what that does to the industry and have audio applications that don't need that. Get them talking to put together a working group ignoring the naysayers who will always be in the majority.
Nothing was done by people who said nothing was needed or nothing can be done.
How can you help?
If you know anyone that fits the above description, please pass the main content of this post. Awareness and stimulating thinking is the first step. Don't let the nay-saying discourage you.
I have heard that USB host-mode chipset is relatively expensive, which restricts use. I don't know what the cost impact would be.
Type-C ports would have the advantage that the same port may act either as a host or as a peripheral (dual-role data), which makes the behavior more like peer-to-peer.
The port is also relatively small and reversible, and even now users have to distinguish which features are supported by each type-C port. However, type-C dual-role chipset would probably be even more expensive.
Type-C ports would have the advantage that the same port may act either as a host or as a peripheral (dual-role data), which makes the behavior more like peer-to-peer.
The port is also relatively small and reversible, and even now users have to distinguish which features are supported by each type-C port. However, type-C dual-role chipset would probably be even more expensive.
Last edited:
Where did you hear that? Most every SoC has built-in USB host controllers.
OP
Vasr
Major Contributor
- Joined
- Jun 27, 2020
- Messages
- 1,409
- Likes
- 1,924
- Thread Starter
- #52
This is a good point. But for stand-alone chipsets as may happen in a special purpose box that wants to act as a host which may or may not be micro-processor controlled. Without the large and ready market in computing devices where it is less of an issue, USB would have never made it as a general inter-connect.
The commoditization of a transceiver for any port type depends on
1. Narrow functional definition. This is where the multi-use requirements on USB and lack of symmetry between host and client create a problem for it. The HDMI transceivers are relatively cheap, it is the licensing costs that are expensive. Power transmission requirements add to the cost of the USB host even if optional.
2. Relative stability of protocol for longer amortization. Planning ahead for expansion and new applications help reduce number of revisions and the magnitude of backward compatibility costs.
A USB-C port connector may or may not work for this digital audio universal connector. Thunderbolt manages to get 40gbps out of the same port connector. It depends on what the protocol design requirements converge to.
TonioRoffo
Member
- Joined
- Jul 6, 2020
- Messages
- 84
- Likes
- 41
Relevant XKCD, explains all, as usual. https://xkcd.com/927/
The issue is more with accessories that don't include a SoC.
For example, there is no mass-market converter from a USB keyboard to a Bluetooth one, because such a converter would need a USB host controller, which is too complicated.
Several STM32 microcontrollers have USB host and cost less than $5.
somebodyelse
Major Contributor
- Joined
- Dec 5, 2018
- Messages
- 3,745
- Likes
- 3,031
More likely the manufacturers just can't see a mass market for such a device. The USB host side isn't significantly more complicated to deal with than the bluetooth side.
The Bluetooth side is much more complicated.
andymok
Addicted to Fun and Learning
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.
OP
Vasr
Major Contributor
- Joined
- Jun 27, 2020
- Messages
- 1,409
- Likes
- 1,924
- Thread Starter
- #60
You are confusing the OSI layers and multicast vs unicast choices for applications.
The AoIP protocols exist at application level and can use multicast or unicast. Multicast is preferred if you are sending the same content to multiple destinations. Unicast is more efficient if you have a source-destination pair. Multicast is typically used for discovery in the latter. Multicast is wasteful to simulate unicast when the latter is needed (although you can do it in theory).
They all depend on the layers 1-5 of the transport for QoS and routing/switching. You can, in theory, use a physical bus topology like a token ring but most common is the ethernet based IP network with a hub and spoke model where the hub or switch enables the multi-cast feature. This is not the best solution as a replacement for the back of your audio stack.
AoIP makes most sense when the distances are sufficiently large where running special audio cables are problematic and/or you need broadcasting to multiple destinations (e.g., to multiple speakers around the house) where you don't want to run point-point cables.
Part of the motivation for AoIP, in theory at least, for use in mixing consoles, etc came from some of the problems identified here. Too many cables needed with one-way two channel protocols. I don't think any such practical implementations exist unless in big studios where the distance again becomes an issue.
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.
Similar threads
