Jump to content
Sign in to follow this  
The Computer Audiophile

Did We Overhype USB Audio And Overlook Possible Pitfalls?

Recommended Posts

Chris, getting back to original post. I would say that we did not overhype USB audio and overlook possible pitfalls at least compared to computer audio with AES/EBU output and i2s output. I started out making computer audio based servers with the Lynx Studio audio card for AES/EBU output. I also made a version with a Julia card that output LVDS i2s. From the server point of view we were able to tweak the sound at the hardware level and software level the same we do with USB and in some cases with the same parts. We could even tweak the audio signal external to the devices with a re-clocker. These designs would also fall under the knife as the sample rate wars moved the high bar. The implementation issues on both the server and the DAC is not new. The interconnects maxing a difference issue is not new. The power supply issue is not new. To me these are the same old issues in a different format.

 

Jesus R

Share this post


Link to post
Share on other sites
Chris, getting back to original post. I would say that we did not overhype USB audio and overlook possible pitfalls at least compared to computer audio with AES/EBU output and i2s output. I started out making computer audio based servers with the Lynx Studio audio card for AES/EBU output. I also made a version with a Julia card that output LVDS i2s. From the server point of view we were able to tweak the sound at the hardware level and software level the same we do with USB and in some cases with the same parts. We could even tweak the audio signal external to the devices with a re-clocker. These designs would also fall under the knife as the sample rate wars moved the high bar. The implementation issues on both the server and the DAC is not new. The interconnects maxing a difference issue is not new. The power supply issue is not new. To me these are the same old issues in a different format.

 

Jesus R

 

Yes, I strongly considered Lynx or RME cards when first getting into computer audio. Bought a Julia, beautifully made card, but eventually sold it because FreeBSD lacked drivers for it.

 

As you point out, each type of device/interconnection/format has advantages and disadvantages, and it's how the individual implementation resolves these that determines sound quality.


One never knows, do one? - Fats Waller

The fairest thing we can experience is the mysterious. It is the fundamental emotion which stands at the cradle of true art and true science. - Einstein

Computer, Audirvana -> wi-fi to router -> EtherREGEN -> microRendu -> USPCB -> ISO Regen (powered by LPS-1) -> USPCB -> Pro-Ject Pre Box S2 DAC -> Spectral DMC-12 & DMA-150 -> Vandersteen 3A Signature.

Share this post


Link to post
Share on other sites
Do you know if this coax connection can be used for DSD?

 

As far as I know coax is PCM only, DSD would need to transcode to PCM and I end up playing DSD from the mini DAC section. I'd like to believe that DSD signal bandwidths will eventually drive audio to use better fiber optical transceiver solution as optics are inherently more linear and error free than EM signal transmission solutions like coax and USB. In telecom we use fiber optic pairs wherever possible today for all terrestrial circuits because of those reasons, with bandwidths up to 100Gbps


Regards,

Dave

 

Audio system

Share this post


Link to post
Share on other sites

I think this is a bit of a chicken and egg scenario. If the audio industry was tasked with producing an "optimum" interface and have it universally adopted we would still be waiting. Using available interfaces is the path of least resistance and with USB being ubiquitous it is therefore the popular choice. Just because there are tweaks to squeeze the best sound out of it doesn't mean that it isn't working. Having equipment with USB/Optical/Coax options seems to cover the bases for 99% of users.

 

This hand wringing about USB is a little ridiculous! Using the same logic you could say all of our collective audio equipment sounds bad because we rely on the power coming into our houses from the grid and we better invent a new supply. After all, if we have to apply tweaks like whiz-bang power strips, isolation transformers, conditioners, etc, it can't be worth it! Where it that personal solar power supply for my equipment? :)


Jim

Share this post


Link to post
Share on other sites
It seems to only be available on lower-cost systems. It is only with the audiophool-pricepoint that you can obtain equipment revealing enough to benefit from tinkering with paranormal phenomena.

 

:)

 

You know, normally we don't let the secret out...

 

:)


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites

 

The error rate on a USB bus is pretty low to begin with. I did some tests a while back, I setup a 6ft long link and ran for several days of continuous music checking the CRC and never got a single error. I repeated this with a 15ft link and the same thing. I then strung together two "extension cords" to get about 30ft and THAT gave a few errors a day.

 

