Did We Overhype USB Audio And Overlook Possible Pitfalls?

[mansr]

Above is our hypothesis.

 

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

 

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.

 

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.

 

Man that Ted S. guy is really cleaver. In short, you did not consider this option and therefore the hypothesis is wrong. Experiment over.

 

Oh, but I did.

 

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.

 

Who said anything about USB?

 

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

 

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.

[tranz]

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.

 

What about something like the ABC PCB renderer board? Ethernet to I2S and it handles most formats including DSD.

[jabbr]

What about something like the ABC PCB renderer board? Ethernet to I2S and it handles most formats including DSD.

 

Right. That board is limited to DSD128 and copper Ethernet in, but demonstrates the outlined approach. Unsure what that costs. At the moment, the Ethernet input looks to bit a bit more expensive than USB. The "snickerdoodle" is $55 so might make this approach more cost effective as time goes on. Similarly one can embed an ARM CPU board (e.g. beaglebone/raspberry-pi) which can run Linux and be its own NAA.

 

I am specifically looking for a product that has an SFP cage input and consequently will allow fiberoptic Ethernet input.

[Cebolla]

What about something like the ABC PCB renderer board? Ethernet to I2S and it handles most formats including DSD.

+1

 

However, it'll be hard to convince the traditional computer with tethered DAC using majority of the viability of a dedicated network audio file player and DAC in the same box, especially one that streams via UPnP!

[Lighthouse]

I remember Chris mentioned USB Audio stack is being re-written. It's obvious USB is the one still being developed.

 

With how Apple and other desktop/laptop manufacturers are moving into, I don't think other connections except USB and wireless are viable for future. It's been a long time since Ethernet port is replaced by a small USB modem, and USB-C / Thunderbolt is poised to replace chunky HDMI port for video output. Apple's Macbook only has a USB-C port.

[Rexp]

Thanks to those who suggested DAC's that have good sounding USB inputs but my take away from this interesting thread is if one is auditioning DACs, as I have been doing recently, then you had better take a Regen/Intona/etc with you otherwise you will not get a true impression of what DAC's can do. A crazy situation or what?

[One and a half]

Thanks to those who suggested DAC's that have good sounding USB inputs but my take away from this interesting thread is if one is auditioning DACs, as I have been doing recently, then you had better take a Regen/Intona/etc with you otherwise you will not get a true impression of what DAC's can do. A crazy situation or what?

 

That's about the size of it.

[sandyk]

That's about the size of it.

 

A Regen with a battery power supply may be worthwhile taking along, but as the Intona appears to be touchy to get working sometimes, it may not work with the rest of the gear in some situations. A USB +5V Isolating adaptor may be worthwhile taking along too ?

[r_w]

Yes, because IME... until you've heard the kit this way and LAN isolated, you simply 'haven't heard it'. There is no point even reviewing kit until it's in an optimised environment, because the step change in SQ is so obvious when both of these optimisations are in-place.

 

Does it make USB crap? = No

 

Does it mean we're finally understanding how to get the best out of USB (and understanding/managing the effects of computer generated pollution in general)? = Yes

 

I'd say it's an exciting time for digital audio.

 

;-)

 

A Regen with a battery power supply may be worthwhile taking along, but as the Intona appears to be touchy to get working sometimes, it may not work with the rest of the gear in some situations. A USB +5V Isolating adaptor may be worthwhile taking along too ?

[lmitche]

Thanks to those who suggested DAC's that have good sounding USB inputs but my take away from this interesting thread is if one is auditioning DACs, as I have been doing recently, then you had better take a Regen/Intona/etc with you otherwise you will not get a true impression of what DAC's can do. A crazy situation or what?

 

Or arrange for an in home audition.

