Support Head-Fi.org by
starting all of your
Amazon.com shopping by
clicking here.
____________________________________________________________________
Today's Featured Head-Fi Blog: A Japanese headfier's monologue (Sasaki)
____________________________________________________________________
Please help
support Head-Fi by becoming a Contributing Member
CLICK
HERE -- Contributing Members, thank you
for your generous support! --
Hi there, I am in the market for a DAC to use with my computer. I want it to have a usb input and I want that input to be converted directly to i2s (as opposed to spdif). I know the DAC1 and all Wavelength audio products($$) do this, but I want more options. Does anyone know if the AQVOX USB 2 MKII or the stello DA220 do this? What about any others? I tried to do a search for this but comments related to I2S seem to be kind of few and far between. Any help is apreciated.
It doesn't include a high quality DAC and would require a DIY enclosure, but Twisted Pear's Opus project includes a module that accepts USB input and produces I2S output. It's also got basic analog outputs from the mediocre PCM2707 it uses for USB->I2S
You just get the board and the parts soldered onto it though, no connectors, indicators or casework.
I have to question why you want this though; my own educated guessing suggests that SPDIF from a PCI card to the DAC will have a much less ambiguous embedded clock than USB audio can. Of course, if your destination DAC does aggressive reclocking this shouldn't be a big deal, and there are other applications for such a device - but I don't think it's the best road to high fidelity computer audio.
The problem with USB audio (at least the USB audio class defined by the USB standard, that most 'audiophile' stuff uses due to economies of scale - this may not apply to commercial products like E-mu 0404 etc.) is that the clock is wholly derived from the actual data transfer itself. The receiver is supposed to get its master clock by averaging each data packet received, which are supposed to come at a rate of exactly 1KHz. There are two problems here. First is that the reference master clock is generated by the PC's USB interface or possibly even the software itself, so it won't be very accurate. Second is that it's much more difficult to design a PLL to sync to this property, and because the receiver's output clock must be generated by multiplying this 1KHz clock by a large factor, error is multiplied.
IMO you're better off using a PCI soundcard with SPDIF output, since the SPDIF clock is a) generated directly by the soundcard's clock circuitry, which is purpose specific and b) is continuous and at a much higher rate, and thus much easier for the receiver's PLL to sync to and c) matches exactly the necessary clock for the DAC, so no multiplication is required.
In short, it all comes down to the clocking. USB does a pretty terrible job of making it easy for the receiver to recover the necessary clocks. It's doable, or devices wouldn't work without serious glitches all the time, but personally I feel more comfortable using an interface where the clock is easy to recover.
If you want 'true' high fidelity, I would hack (or buy) a PCI card for I2S output. USB is the limitation, not trying to get I2S out of the computer. PCI soundcards control the timing of the audio (and generating an interrupt for the software when their buffers need refilling), many USB cards are slaves to the computer's USB bus and just play what they're sent, when they're sent it.
I realize that some DACs use asychronus and some do not, but both claim their methods eliminate jitter with usb... If someone could put this debate to rest that would be great.
I realize that some DACs use asychronus and some do not, but both claim their methods eliminate jitter with usb... If someone could put this debate to rest that would be great.
Most USB audio devices use isochronous transfer (which IMO is worse than asynchronous, more on that later). If the device doesn't require a driver, this is guaranteed as Windows doesn't support asynchronous mode USB audio class devices.
This slaves the DAC clock to the USB receiver, which is then slaved to the PC's clock, which is probably not of high precision (I believe, and haven't looked into it, but this 1ms delay is probably implemented with the PC's RTC, which is not very accurate). Even if it were, the low frequency and large number of output clock samples that must be generated make a difficult job for the PLL on the USB receiver. What we end up with is a pretty unstable input to the PLL, which already is running under difficult conditions. So we can shove in some asynchronous reclocking to deal with the poor quality recovered clock, which is another argument entirely. This is what that post is referring to. It will reject jitter indeed, but there are convincing arguments that other distortion is introduced as a result, and no reclocking circuit is perfect.
The alternative is to a) use an accurate clock source to begin with and b) get this clock signal as undamaged as possible to the DAC. There are two ways to approach this. We can put the master clock in the DAC, or in the soundcard. With a PCI soundcard, this is exactly what happens. Either the OS monitors the soundcard's buffer, or the soundcard requests data with an interrupt when the buffer gets below a certain threshold. Data is clocked entirely out of the buffer. When data is required, the driver calls a callback function in the application that's playing sound and the application then fills the buffer with the next set of samples. In this fashion, the buffer stays filled and the exact sample rate is controlled by the soundcard itself (which plays out of the same memory buffer the application writes to). The soundcard then uses this same sample clock to generate the SPDIF signal, which is very tightly coupled to the clock output, making the clock relatively easy to recover.
The alternative is to place the clock in the DAC itself, as with a USB asynchronous transfer. This is a very similar situation to the PCI card above, except for the limitations of the USB bus which make it much more difficult to obtain a low-latency and not miss many samples. It has the advantage of giving the actual DAC chip access to the master clock, with no regeneration step required. This is probably the optimal situation you will see with unmodified hardware, if USB is solid enough in your case that you don't lose samples (only isochronous transfers are guaranteed bandwidth), if it can handle your sample rate, and if you don't care about latency or hardware mixing.
Finally, it should not be too difficult to modify a cheap PCI card to pull the I2S lines from it out to an external DAC if you so desired. I'm considering doing this with my old SB Live!, but I'm not certain these signals are exposed... With something like an AV-710 it should be trivial. Just find the DAC IC, get its pinout and tap the signals, or even remove it entirely and connect to its pads. Overall I'd say this is the best solution, at least for my own use case, as it has low CPU usage, large bandwidth, low latency, and the possibility of DSP/mixing/etc. happening in the soundcard instead of in software.
All non-driver oriented USB DACS use ISO mode. But there are 3 modes, Sync (no one uses), Adaptive and Async.
If you use off the shelf controllers like the PCM27xx then yes you have to reclock for good results.
But it is actually very easy with some ARM processors and the TI TUSB3200 and TAS1020 to do Adaptive and Async mode with external very low jitter clocks.
You are confusing the 1KHZ thing a little. Basically adaptive you determine the internal and computer differences from the varience between your 1KHZ clock and the SOF frame which happens every 1ms. But really non of this matters because you still use the internal clock because you have a large buffer you can manage your internal clock changes to very little changes.
Non of these devices truely run off the SOF frame to make the clock that sillyness.
But again one of the problems is that USB controllers typically derive their clocks from the 12MHZ USB Clock and getting 11.2896MHZ from that makes for some problems.
But again you can source a MASTER clock to many of these devices and get much better results than any PCI card can ever do. Because in USB there is no clock and with the PCI you are also getting a ton of noise and if the SPDIF is not isolated then forget it.
Thanks
Gordon
__________________
J. Gordon Rankin
Wavelength Audio, ltd.
All non-driver oriented USB DACS use ISO mode. But there are 3 modes, Sync (no one uses), Adaptive and Async.
Windows supports only adaptive and sync until Vista, so nobody actually uses async as it would require a driver installation. As I mentioned, this might not be the case for some commercial devices like the E-mu etc., but as far as I know, no common devices use async. It would be supported under Linux and Vista, so we might see more coming out now...
You are confusing the 1KHZ thing a little. Basically adaptive you determine the internal and computer differences from the varience between your 1KHZ clock and the SOF frame which happens every 1ms. But really non of this matters because you still use the internal clock because you have a large buffer you can manage your internal clock changes to very little changes.
Non of these devices truely run off the SOF frame to make the clock that sillyness.
I don't think I am. First of all, there's no indication in the USB metadata of what the actual sample rate is, the way the standard is defined is that each frame is exactly 1ms of audio and should be played back as such. This allows you to derive the actual sampling frequency easily enough, but you do in fact need to sync to it.
Even with a fairly large buffer, you will quickly either lose samples or overrun the buffer without syncing to the 1ms SOF. Consider an example where the computer's clock is slow by 441Hz - 1%, at 43659Hz. Let's call the first sample played sample 0. After ten seconds, the computer's at sample 436590 while the DAC wants to play sample 441000; assuming 16 bit samples, it would've needed 9KB of buffered data to not underrun during that 10s period. Reasonable, but never seen on an integrated device like the PCM27xx. If we extend the period to five minutes (maybe you'll say it's okay to resync on silence, but you still at least have to play one song...and I think this is terrible engineering either way), the computer's at sample 13097700 while the DAC's playing sample 13230000 - a difference of 132K samples - 264KB. Unreasonable to say the least, and it's unsafe to assume that a buffer will always be sufficient - a buffered system will always underrun or overflow if the clocks are not synced and there is no asynchronous request system. Therefore, they must sync clocks, which in USB audio is done with the SOF indicators at a rate of 1KHz. The sample clock is then generated from this based on the detected rate, but the 1KHz clock is the master. There's no other way to do it using Adaptive Isochronous transfer, unless you're willing to accept sample loss or overrun (both of which create audible artifacts that are not at all desirable).
I could be missing something, but please show me how, without basing the master clock on the 1KHz SOF frequency, it's possible that buffering is sufficient.
But again you can source a MASTER clock to many of these devices and get much better results than any PCI card can ever do. Because in USB there is no clock and with the PCI you are also getting a ton of noise and if the SPDIF is not isolated then forget it.
If asynchronous transfer is used, I agree from an audio quality perspective (though with hardware mixing, CPU usage etc. considerations I think all-around the PCI solution is better as long as the DAC quality is the same). Otherwise, I think you're way off the mark here. If we can get 100+dB noise floors out of a PCI card for analog signals in the mV range, I don't think there's a problem for a differential digital interface at 1V. EMI is a red herring, it's quite simply not that hard to deal with, as the quality of soundcards in the past 5 years should have made plain. The improvements in the digital interface side of things are a much bigger deal.
Which USB DAC's convert USB directly to I2S?
, 
Linear Mode
