Did We Overhype USB Audio And Overlook Possible Pitfalls?

[jabbr]

Optical or wireless transmission have the inherent advantage of electrical isolation. I wonder if as much time and as many resources were placed into developing either of these, whether they would be ahead of where USB is now?

 

If there were a recognized market, an optical to I2S board would be available. Using an FPGA/ARM processor it would be programmed to take the Ethernet input from the SFP, convert and output I2S/DSD, in pretty much the same way that the Amanero USB board uses an XMOS processor to convert between USB and I2S/DSD.

Done correctly it would be better.

 

The more recognition optical Ethernet gets, the more likely someone will make the effort to commercialize this.

[jabbr]

A good part of the problem here is that there are a whole bunch of different protocols for delivering music over Ethernet, and most of them are quite complex, dealing with metadata, cover art etc. This situation requires a fairly decent processor and a lot of software to deal with the plethora of what might get sent to the DAC. This is NOT good for the DAC.

 

What is needed is something like the NAA protocol which as simple as it can get for just sending the music and not dealing with all the other stuff.

 

John S.

 

I use HQPlayer so am contemplating running NAA on the ARM/Linux side of the FPGA SOC ... I've done enough coding in the past that I could probably write the code/driver though have enough other projects that it will undoubtedly take awhile to get around to this. I actually have a 'snickerdoodle' along with SFP module on order just to play around with.

 

Perhaps the AES67/Ravenna protocol would be the best to standardize on?

 

 

Room treatments for headphone users

[jabbr]

That said, my point that USB is a more robust interface than I2S still stands.

 

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.

 

 

Room treatments for headphone users

[jabbr]

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.

[jabbr]

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.

[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.

[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

[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

[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.

[jabbr]

 

So in order to do this you need a SGMII to RGMII converter chip. That was a little more work than I wanted to do then, but it is not that difficult to do.

 

John S.

 

What about:

 

http://www.xilinx.com/support/documentation/application_notes/xapp1082-zynq-eth.pdf

 

Would this work?

[jabbr]

Yes that would work quite nicely, you can do the same thing with Altera SoC chips as well.

 

So IF you are using one of these combo ARM/FPGA (SoC) chips you can just implement the RGMII -> SGMII converter in the FPGA, or if you are not using one of these there are dedicated chips that do this.

 

John S.

 

Seems like Altera might even be ahead of Xilinx regarding this? https://www.altera.com/solutions/technology/transceiver/protocols/pro-sgmii.html , well when my snickerdoodle+gigglebits arrives in a few months I'll have to start playing around with this. Any inexpensive Altera option that is recommended?

 

Really though I've got such a stack of projects in the works that I'd prefer to just buy a packaged solution: hint hint :)

[jabbr]

Depends on how good you are at getting stuff for free. If you're not, some of the simpler boards can be had for less than $100. There's a decent selection here: Terasic - All FPGA Main Boards

 

Any advice on getting dev board for free would be welcome! The ones with SFP cages are pricey!

[jabbr]

Establish a reputation as a kernel developer.

 

Too much latency...