[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

[mansr]

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.’"

 

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.

 

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.

 

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

[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

[jabbr]

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

 

I think there is a very rough consensus that this general approach will be more widely adopted in the future. As I've said, adding Ethernet input to this is straightforward, at least the literature/block diagrams of the FPGAs that I've seen highlight their ability to handle Ethernet connections.

 

Consider that if the Ethernet connection is exposed as an SFP cage, the user can select between RJ45, single and multi mode fiber by swapping out the SFP module.

 

 

Room treatments for headphone users

[mansr]

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

 

From the rather vague description given there, it appears to be an asynchronous sample rate converter of sorts.

[barrows]

Ok. The Ayre and above mentioned Vega both being $3,000 DACs.

 

I am not sure what point you are trying to make? In a world where five figure DACs (and even 6 figure DACs exist) are common place I consider $3K-$7K DACs moderately priced.

[jabbr]

From the rather vague description given there, it appears to be an asynchronous sample rate converter of sorts.

 

In the general case the USB or Ethernet and possibly the LVDS stream is read into a buffer and then read out of a buffer (FIFO) not in the general case sample rate converted although clearly reclocked/dejittered, certainly depacketized.

 

Of course the DirectStream does up sampling and so sample rate conversion, but that isn't necessary to the approach

[mansr]

In the general case the USB or Ethernet and possibly the LVDS stream is read into a buffer and then read out of a buffer (FIFO) not in the general case sample rate converted although clearly reclocked/dejittered, certainly depacketized.

 

Of course the DirectStream does up sampling and so sample rate conversion, but that isn't necessary to the approach

 

Absent a return channel for flow control, the FIFO will eventually overflow or underflow without an ASRC. Standard asynchronous USB audio has flow control, while S/PDIF, Toslink, and AES do not. Ethernet certainly can since it's a two-way interface but it depends on the high-level protocol, and there are many of those. The LVDS/I2S input requires an additional side channel, so it too could in theory do flow control although I2S as such is a synchronous interface.

[barrows]

From the rather vague description given there, it appears to be an asynchronous sample rate converter of sorts.

 

Actually the DS does not asynchronously resample. all incoming rates are converted to DSD x10, which is an integer relative to both sample rate bases, hence they can use a single clock, without asynchronously resampling the data.

[mansr]

Actually the DS does not asynchronously resample. all incoming rates are converted to DSD x10, which is an integer relative to both sample rate bases, hence they can use a single clock, without asynchronously resampling the data.

 

If the DS master clock is not locked to the source clock, they are by definition asynchronous.

[barrows]

If the DS master clock is not locked to the source clock, they are by definition asynchronous.

 

right, my understanding is that the masterclock is appropriately divided and sent back to the USB receiver, so the data is all locked to the same masterclock source.

Ted Smith specifically replied that the DS does not asynchronously resample the data when I asked him that question directly.

[jabbr]

Absent a return channel for flow control, the FIFO will eventually overflow or underflow without an ASRC. Standard asynchronous USB audio has flow control, while S/PDIF, Toslink, and AES do not. Ethernet certainly can since it's a two-way interface but it depends on the high-level protocol, and there are many of those. The LVDS/I2S input requires an additional side channel, so it too could in theory do flow control although I2S as such is a synchronous interface.

 

All implementation dependent. USB and Ethernet do have flow control and I have not thought out the I2S/LVDS situation. Since the implications of buffer overflow here are not life threatening, I might be happy to accept the need to limit continuous play to xxx hours, and assume that a song change will restart the buffer, but that's just me;)

 

In any case this is the approach. There are of course other approaches. This approach can be used external to the DAC or internal to the DAC and the usual trade offs will always apply. It remains my impression that this approach internal to the DAC i.e. At the DAC input module, will continue to gain traction particularly at the mid to high end.

[mansr]

right, my understanding is that the masterclock is appropriately divided and sent back to the USB receiver, so the data is all locked to the same masterclock source.

 

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.

 

Ted Smith specifically replied that the DS does not asynchronously resample the data when I asked him that question directly.

 

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.

[mansr]

All implementation dependent. USB and Ethernet do have flow control and I have not thought out the I2S/LVDS situation. Since the implications of buffer overflow here are not life threatening,

 

No, but you'll get a nasty pop from your speakers.

 

I might be happy to accept the need to limit continuous play to xxx hours,

 

If placing an upper bound on the continuous playback time is acceptable, you can of course fill your FIFO to 50% at startup and hope for the best. The time limit depends on the size of your buffer and the accuracy of the clocks. I assumed that such arbitrary limits would not be involved.

 

and assume that a song change will restart the buffer, but that's just me;)

 

That assumption is wrong if you do gapless playback.

[manisandher]

Yes, I strongly considered Lynx or RME cards when first getting into computer audio.

 

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.