TPA - USB Transport - Page 54 - diyAudio
Go Back   Home > Forums > Commercial Sector > Manufacturers > Twisted Pear

Twisted Pear Superior quality electronic kits

Closed Thread
 
Thread Tools Search this Thread
Old 20th April 2012, 02:31 PM   #531
diyAudio Member
 
Join Date: Sep 2004
Quote:
Originally Posted by barrows View Post
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 ?
 
Old 20th April 2012, 02:45 PM   #532
diyAudio Member
 
Join Date: Jul 2010
Default That

Quote:
Originally Posted by sinski View Post
Which USB receiver do you use ?
would be off topic here, I will send you a PM...
 
Old 21st April 2012, 01:37 AM   #533
jake01 is offline jake01  United States
diyAudio Member
 
Join Date: Apr 2012
Quote:
Originally Posted by barrows View Post
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!!
 
Old 21st April 2012, 10:33 AM   #534
Goto is offline Goto  United Kingdom
diyAudio Member
 
Join Date: Sep 2006
Quote:
Originally Posted by jake01 View Post
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.
 
Old 28th April 2012, 04:49 PM   #535
diyAudio Member
 
Join Date: Jul 2004
Location: North Carolina
Quote:
Originally Posted by Goto View Post
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.
 
Old 28th April 2012, 05:29 PM   #536
diyAudio Member
 
Join Date: Jul 2010
Default One...

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.
 
Old 28th April 2012, 06:25 PM   #537
diyAudio Member
 
Join Date: Jul 2004
Location: North Carolina
Quote:
Originally Posted by barrows View Post
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.
 
Old 28th April 2012, 09:07 PM   #538
jake01 is offline jake01  United States
diyAudio Member
 
Join Date: Apr 2012
Quote:
Originally Posted by Goto View Post

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.



Quote:
Originally Posted by barrows View Post
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..
 
Old 30th April 2012, 01:58 AM   #539
diyAudio Member
 
Join Date: Mar 2007
Location: Minneapolis, MN
Quote:
Originally Posted by ccclapp View Post
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
 
Old 30th April 2012, 02:58 AM   #540
diyAudio Member
 
Join Date: Jan 2009
Location: Seattle, WA
Quote:
Originally Posted by Goto View Post
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
 

Closed Thread


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
TPA metronome and Ivy modules woodturner-fran Swap Meet 7 29th January 2010 09:11 PM
TPA COD parts nikongod Swap Meet 6 8th January 2010 04:07 PM
A SD/USB/Ethernet transport jkeny Digital Line Level 8 25th September 2009 12:20 PM
Tpa 3122 help kkchunghk Class D 2 28th August 2009 08:44 AM
Maybe have a CD transport source USB to drive a USB DAC? wa2ise Digital Source 0 6th February 2007 12:22 AM


New To Site? Need Help?

All times are GMT. The time now is 07:28 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright 1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2