TPA - USB Transport

[sinski]

Originally Posted by barrows

mpd is a music player which runs on linux OS. It does not necessarily preclude a USB-I2S interface for the DAC, currently I use a custom music server with a dedicated USB output card, to a B-II based DAC with a USB receiver.

Which USB receiver do you use ?

[barrows]

Originally Posted by sinski

Which USB receiver do you use ?

would be off topic here, I will send you a PM...

[jake01]

Originally Posted by barrows

mpd is a music player which runs on linux OS. It does not necessarily preclude a USB-I2S interface for the DAC, currently I use a custom music server with a dedicated USB output card, to a B-II based DAC with a USB receiver.
But Russ could make a direct host with I2S output (via the daughter card he mentioned) skipping USB.
mpd is typically controlled by a client via LAN (usually wifi). the beauty of this approach is that Russ does not have to develop music player software, or client software, as this already exists and works very well. I use the Mpad app, running on an Ipad to control my server, and it works flawlessly. There are various clients available to control mpd based players, which will run on smart phones and various tablets, or laptops.

Thanks for the explanation!


Is it correct to assume that, in a regular PC or MAC configuration, we can not get directly at the I2S signal, and therefore need a USB interface to multiplex I2S into a serial data stream and get it out of the box over USB's differential signal pair, and then de-multiplex it again into I2S?

Also, is I2S the standard used to shuttle the audio stream around the computer's motherboard or sound card after it is decoded from the stored file format?

And last, I have been taught that a well implemented USB design resolves the jitter issue by essentially buffering the data stream after transmission. Would it be correct to assume that a de-multiplexed data stream sent over at least 3 channels, as is the case with I2S, is an inherently more robust way to prevent jitter?

Thanks!!

[Goto]

Originally Posted by jake01

Thanks for the explanation!


Is it correct to assume that, in a regular PC or MAC configuration, we can not get directly at the I2S signal, and therefore need a USB interface to multiplex I2S into a serial data stream and get it out of the box over USB's differential signal pair, and then de-multiplex it again into I2S?

Also, is I2S the standard used to shuttle the audio stream around the computer's motherboard or sound card after it is decoded from the stored file format?

And last, I have been taught that a well implemented USB design resolves the jitter issue by essentially buffering the data stream after transmission. Would it be correct to assume that a de-multiplexed data stream sent over at least 3 channels, as is the case with I2S, is an inherently more robust way to prevent jitter?

Thanks!!

Hi

Computers do not typically generate or utilise I2S, which is a serial format designed to transmit from a transport to a DAC. It differs from SPDIF in having separate clock lines and a less rf-like layer 1 implementation. Within a PC (i.e. between motherboard and audio card or onboard dac) data is sent in parralel or serial formats (i.e. over the serial bus) in packets of one format or another depending on the driver in use. I2S would be difficult to implement on a motherboard with any real integrity (at a sensible cost at least). And it would mean the DAC would have to live in very close proximity, exposing it to the same noisy environment.

Sending audio over USB works (best, arguably) by sending high speed serial bursts to a device which receives, stores, reclocks and outputs in either SPDIF (devices like the M2Tech HiFace) or I2S formats at a very constant rate. This involves generating the various clocks that I2S specifies (this is what the fancy XMOS or fpga chips do) as these are not explicitly part of the pcm data stored on the computer. The other big opportunity with this kind of implementation is galvanic isolation of the output, keeping ground noise generated in the computer away from the audio processing circuits.

I2S when implemented properly should provide (over a short distance at least) at least the possibility of a very low jitter rate (as seen at the input of the DAC). Due to the bandwidth/speed of the transmission involved (especially for high sample rates) I2S becomes more and more prone to the effects of capacitance/inductance in the wires and stray emf, increasing jitter as distance from the DAC increases.

So, for a real world/affordable implementation, getting the audio electronics away from the PC is a good thing and USB is a robust transmission protocol for the job, but it does not inherently provide a clean, well-clocked datastream for the DAC so a converter is used between the DAC and the computer to solve this problem.

[nycavsr2000]

Originally Posted by Goto

Hi

Computers do not typically generate or utilise I2S, which is a serial format designed to transmit from a transport to a DAC. It differs from SPDIF in having separate clock lines and a less rf-like layer 1 implementation. Within a PC (i.e. between motherboard and audio card or onboard dac) data is sent in parralel or serial formats (i.e. over the serial bus) in packets of one format or another depending on the driver in use. I2S would be difficult to implement on a motherboard with any real integrity (at a sensible cost at least). And it would mean the DAC would have to live in very close proximity, exposing it to the same noisy environment.

Sending audio over USB works (best, arguably) by sending high speed serial bursts to a device which receives, stores, reclocks and outputs in either SPDIF (devices like the M2Tech HiFace) or I2S formats at a very constant rate. This involves generating the various clocks that I2S specifies (this is what the fancy XMOS or fpga chips do) as these are not explicitly part of the pcm data stored on the computer. The other big opportunity with this kind of implementation is galvanic isolation of the output, keeping ground noise generated in the computer away from the audio processing circuits.

I2S when implemented properly should provide (over a short distance at least) at least the possibility of a very low jitter rate (as seen at the input of the DAC). Due to the bandwidth/speed of the transmission involved (especially for high sample rates) I2S becomes more and more prone to the effects of capacitance/inductance in the wires and stray emf, increasing jitter as distance from the DAC increases.

So, for a real world/affordable implementation, getting the audio electronics away from the PC is a good thing and USB is a robust transmission protocol for the job, but it does not inherently provide a clean, well-clocked datastream for the DAC so a converter is used between the DAC and the computer to solve this problem.

Wow. Make that a sticky. For the newbies out there, it succinctly summarizes the trials, tribulations and handshaking issues associated with the marriage between I2S & USB, whilst trying to achieve a state of the art level of high fidelity.

