Hmm, no USB to i2s ... another BII owner is dissapointed.
Do i understand it right ? The work on the USB module has been stopped and something like Squeezebox on raspberry pi got a priority ?
Even if this kind of device will appear, what about software to control it ?
What about remote control - Android app ?
Do i understand it right ? The work on the USB module has been stopped and something like Squeezebox on raspberry pi got a priority ?
Even if this kind of device will appear, what about software to control it ?
What about remote control - Android app ?
If it's based on MPD which when you already use linux would be the obvious choice that problem is solved already.
MPD is a network based server-client music player where there are working and polished clients for almost all platforms imaginable, so no problem for iOS android windows OSX or if you run linux. http://mpd.wikia.com/wiki/Clients
( I use MPD myself and has done for years though I'm currently only using it locally though I have plans to move it to an external player.)
Hey Guys, I just want to be clear. I am *not* canning the USB project!!! Far from it.
I know its been a long time coming but I have to work my design time around my day job.
The Linux host project will be a separate project I just think it has some better long term prospects that is all.
OK, i will wait for usb interface
Something like raspbery pi with one 2.5" usb drive for music library connected to Buffalo with usb-i2s ? or ?
Some more details will be great
, or it is a top secret project ...I am sure many (not only diy) audiophiles will welcome a product similar to Squeezebox Touch, but without display (for the configuration at the begining one can connect keyboard and display), with i2s output ? (extra TP pcb ?), based on raspberry and dedicated only to non-compromised stereo music reproduction.
Thanks...
Russ, it is a relief to hear that you plan on completing the USB receiver project.
To those who think currently available solutions are adequate/best: my suspicion is that the TPA USB solution will be better than the solutions currently available for us two channel guys (better oscillators, possibility of using new Tridents for power supplies, etc). Although some existing products are quite good, it is not hard to see how they could be improved in terms of clocking and power supplies (an area where TPA is known to not compromise).
As someone using voyage/mpd now, I am also very interested that Russ is working on his own host solution, this is a really cool development, as he can probably concentrate mostly on the hardware side, and leverage the good work already done by the mpd folks. A simple, low power host running mpd and controlled over LAN made for DIY use is a really cool possibility.
Russ, it is a relief to hear that you plan on completing the USB receiver project.
To those who think currently available solutions are adequate/best: my suspicion is that the TPA USB solution will be better than the solutions currently available for us two channel guys (better oscillators, possibility of using new Tridents for power supplies, etc). Although some existing products are quite good, it is not hard to see how they could be improved in terms of clocking and power supplies (an area where TPA is known to not compromise).
As someone using voyage/mpd now, I am also very interested that Russ is working on his own host solution, this is a really cool development, as he can probably concentrate mostly on the hardware side, and leverage the good work already done by the mpd folks. A simple, low power host running mpd and controlled over LAN made for DIY use is a really cool possibility.
I assume a network-based implementation as mentioned above.
I'm confused - how would one navigate and choose tracks without a display?
I wonder - is MPD or similar, inherently superior to a USB-i2s conversion? If so, in what way?
You can navigate and choose tracks using some smartphone app. No display is necessary, maybe only for the initial configration.
I think that TP developpers should start another thread dedicated to this new "TP-squeezebox?-raspberrypi?" project, than we can all discuss about it
Last edited:
What if one doesn't have a smartphone (i.e. me)?
If one has a smartphone - why not play music from that? Isn't Android a form of Linux?
mpd
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.
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!!
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.
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.
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.
Thank you for the explanation.
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..
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
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
- Status
- Not open for further replies.