So even though UAC has no error correction it is not that big a deal in most situations.

 

John S.

 

Yet, I think many folks suppositions about USB audio rest on the idea that this is not true, though I am not sure if this idea exceeds the idea that "noise" is being passed by USB - though I have not heard an explanation as of yet (I am sure there is one) as how exactly the DAC processes this electrical noise into something audible (i.e. confuses it for data/bits). Perhaps the DAC is merely passing it on to the amp to be heard?


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites
Two different purposes.

 

All DACs have input modules that convert external signals into something the DAC module itself accepts. I2S is a standard 'interboard' format that the actual DAC board itself accepts.

 

USB is an 'interbox' format. I2S over LVDS is being promoted as an interbox format.

 

I2S over LVDS is obviously more robust than single-ended signals, but it still has problems for use an inter-box format. To see why, look at the signals I2S uses:

 

- BCLK: bit clock

- FRAME or LRCLK: toggles between words, indicates left/right for stereo

- DATA: serial data, sampled on BCLK rising edge

 

As we can see, it is a synchronous interface meaning. If there is too much skew between the signals, the transmission breaks down. 384 kHz 24-bit stereo translates to a BCLK of roughly 19 MHz. Maintaining timing integrity between multiple signals at these rates over long wires is certainly possible (HDMI has much higher rates) but it is also not entirely trivial (and HDMI cables are rarely very long). An embedded clock encoding such as Manchester (Ethernet) or NRZI (USB) is easier to handle and also uses fewer wires.

 

Then there is the issue of flow control, and I2S has none; one end is picked as master and that's it. From a signal timing point of view, having the source as master is easier, but it is worse with regard to sound quality. The DAC chip requires an operational clock of typically 256x Fs. For a 384 kHz sample rate, that's close to 100 MHz. Normally (when everything is on the same PCB), this clock is provided by a crystal oscillator and the bit clock is derived through a divider. For an inter-box link, we probably don't want to send a 100 MHz clock if we can avoid it (yes, HDMI does this), so we're left with either synthesising it from the bit clock using a PLL or using a local oscillator and an asynchronous sample rate converter, neither of which are ideal. Having the DAC as master using a local oscillator give the best jitter performance, but then meeting timing constraints over a long cable becomes much harder (an HDMI source is always the master).

 

Timing and jitter aside, I2S also provides no information on signal parameters: word length, sample rate, etc. These must always be supplied through a side channel. Most DAC chips have I2C or SPI interfaces for this purpose, and there are no protocol standards here. For an interoperable link based on I2S to be viable, a configuration channel must also be specified. This is not hard to do per se, but it still has to be done.

 

In summary, for an inter-box link, I2S is not sufficient by itself, nor is it a particularly good choice as a foundation for a complete solution.

Share this post


Link to post
Share on other sites
Have you tried using a linear power supply and a regen on your USB keyboard?

 

Stop! my side hurts!


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites
With the speed and capacity of today's networks, UDP is not really needed as much to save on bandwidth and connections.

 

Saving bandwidth is usually not the main reason for using UDP. For real-time streaming, TCP can actually be a problem because of its reliability guarantees. If a packet is dropped, TCP will stall the transfer and request retransmission, which ends up causing a much longer drop-out than the a lone lost packet would. By the time you get the retransmission, the packet is too old anyway and you have to discard a bunch of following ones too in order to catch up. For non-real-time streaming (e.g. audio/video on demand), TCP together with a rather large local buffer tends to be the simplest to implement. Provided packet loss is not too severe, the buffer will hide the interruptions in the data stream whenever TCP needs to retransmit.

Share this post


Link to post
Share on other sites
Saving bandwidth is usually not the main reason for using UDP. For real-time streaming, TCP can actually be a problem because of its reliability guarantees. If a packet is dropped, TCP will stall the transfer and request retransmission, which ends up causing a much longer drop-out than the a lone lost packet would. By the time you get the retransmission, the packet is too old anyway and you have to discard a bunch of following ones too in order to catch up. For non-real-time streaming (e.g. audio/video on demand), TCP together with a rather large local buffer tends to be the simplest to implement. Provided packet loss is not too severe, the buffer will hide the interruptions in the data stream whenever TCP needs to retransmit.

 

