Did We Overhype USB Audio And Overlook Possible Pitfalls?

[vortecjr]

Not a single mention of i2s/dsd:)

[vortecjr]

I2S is is a trivial clock+data serial interface only suited for short links, typically on the same PCB or over a very short cable, due to the lack of any error correction. For transmission from a computer to a different device, you really want something using differential signalling and at least some amount of error correction.

 

Yes and no:

no - why would you need LVDS if you have a network DAC that excepts Ethernet input and outputs i2s/DSD to your circuit.

yes - LVDS i2s for transmission.

 

BTW have you seen the inside of audio gear lately....nothing short about the audio signal paths;)

 

Jesus R

[vortecjr]

Ethernet is differential. I2S is fine within a single device, not between different devices.

 

I2S is by definition single-ended. You can of course send the same signals over a differential link using suitable transceivers, but then it's not really I2S any more.

 

We're still talking about inches. The distance from a computer to a DAC is typically several metres.

 

I have no issue sending i2s/DSD between two boxes in LVDS format and the boxes are a meter apart. I have no issues putting it up against USB DACs or ethernet DACs. I have been doing it for years and I have direct feedback from customers. You can't simply brush it off....

 

Jesus R

[vortecjr]

My Nova's USB input is only 16 bit, 44.1 or 48 kHz, so I have to go optical or coax. Coax seems to be the most reliable. Someday I may get a new DAC, so I was just wondering ...

 

They have a mix of adaptive USB and asynchronous USB based products. This happened to many companies during a period where things where changing very quickly. That one sounds like the one that is adaptive USB. Use it for streaming internet radio...

 

Jesus R

[vortecjr]

For me personally, it was not, and neither was USB -> Toslink or coax -> Toslink (by a long shot). For some folks a converter sounds better; for me and others, USB has been the best so far.

 

All anecdotal (on my part anyway), so up to you how much credit to give it.

 

This is fair.

 

I see a bunch of expensive devices with cheap third party USB receivers boards and the owners love the equipment. Can you argue with a happy customer?

 

Jesus R

[vortecjr]

Yes from my experience I'd rate AES first, Spdif second and USB or toslink joint third in terms of SQ. The Bryston BDP into Chord DAC64 via AES, for example, was superb.

 

With both Hugo and Esoteric DACs I never use USB, as Spdif is superior. Presumably USB is used simply as it's the default interface for commodity PCs - which doesn't seem an auspicious starting point for audiophile SQ.

 

The Bryston BDP uses an off the shelf motherboard and it doesn't output AES/EBU on it's own. The AES/EBU signal appears to come from an XMOS based USB to AES/EBU converter. Not sure which BDP version. They also use a Julia PCI card which is now discontinued by ESI. That Julia PCI card is single ended so the AES/EBU signal is derived from SPDIF.

 

Jesus R

[vortecjr]

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

[vortecjr]

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.

[vortecjr]

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

[vortecjr]

It is a statement of facts. You may of course disagree on the implication of those facts.

 

IIRC, the PerfectWave uses an asynchronous sample rate converter. In fact, the only way you can have an independent clock in a DAC without any flow control is by the use of an ASRC. While I have no doubt it is a very good one, having none at all would be better still.

 

Oh, but I did.

 

Who said anything about USB?

 

Do not confuse I2S with I2C, they are entirely different interfaces used for entirely different purposes. The I2C link in HDMI is also known as DDC (Display Data Channel) and is used by computers to retrieve the supported resolutions etc of a display (EDID). For pure audio applications you can probably ignore it and hope for the best, although it would be able to tell you things like supported sample rates and number of channels.

 

Well that is not what Ted S. is saying in an article on audiophilia.com. This is what he said in double quotes no less:

"Smith: ‘I do not believe there are other DACs that use the FPGA for everything from “parsing” the input bits to outputting single bit DSD. There are a few other DACs that use sample rate conversion of all inputs to a single output frequency, but they use asynchronous sample rate conversion to convert from the incoming clock to the local clock or use a phase-lock loop (PLL) to drive the local clock. We use no input PLLs or FLLs (frequency-locked loops) and we use one master clock (and derive all other needed clock rates synchronously from that). As far as I know we are the only ones that do that.’"

 

Source: PS Audio DirectStream (DS) DAC

 

I did not confuse i2s and i2c and I'm not talking about HDMI for video use. The PS Audio LVDS i2s spec uses pin 15 and 16 for i2c. I mentioned usb as an example to show why one input might be better than another on the same device.

 

BTW I use a Signature Series Rendu LVDS i2s out via a 12" HDMI cable into my Buffalo IIISE DAC. The DAC has a LVDS receiver and very short U.FL cables connecting the resulting i2s signals to the main DAC board. The Buffalo IIISE DAC is synchronously clocked. My Signature Series Rendu and my DAC were at RMAF last year for everyone to sample. You will say it's flawed and I will reply in advance that you need to get out more often:)

 

Jesus R

[vortecjr]

It doesn't matter what they call it, if the output clock is not somehow tied to the source clock (and there is no flow control as in USB Audio 2.0), there must be a conversion going on somewhere. Otherwise there will be clock drift and skips which sound absolutely terrible.

 

Oh, you're just using an HDMI cable, not the HDMI signal protocol? That makes sense.

 

They resample everything in the FPGA to a common rate. The local clock syncs the analog section, the FPGA and the USB receiver.

 

Source: http://www.psaudio.com/wp-content/uploads/2014/02/DirectStream-DAC-white-paper.pdf

 

Jesus R

[vortecjr]

Yes, that's how asynchronous USB always works, and it's the reason this is often preferred over synchronous interfaces. S/PDIF and similar interfaces don't have a return channel and so cannot possibly work this way.

 

With one-way communication from an audio source to a DAC, there are exactly two options: 1) use a PLL (or similar) to lock the DAC clock to the average rate of the incoming data stream, or 2) use an adaptive asynchronous sample rate converter to add or remove samples depending on the relative rates of the clocks. Purists tend to frown upon both.

 

The same master clock is also send to the FPGA that receives the i2s/dsd, AES, S/PDIF, and Toslink.

 

BTW I emailed Ted S. and asked him for clarification (even though I'm sure what his position is) and he replied this when I asked him if the DS uses a asynchronous sample rate converter, "I don't believe in them, at least when I can get away without them. As you probably found out (or remembered) the DS is all synchronous with a VCXO."

 

Jesus R

[vortecjr]

Hey Jud, I spent an inordinate amount of time optimizing the AES interface between my PC and Pacific Microsonics Model Two - I ended up with Weiss and RME interfaces. Anyone who thinks AES is anywhere near perfect should think again - there are massive impedance mis-matches to contend with. Not a good idea in digital audio.

 

No, the only digital interface I have full faith in is properly-terminated BNC. I simply can't understand why this isn't the norm in digital audio. (Well apart from the fact that recording studios had loads of balanced audio cables lying around - not even 110 ohms - so AES in, their infinite wisdom, knocked up the AES/EBU standard.)

 

"Bring back BNC!", that's what I say.

 

Mani.

 

I like BNC as well.

 

Jesus R

[vortecjr]

Some manufacturers prefer the much higher voltage of AES over the impedance of BNC.

 

I'm going to guess DAC manufacturers?

 

Jesus R