SPDI/F vs USB for digital audio from laptop to DAC

[Dan Turner]

I have a feeling this has been asked 100 times before, and I remember contributing to a thread where this was discussed, but don't recall seeing any conclusions....

Is it better to use a SPDI/F output (e.g. in most cases optical) to transfer digital audio from a laptop to a DAC, than USB? I read somewhere that because of the fact that a USB interface sends data in 'packets' rather than a continuous stream of bits according to a 'clock', it inherently introduces jitter and hence is not as good sound-quality wise, once the data has been decoded to analogue.

However do DACs with USB inputs have someway of mitigating this by re-clocking the incoming data - is that dependent on how good the DAC is?

I started another thread today about how good the Sonos systems were and ended up concluding that I'd ultimately like to go for a computer based system consisting of a macbook and a Cyrus DAC-X. However this would be rather costly, and I already have a windows laptop. The only 2 things making it unsuitable are 1) hard-drive size and 2) the fact that the spdi/f output is only carried over the HDMI connection (no optical).

The hard drive could probably be upgraded, which leaves only the connection issue. If USB would be a suitable way of connecting to a DAC - without losing out on quality grounds to spdi/f - then all I need is a USB-equipped DAC.

Any thoughts?

 

[Anonymous]

Dan Turner:

I have a feeling this has been asked 100 times before, and I remember contributing to a thread where this was discussed, but don't recall seeing any conclusions....

Is it better to use a SPDI/F output (e.g. in most cases optical) to transfer digital audio from a laptop to a DAC, than USB? I read somewhere that because of the fact that a USB interface sends data in 'packets' rather than a continuous stream of bits according to a 'clock', it inherently introduces jitter and hence is not as good sound-quality wise, once the data has been decoded to analogue.

However do DACs with USB inputs have someway of mitigating this by re-clocking the incoming data - is that dependent on how good the DAC is?