I must be missing something, why does this not work for audio (a buffer of sufficient size that TCP re-transmissions could get put back in order in time for processing by the DAC)? Are you talking about assuming buffer in the > 1 second range? I would think even in a "mediocre" home wifi situation (where TCP re-transmissions are of a non trivial amount) this would work.

 

As an aside, the UDP comparison has me wanting to jump to the anti-USB camp...


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites
I2S over LVDS is obviously more robust than single-ended signals, but it still has problems for use an inter-box format. To see why, look at the signals I2S uses:

 

- BCLK: bit clock

- FRAME or LRCLK: toggles between words, indicates left/right for stereo

- DATA: serial data, sampled on BCLK rising edge

 

As we can see, it is a synchronous interface meaning. If there is too much skew between the signals, the transmission breaks down. 384 kHz 24-bit stereo translates to a BCLK of roughly 19 MHz. Maintaining timing integrity between multiple signals at these rates over long wires is certainly possible (HDMI has much higher rates) but it is also not entirely trivial (and HDMI cables are rarely very long). An embedded clock encoding such as Manchester (Ethernet) or NRZI (USB) is easier to handle and also uses fewer wires.

 

Then there is the issue of flow control, and I2S has none; one end is picked as master and that's it. From a signal timing point of view, having the source as master is easier, but it is worse with regard to sound quality. The DAC chip requires an operational clock of typically 256x Fs. For a 384 kHz sample rate, that's close to 100 MHz. Normally (when everything is on the same PCB), this clock is provided by a crystal oscillator and the bit clock is derived through a divider. For an inter-box link, we probably don't want to send a 100 MHz clock if we can avoid it (yes, HDMI does this), so we're left with either synthesising it from the bit clock using a PLL or using a local oscillator and an asynchronous sample rate converter, neither of which are ideal. Having the DAC as master using a local oscillator give the best jitter performance, but then meeting timing constraints over a long cable becomes much harder (an HDMI source is always the master).

 

Timing and jitter aside, I2S also provides no information on signal parameters: word length, sample rate, etc. These must always be supplied through a side channel. Most DAC chips have I2C or SPI interfaces for this purpose, and there are no protocol standards here. For an interoperable link based on I2S to be viable, a configuration channel must also be specified. This is not hard to do per se, but it still has to be done.

 

In summary, for an inter-box link, I2S is not sufficient by itself, nor is it a particularly good choice as a foundation for a complete solution.

 

Entirely correct. Now that Ethernet -> I2S is becoming more readily available, it will likely replace the current USB -> I2S as the input section of the DAC.

 

What I am suggesting is that an SFP -> I2S module would be ideal as it would allow either optical or copper Ethernet based on which SFP module is plugged in.

 

I have a "snickerdoodle" and "gigglebits" modules on order "krtkl.com" which should enable this with the correct software.

 

I2S is and only should be what the DAC internally uses to get the reclocked audio bits to the actual DAC circuitry.


Custom room treatments for headphone users.

Share this post


Link to post
Share on other sites

I think someone else has already mentioned this, but . . .

 

Why don't DACs use the USB file-transfer mode instead of streaming? It would seem logical to put a large (say, 128GB) buffer onboard the DAC, then just transfer the file to the DAC and let it "stream" from the internal buffer? Seems that would get rid of any concerns about timing / jitter, power supply "pollution", etc., over the USB cable.

 

I'm sure there's a reason for it, I'm just ignorant and asking the question ;)


John Walker - IT Executive

Headphone - MacMini running Roon Server > Netgear Orbi wireless > Blue Jeans Cable Ethernet > mRendu Roon endpoint > iFi Audio xDSD + iFi Audio xCAN > Focal Elegia

Home Theater - Mac Mini running Roon Server > Blue Jeans Cable HDMI > Pioneer Elite SC-81 > MartinLogan Motion series home theater speakers + M&K subwoofer

Share this post


Link to post
Share on other sites
I must be missing something, why does this not work for audio (a buffer of sufficient size that TCP re-transmissions could get put back in order in time for processing by the DAC)? Are you talking about assuming buffer in the > 1 second range? I would think even in a "mediocre" home wifi situation (where TCP re-transmissions are of a non trivial amount) this would work.

 

For something like a phone call a buffer of that size would add too much latency. It also doesn't work for any kind of live transmission since every lost packet will make you fall a little more behind the source and eventually a buffer of any size will run out.