Kudos Goto.

Best,
Anand.

[barrows]

Additional point. While it is true that standard I2S transmission is not robust enough to remain high quality/low jitter over any distance; TPA/Russ has already developed a solution to this problem: the Bit Teleporter.
The Bit Teleporter is a balanced I2S transmission, which elimiantes the problems which can occur when trying to run I2S signals over wiring distances of more than a few cm. Russ has reported no signifcant problems using the Bit Teleporter with I2S signals (including master clock) over even long distances. The balanced nature of the signal can also be used to isolate the computer ground from the DAC. Because he already has the Bit Teleporter, Russ can go ahead and develop his new playback device with a balanced I2S driver output.

[nycavsr2000]

Originally Posted by barrows

Additional point. While it is true that standard I2S transmission is not robust enough to remain high quality/low jitter over any distance; TPA/Russ has already developed a solution to this problem: the Bit Teleporter.
The Bit Teleporter is a balanced I2S transmission, which elimiantes the problems which can occur when trying to run I2S signals over wiring distances of more than a few cm. Russ has reported no signifcant problems using the Bit Teleporter with I2S signals (including master clock) over even long distances. The balanced nature of the signal can also be used to isolate the computer ground from the DAC. Because he already has the Bit Teleporter, Russ can go ahead and develop his new playback device with a balanced I2S driver output.

Thank you for that clarification. For those of us however who are implementing a USB to I2S device within our DAC enclosure (and my only input is USB since I use a Mac Mini), I see 2 options:

1) the USB-I2S converter that Russ is designing, but not currently released.

2) the ExA-U2I device that is already available.

However, I really want an all Twisted Pear solution as I already have the Buffalo III dac with shunt regulation installed. The distance between the USB-I2S converter and I2S input on the Buffalo module in my unit will only be a few mm.

[jake01]

Originally Posted by Goto

So, for a real world/affordable implementation, getting the audio electronics away from the PC is a good thing and USB is a robust transmission protocol for the job, but it does not inherently provide a clean, well-clocked datastream for the DAC so a converter is used between the DAC and the computer to solve this problem.

Thank you for the explanation.

Originally Posted by barrows

Additional point. While it is true that standard I2S transmission is not robust enough to remain high quality/low jitter over any distance; TPA/Russ has already developed a solution to this problem: the Bit Teleporter.
The Bit Teleporter is a balanced I2S transmission, which elimiantes the problems which can occur when trying to run I2S signals over wiring distances of more than a few cm. Russ has reported no signifcant problems using the Bit Teleporter with I2S signals (including master clock) over even long distances. The balanced nature of the signal can also be used to isolate the computer ground from the DAC. Because he already has the Bit Teleporter, Russ can go ahead and develop his new playback device with a balanced I2S driver output.

Would it be possible to mate one Bit Teleporter board with the I2S LPCM coming off a PC HDMI port, especially since it is also LVDS? I don't know very much about HDCP, or tricking the PC into thinking it has the right kind of device connected to the HDMI port, but from my brief research it seems Red Book CDs are exempt from the HDCP encryption. The same is supposed to apply to digital files without DRM. I think that covers quite a few of us..

[francolargo]

Originally Posted by ccclapp

frank, not to go OT, but what are you using for this? Via software in jrmc? Via hardware minidsp? Other?

Thanks

Other: All old school and irrelevant to this conversation. The multichannel DAC source is an old rack-mount recording interface for a PC (w/ custom PCI card), in which playback was the weakest link (though balanced). I tapped I2S for Buffalo and Opus boards. Sound is quite good, but experience with this equipment confirms that various Win PC mobos can differ sonically. (best sounding so far: Gigabyte w/ heavy ground/power planes) Definitely justification to take PCs out of the signal path. But I sure like my software crossovers, and (unlike some wireless systems) when I pipe music into both the kitchen(2 ch) and LR(6 ch), I KNOW it's as 'time aligned' as possible...

Sorry for the diversion,

Frank

[thomaspf]

Originally Posted by Goto

Sending audio over USB works (best, arguably) by sending high speed serial bursts to a device which receives, stores, reclocks and outputs in either SPDIF (devices like the M2Tech HiFace) or I2S formats at a very constant rate. This involves generating the various clocks that I2S specifies (this is what the fancy XMOS or fpga chips do) as these are not explicitly part of the pcm data stored on the computer. The other big opportunity with this kind of implementation is galvanic isolation of the output, keeping ground noise generated in the computer away from the audio processing circuits.

What you describe is an asynchronous transmission mode where the master clock for reclocking the received bits is located on the recieving side. There is however a caveat. Interfaces like the original HiFace invented their own protocol and USB driver module to achieve this asynchronous transmission. While this is not a problem now I wonder for how long these companies plan to update their drivers. While the average lifetime of a computer is around 3 years I tend to keep my audio equipment for much longer. The way to deal with that problem is to look for interfaces that implement USB class drivers that are supported by the mainstream operating systems. For 24bit / 192 Khz playback that means USB Audio Class 2. MacOS and I believe Linux already support this latest USB Audio standard and it is a pretty safe bet that Windows will eventually do the same. This protects you from having a dead box in 10 years.

The XMOS controller that Russ is planning to use supports this standard, so does the update to the Hiface called the HiFace 2. Probably the cheapest option for projects right now is the Audio-GD USB upgrade kit which is based on the Tenor TE8802L chip that also supports USB Audio Class 2. Right now the board is $39 plus shipping. It does not, however, provide for galvanic isolation and all clock singals are derived from a single 12Mhz crystal.

While I wait for the XMOS module from Russ I ordered one of those so I can finally test out my build.

Cheers

Thomas