This is true. USB sends a package every millisecond so there is no way that that can be used to clock the data. I think that the consensus was that the quality depends on the implementation. Mainly the quality of the computers S/PDIF output vs the quality of the USB>digital step in the external DAC before is enters the real D>A circuitry. I think that my setup (below) is very hard to beat in value for money: netbooks are quiet, cheap, and adequate for the job, the V-DAC is excellent, its mains supply is cheap but does not melt, external storage is really cheap (I rip cd's on my 'real' laptop) and I have internet radio and shoutcasts also for free. Consider installing free media software on your PC, buy a USB DAC and see how you like it. The only risk is to loose a few pounds if you decide to sell the DAC again (even if you upgrade later I suspect you will keep it to use with your laptop).

 

[idc]

Dan Turner:

....However do DACs with USB inputs have someway of mitigating this by re-clocking the incoming data - is that dependent on how good the DAC is?......

Any thoughts?

My first thought is that any DAC with a USB is designed to take the data as it comes from a USB. For example the V-DAC, which from other forums where members buy stuff and pull it apart to modify it, contains a Burr-Brown DSD1792 and USB receiver chip PCM 2706. I use the Firestone Fubar USB DAC and it is excellent. I am not paying for connections I will never use. I have also seen or read very little that claims to find optical/digital/USB to be consistently and dramatically different from one another in terms of SQ. So my second thought is that other factors such as music file/type, the DAC itself, amp etc are far more important.

 

[Andrew Everard]

However, there are those who report noise problems with USB connections, from which an optical S/PDIF connection provides isolation.

 

[Anonymous]

There are two approached to designing USB DACs, the common and cheaper option acts as described. It is called adaptive mode, the computer squirts data at the USB chip in packets with no care for 44.1k data rates.

There are some USB DACs at the high end which operate in Asychronous mode, this is expensive as generally it requires custom software, as essentially the USB chip now controls the data transfer and the clocking. Wavelength and dCS make DACs like this.

Ease of use for me wins out. In work I use a iBasso D10 over USB, as this charges the battery in the DAC.

At home I use optical digital spdif, as the USB bus has the drives hanging on it. Whereas the optical has less data transfer happening.

I should do some A/B testing with my DACs and see if I can see any difference with the cheap and cheerful optical and digital cables I've got. I've got a few clear evenings this week, so I'll try and do it tonight or tomorrow.

 

[Dan Turner]

zzgavin:
I should do some A/B testing with my DACs and see if I can see any difference with the cheap and cheerful optical and digital cables I've got. I've got a few clear evenings this week, so I'll try and do it tonight or tomorrow.

Sounds on the face of it like the optical spdi/f is the better option, given that it was designed for the transfer of clocked audio data, but the comparison would be a great way of seeing if the theory holds true.

 

[Anonymous]

no got it wrong usb cant introduce jitter as no clock

 

[Andrew Everard]

one off:no got it wrong usb cant introduce jitter as no clock

It's the way he tells 'em...

 

[manicm]

one off:no got it wrong usb cant introduce jitter as no clock

wrong - there is jitter.

 

[Anonymous]

how

 

[Anonymous]

manicm:
one off:no got it wrong usb cant introduce jitter as no clock

wrong - there is jitter.

as far as I understand it, the issue is that USB data transfer in adaptive mode, the common one, is driven by the computer and the USB chip has to adapt to the master clock provided by the computer. Hence there is a clock, the USB system runs at 12MHz, which is not really a clean multiple of 44.1k, so the incoming data is off-kilter and this cause the jitter. Andrew mentioned the electrical noise issue which some mention in articles I've read and I've experienced with a noisy graphics card in the past. Moving to an electrically isolated system seems to be a good idea, especially as USB is used for so much other stuff.

google for Asynchronicity and USB and you'll find more about this topic. Not sure if I can link to the appropriate site. Do blogs count as competing sites?

 

[Anonymous]

see usb org

 

[Anonymous]

one off:see usb org

a direct link and quote from the material you are referencing would be a lot more helpful than terse one line responses.

 

[Anonymous]

Ok, I went to usb.org

"To provide a manageable phase model to the host, an audio function is required to report its internal delay
for every AudioStreaming interface. This delay is expressed in number of frames (ms) and is due to the
fact that the audio function must buffer at least one frame worth of samples to effectively remove packet
jitter within a frame. Furthermore, some audio functions will introduce extra delay because they need time
to correctly interpret and process the audio data streams (for example, compression and decompression).
However, it is required that an audio function introduces only an integer number of frames of delay. In the
case of an audio source function, this implies that the audio function must guarantee that the first sample
it fully acquires after SOFn (start of frame n) is the first sample of the packet it sends over USB during
frame (n+d). d is the audio function's internal delay expressed in ms. The same rule applies for an audio
sink function. The first sample in the packet, received over USB during frame n, must be the first sample
that is fully reproduced during frame (n+d).
By following these rules, phase jitter is limited to ñ1 audio sample. It is up to the host software to
synchronize the different audio streams by scheduling the correct packets at the correct moment, taking
into account the internal delays of all audio functions involved." http://www.usb.org/developers/devclass_docs/audio10.pdf

so there is jitter, even in the original 1998 spec document

 

[professorhat]

one off:no got it wrong usb cant introduce jitter as no clock

one off:see usb org

As usual, your arguments leave absolutely no room for doubt...

 

[Anonymous]

so its host software and not usb thanks

 

[Andrew Everard]

You're really not making much sense...

 

[Dan Turner]

one off:so its host software and not usb thanks

I think that what the referenced material actually says is that because of the inherent design of the way that data is sent over USB any host application pertaining to an audio function has to mitigate the effect of packet delay on the digital audio signal.

So nothing 'wrong' with USB per se, but perhaps a limitation when used for passing data in audio replay applications.

 

[Anonymous]

Ok, let's step back and try to find out what is really the issue here. You do not have to believe me on my word, but I really have tried to understand the basics. One problem is that the word jitter is used as a general term for the variation in delivery of data. In that sense most computer parts have a HUGE jitter, including hdd's but also the usb spec's show this. This means that engineers have to take this into account, for instance by adequate buffering, storing a few millisecs of data. This is the type if jitter referred to earlier in the usb specs I think, and it is solvable. It is not the type of jitter that affects audio playback.

Now the jitter that does affects digital music and more in general any timed digital transfer of information. This is due to the fact that the samples are never perfectly spaced in time in regular intervals (let's say 48kHz for instance). This is the jitter that is discussed usually with CDPlayers and also applies to external DACs. Also the original recording can have jitter - can not be cured. At playback it depends on the quality of the circuitry creating the signal (S/PDIF) or translating the USB datastream to a clocked feed into the DAC. So every ms there are 48 stereo samples that are processed, and every ms there are 48 new samples waiting if all is well, but it is not complicated to read the buffer and clock these samples at 48kHz. With 44.1 this becomes a bit more complicated: not all data packets can have the same length (it's like an extra 29th of february that is needed), but this is also solved.

However, there still is one problem with USB: the clocks of the source and of the receiver DAC may not be exactly the same and there is no clock line in the USB cable, just data coming in. Or in other words, a msec for the sender is not the same as a msec of the receiver. The buffer either becomes empty or overloaded after a while. The receiver has to 'learn' the difference by keeping track of the arrival of data and adjust. How? The Japanese TI/BurrBrown engineer Hitoshi Kondoh found a clever solution (see http://www.planetanalog.com/showArticle.jhtml;jsessionid=H4AWTUBI13KLZQE1GHPSKH4ATMY32JVN?articleID=12801995) that apparently works very well. Now note that this adjustment is a slow and gradual adjustment that stabilizes rapidly, not the between-sample timing variation type of jitter. You can compare this with the speeding up/down of a cd transport. And once the learning is over the receiver uses the _average_ arrival time of data (so not affected by the variation in arrival times) and happily processes the data at the same rate. Intervention and changing the frequency of processing is only rarely needed.

Hope this makes sense to at least to somebody.

Pete

 

[Anonymous]

From my own experience and set up, the most important thing in any pc spdif to external dac conection is to that the pc can send a bit perfect and untouched stream via the spdif and that depends on soundcard and pc configuration. If using this method,then the method of dealing with said jitter at the DAC end becomes a factor.

I don't know much about USB DACs but presumably they buffer the data and then feed that to the onboard DAC which is clocked at the sample rate of the data in a similar way a CD player's DAC receives data off a disc ?

I have bit perfect and untouched SPDIF out from a cheap CMedia based 8738 card (£15) being fed to a Quad 99CDP2 which works very well.

If you are not au fait with how your PC/Operating system handles audio then go down the USB route.

 

[manicm]

http://www.computeraudiophile.com/content/Asynchronicity-USB-Audio-Primer

 

[Anonymous]

manicm:http://www.computeraudiophile.com/content/Asynchronicity-USB-Audio-Primer

Yes, I read this one too. Although I do not contest that the asynchronous mode is very interesting and theoretically superior, I feel that the downside of adaptive is exaggerated (really,dropouts due to empty buffers do not occur) . And although the arrival time of data packets may show variation (call it arrival jitter) the TI implementation uses the +average+ arrival time to adjust the clock used for the dac - this average quickly stabilizes because every msec a new value is added to the average, so normally little or no adjustments are needed and the dac effectively uses the average speed of the incoming data,not the timing between one packet and the next, It is very unlikely that during playback the usb timing decreases or increases steadily: there is some stochastic variation, but on average the msec packet interval will be maintained as this is derived from the computer(-bus) clock. Clock crystals have a very characteristic frequency.

Besides this I am not so sure of the superiority of asynchronous mode. The advantage is clear in that the dac processes data using its own fixed clock. But: computers are specifically designed to give the USB output high prioriy, i.e. produce a regular stream. Now if the dac is the master, it means that the computer should always be responsive to the dac's instructions, if not: dropouts/overruns. But then again, the few available asynchronous usb dacs also work fine so apparently this is not a problem if implemented well.

Anyway I am still happy with my adaptive V-DAC, so it is purely academic to me.

 

[manicm]

Just gave it as a good read. Itself say asynchronous USB is very difficult to implement and not all listeners may like the results anyway.

And the other mag rates the V-Dac very highly.

 

[idc]

A very interesting article. For me the main conclusion from it and this thread is that there is no clear answer to the OPs original question.

The article author speaks at the start of 'taking out marketing terms' and at the end of readers 'must listen to as many products as possible'. He is also very clear that he is not comfortable with any claim that USB is better or worse than any other type of connection.

So I am happy to take the author's research and conclusion and I will stick with USB for its sheer convenience and my own experience of; my setup sounds brilliant to me.