Share this post


Link to post
Share on other sites
As far as I know coax is PCM only, DSD would need to transcode to PCM and I end up playing DSD from the mini DAC section.

 

You can transfer DSD64 via S/PDIF coax or optical or AES as soon as you use DoP. I tried it on this chain:

PC - [uSB] - Gustard U10 - [coax] - Gustard DAC-X10.

Display of my DAC showed DSD64 with coax input. I found a photo I made that time ... But S/PDIF allows max DSD64 DoP, no chance to use higher DSD bitrates.

 

coax_DSD64.jpg

Share this post


Link to post
Share on other sites
For something like a phone call a buffer of that size would add too much latency. It also doesn't work for any kind of live transmission since every lost packet will make you fall a little more behind the source and eventually a buffer of any size will run out.

 

Ah yes, Homer moment - I forgot USB audio is for other things besides my music audio...


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites
Interesting you mention UDP. Most people think Ethernet means TCP/IP and all audio over Ethernet must use TCP. However, some home audio uses UDP. That said UDP is more than fine for home audio with a decent network.

 

If you are so inclined, what are some examples of these products that are using UDP? Is this usually in the specs of said products?


Hey MQA, if it is not all $voodoo$, show us the math!

Share this post


Link to post
Share on other sites
The Dragonfly comes to mind.

 

 

Definitely! I also understand the latest Meridian Director with MQA is also very good and has the added advantage of being able to take an SPDIF input as well as USB and being a full 24/192 DAC. I haven't heard the MQA version (is it even out yet?) but I have heard the one without MQA, and I have to say Meridian's Apodizing filter makes this DAC sound excellent.


George

Share this post


Link to post
Share on other sites
I think someone else has already mentioned this, but . . .

 

Why don't DACs use the USB file-transfer mode instead of streaming? It would seem logical to put a large (say, 128GB) buffer onboard the DAC, then just transfer the file to the DAC and let it "stream" from the internal buffer? Seems that would get rid of any concerns about timing / jitter, power supply "pollution", etc., over the USB cable.

 

I'm sure there's a reason for it, I'm just ignorant and asking the question ;)

I have had that thought exactly for some time.

 

Actually, since John Swenson made that suggestion a while back and if memory serves, said that he had already done most of the work to achieve it for another project? I am sure it is not quite as simple as that, but in principle I think it has a lot going for it.

Share this post


Link to post
Share on other sites

pre-2013 apple machines were/are limited to 24/96 (or lower) via optical/toslink.

 

Correct, mine does 96kHz and multi-channel.


Dedicated Line DSD/DXD | Audirvana+ | iFi iDSD Nano | SET Tube Amp | Totem Mites

Surround: VLC | M-Audio FastTrack Pro | Mac Opt | Panasonic SA-HE100 | Logitech Z623

DIY: SET Tube Amp | Low-Noise Linear Regulated Power Supply | USB, Power, Speaker Cables | Speaker Stands | Acoustic Panels

Share this post


Link to post
Share on other sites
There is an argument that great USB audio is still in its infancy and out of reach for the average consumer. You can spend $5k and do it yourself, but you need to do an awful lot of research to learn what to do, and have a decent background in digital hardware and software. It's still an enthusiasts game. To get the same performance in a turnkey system may cost $10k to $20k all in.

 

You can show me a shadow of value in that when most can't identify MP3 vs red book reliably. There will always be those announcing the development of the latest and greatest in technology. ........until they aren't. The last gasp from VHS was as a digital audio recorder. I can't wait for USB to die a a predominant audio interface. Nonsense.

Share this post


Link to post
Share on other sites
For an inter-box link, we probably don't want to send a 100 MHz clock if we can avoid it (yes, HDMI does this), so we're left with either synthesising it from the bit clock using a PLL or using a local oscillator and an asynchronous sample rate converter, neither of which are ideal.

 

Above is our hypothesis. Let's perform a thought experiment and test our hypothesis. I sell my Rendu series to a lot of PS Audio PerfectWave DS DAC owners. Set aside the fact that reports on this forum and via email direct to me prove that these customers overwhelmingly prefer this i2s inter-box combination because it does not validate or invalidate our hypothesis. This circumstantial evidence does provide some insight though on the outcome of our experiment because it appears to be a good solution for many. It turns out that the Rendu / PS Audio PerfectWave DS inter-box solution does not use the Rendu's master clock (even though it is a very good one) and it doesn't use a PPL. In fact, the PS Audio PerfectWave DS ignores the Rendu's master clock all together and it derives it's own clock via FPGA. Man that Ted S. guy is really cleaver. In short, you did not consider this option and therefore the hypothesis is wrong. Experiment over. In addition, you did not consider other factors that could be a benefit to this or other combination. For example, you did not consider that when you place a USB receiver (AKA a processor) in a DAC that some companies do not isolate that processor from the DAC section. The Rendu series has a properly isolated output section that can be a benefit to these devices and it may superceed the importance of some other factor.

 

What I'm getting at is that some oversimplified theoretical analysis of why something should not be good can not possible take into account all the reasons why it is good in practice.

 

Jesus R

 

PS the PS Audio's HDMI specification does support i2C communication, but I do not support it because it's not needed for playback.

Share this post


Link to post
Share on other sites
Above is our hypothesis. Let's perform a thought experiment and test our hypothesis. I sell my Rendu series to a lot of PS Audio PerfectWave DS DAC owners. Set aside the fact that reports on this forum and via email direct to me prove that these customers overwhelmingly prefer this i2s inter-box combination because it does not validate or invalidate our hypothesis. This circumstantial evidence does provide some insight though on the outcome of our experiment because it appears to be a good solution for many. It turns out that the Rendu / PS Audio PerfectWave DS inter-box solution does not use the Rendu's master clock (even though it is a very good one) and it doesn't use a PPL. In fact, the PS Audio PerfectWave DS ignores the Rendu's master clock all together and it derives it's own clock via FPGA. Man that Ted S. guy is really cleaver. In short, you did not consider this option and therefore the hypothesis is wrong. Experiment over. In addition, you did not consider other factors that could be a benefit to this or other combination. For example, you did not consider that when you place a USB receiver (AKA a processor) in a DAC that some companies do not isolate that processor from the DAC section. The Rendu series has a properly isolated output section that can be a benefit to these devices and it may superceed the importance of some other factor.

 

What I'm getting at is that some oversimplified theoretical analysis of why something should not be good can not possible take into account all the reasons why it is good in practice.

 

Jesus R

 

PS the PS Audio's HDMI specification does support i2C communication, but I do not support it because it's not needed for playback.

 

Fair enough and I have no doubt that this implementation is SOTA. By the same token, those DACs that don't isolate the USB similarly wouldn't so isolate the I2S;)

 

OTOH, I think that Ethernet will probably overtake this type of LVDS/I2S because once you've gone to the trouble of using an FPGA, mind as well go all out and implement Ethernet -> I2S on the receiver side? I know your own products are "send" side, but surely something akin to Xilinx 7020 can "do it all"? One can then buffer, isolate and reclock the I2S signal right before it hits the DAC, keeping that shiny brand new clock signal as close to the DAC as possible.

 

Also, not a great way to get DSD from the PC to the DAC going over the I2S lines, at least Pink Faun has no interest in supporting that.


Custom room treatments for headphone users.

Share this post


Link to post
Share on other sites
Fair enough and I have no doubt that this implementation is SOTA. By the same token, those DACs that don't isolate the USB similarly wouldn't so isolate the I2S;)

 

OTOH, I think that Ethernet will probably overtake this type of LVDS/I2S because once you've gone to the trouble of using an FPGA, mind as well go all out and implement Ethernet -> I2S on the receiver side? I know your own products are "send" side, but surely something akin to Xilinx 7020 can "do it all"? One can then buffer, isolate and reclock the I2S signal right before it hits the DAC, keeping that shiny brand new clock signal as close to the DAC as possible.

 

Also, not a great way to get DSD from the PC to the DAC going over the I2S lines, at least Pink Faun has no interest in supporting that.

 

You're tied to one solution in an all in one. You have to provide physical isolation and that costs money. A DAC designer might not be a good network guy and vise versa. Having two boxes gives more options. I'm just saying....each approach has its merits and its issues and the consumer needs to consider them. Not sure what you meant about DSD. We multiplex DSD on the i2s lines and I have no issue sending DSD or PCM down the pipe line to my DAC.

 

Jesus R

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  



×
×
  • Create New...