Battle of S/PDIF vs USB: which is better?

[Soniclife]

Naim had a DAC that did (a). It used a fixed sampling rate and used the gaps to resync with the source. I am not a fan of such designs as it puts requirements on what one plays.

Are you sure Naim did that? They had a dac with a selection of slightly different clocks, would choose one and then if required move to a slightly faster or slower one if required. They had some custom code to ensure the changes were infrequent.

 

[Jakob1863]

I think there are two modes which you are conflating here, both of which can be achieved with S/PDIF:
1. streaming
2. downloading

Could have been, but no, not in this case, you might go back to post #111 ( ):

https://www.audiosciencereview.com/...vs-usb-which-is-better.1943/page-6#post-51771

It is not in dispute that a file can be downloaded in its entirety via any digital link (even RS232!) and then replayed jitter-free.

As said before (see the linked post for one example) this "brute force attempt" isn´t necessary, although of course doing the job.

'Streaming' per se is different: there is no defined start and end point, so you can't know in advance where to insert pauses, or start playback. If the DAC's sample rate is different from the source's (by only a fraction a percent) the DAC must somehow accommodate that difference dynamically => a form of jitter.

As explained above, in this generalized form the assertion isn´t correct.
Of course, there are examples where jitter effects were unavoidable, but the categorical assertion, that "it can´t be...." isn´t correct. I already admitted that it is a bit pedantic, but imo still worth to mention, as i often get the impression that people forget about the mass of older gear still in use. Expecially if it was expensive, delivering good sound quality and is/was durable.

<snip>

I have seen these schemes suggested seriously. They might even achieve what they set out to - in limited applications and with some inconvenience - but using a bidirectional link these shenanigans are unnecessary.

See above.
But anyway, i think we do agree on the fact that even with a S/P-DIF connection it is possible to avoid jitter impact from the source, but that it depends on the specific conditions.

 

[mindbomb]

For spdif, it seems crucial to have asynchronous resampling. This is relatively rare nowadays, with only teac and musical fidelity making accessible dacs that have this afaik. With usb though, asynchronous receivers are more common, although low cost dacs seem like they can be problematic anyway.

The one thing I am left wondering is about the isolation that you get with toslink (or optical usb cables or transformer isolated coaxial). How important is that? Is it just about stopping ground loops, or are there other tangible benefits?

 

[watchnerd]

For spdif, it seems crucial to have asynchronous resampling.

Is it, really?

Is S/PDIF jitter really so bad that it's crucial to have resampling?

Or is this just audio folklore?

 

[Blumlein 88]

Is it, really?

Is S/PDIF jitter really so bad that it's crucial to have resampling?

Or is this just audio folklore?

Well as long as you don't source that from HDMI, it does seem to be folklore.

 

[mindbomb]

Is it, really?

Is S/PDIF jitter really so bad that it's crucial to have resampling?

Or is this just audio folklore?

The results in this thread show that the dacs without resampling perform better with usb, and the ones with it are about the same regardless of input.

 

[Blumlein 88]

The results in this thread show that the dacs without resampling perform better with usb, and the ones with it are about the same regardless of input.

I would say you are over generalizing from too few examples.

Asynchronous resampling can serve as a filter against jitter. Benchmark does this.

Yet there are good DACs that don't resample the SPDIF input asynchronously which still get results roughly equal to the USB inputs. PLL's on the SPDIF can do a good job.

 

[watchnerd]

The results in this thread show that the dacs without resampling perform better with usb, and the ones with it are about the same regardless of input.

Do you think that difference is audible?

 

[bennetng]

There are always exceptions, especially for Schiit:
https://hydrogenaud.io/index.php/topic,111411.0.html
While the topic is about SMSL, there are some very funny Schiit Bifrost measurements in the second page.

 

[watchnerd]

There are always exceptions, especially for Schiit:
https://hydrogenaud.io/index.php/topic,111411.0.html
While the topic is about SMSL, there are some very funny Schiit Bifrost measurements in the second page.

86 dB SNR not good. But why are the links to the Bifrost results WAV files?

 

[bennetng]

86 dB SNR not good. But why are the links to the Bifrost results WAV files?

The wav files are meant to be opened in RMAA so that you can see a detailed report.
http://audio.rightmark.org/products/rmaa.shtml

 

[captain paranoia]

Yet another DAC I found that has both S/PDIF and USB: The S.M.S.L. Mini DAC Sanskrit. While the noise floor is generally lower in S/PDIF, it is peppered with jitter components that are much more problematic as far as audibility

That trace shows clear evidence of a 250Hz (ish) square wave getting into the clock.

The output signal has symmetric spurious sidetones, at 250Hz, and odd harmonics every 500Hz. The symmetry around the output signal suggests either strong coincidence, or spurious on the clock. The first sidetone tells you the fundamental of the clock spur (250Hz), and the odd harmonics tell you that it's due to a square wave injected into the clock generation.

You'd need to look at the system design to see where that 250Hz is coming from. Interestingly, I note that 48k/250 = 192. That's an 'interesting' simple binary value (128+64). My suspicion would be that there's a clock recovery/locking adjustment going on every 192 samples... Basically, it shows that the clock recovery/locking mechanism is pretty poor.

Some of the other traces here show the effect of the clock loop filter, as the noise floor dips slightly around the output signal, showing how the loop filter is actually reducing close-in (wideband) noise.

It would be interesting to see the effect of changing the SPDIF clock frequency, and seeing how the output spurii change; if you can match the source and destination clocks, you ought to disturb the destination clock less (not having to work as hard to lock to the source clock), and so the magnitude of the clock spurii should be reduced. Either a decent clock synthesizer & divider, or a simple pulled xtal ought to do the job.

A general comment to the thread: listen to Cosmik; that man knows what he's talking about.

 

[amirm]

The output signal has symmetric spurious sidetones, at 250Hz, and odd harmonics every 500Hz. The symmetry around the output signal suggests either strong coincidence, or spurious on the clock. The first sidetone tells you the fundamental of the clock spur (250Hz), and the odd harmonics tell you that it's due to a square wave injected into the clock generation.

First, welcome to the forum. On this comment, we would have to vary the source frequency and see the effect on spurs. If they change amplitude then we know it is clock jitter. If they do not, then they are variations/modulation of DAC reference voltage (Vref). For simplicity I don't usually get into this but from troubleshooting point of view, that needs to be run to make sure this is clock jitter and not Vref modulation.

 

[Candlesticks]

Optical provides galvanic isolation and is ok up to 24/96Khz. 24/192 can be troublesome. Most are going to be using 24/44.1 or 24/48Khz so it's not an issue.

I think asynchronous USB is capable of the lowest amount of jitter but it doesn't matter either way.

 

[captain paranoia]

If they do not, then they are variations/modulation of DAC reference voltage (Vref)

Yes; DAC Vref is another means by which symmetric spurs could get in. But I'd really hope they would have the Vref adequately decoupled... And, given that SPDIF is the simpler digital interface, you might hope that it would generate less digital noise than a USB interface operating in 'asynchronous' mode.

I'm now trying to imagine mechanisms by which a clock recovery would inject into Vref, but not cause trouble with the clock...

 

[captain paranoia]

You have a bit stream being sent at f1 with jitter for various reasons (including the cable), and a DAC that is playing samples at f2 that you may control - at the expense of generating your own jitter. You can't 're-clock' without accommodating the frequency difference - which will drift - or allowing long latency and a buffer that drains or fills until it's empty or full whereupon something drastic is needed.

That's exactly what happens with VoIP; there's an ADC clock at one end, and a DAC clock at the other. They are nominally the same frequency, but they are not identical. Eventually, a FIFO buffer will overflow or underflow.

The VoIP protocol allows for the repeat or drop of a frame, thus keeping the FIFO operating at nominal capacity. This gives a brief hiccup to the phone conversation, but that's considered acceptable, as telephony isn't hifi (it's using low-rate CODECs, anyway...).

Such 'drastic' measures wouldn't be acceptable in a 'hifi' situation.

 

[captain paranoia]

First, welcome to the forum.

ps. Thanks for the welcome. It's nice to find somewhere with a sane discussion of the engineering behind audio, rather than unicorn hooves and magic pixie dust that seems to be prevalent elsewhere.

 

[DonH56]

We don't ascribe anything to unicorn hooves, that would be gross, you don't know where they've been. We only use unicorn horns here.

Weclome aboard!

 

[Sal1950]

Unicorn isn't bad, not as tasty as elk but not near as gamey as venison.
Because of the rarity the meat is still quiet pricey.

 

[Rene]

That trace shows clear evidence of a 250Hz (ish) square wave getting into the clock.

The output signal has symmetric spurious sidetones, at 250Hz, and odd harmonics every 500Hz. The symmetry around the output signal suggests either strong coincidence, or spurious on the clock. The first sidetone tells you the fundamental of the clock spur (250Hz), and the odd harmonics tell you that it's due to a square wave injected into the clock generation.

You'd need to look at the system design to see where that 250Hz is coming from. Interestingly, I note that 48k/250 = 192. That's an 'interesting' simple binary value (128+64). My suspicion would be that there's a clock recovery/locking adjustment going on every 192 samples... Basically, it shows that the clock recovery/locking mechanism is pretty poor.

192 samples corresponds to the (AES) S/PDIF block rate; every 192 samples the preamble is inverted. The 250 Hz jitter component is evidence of faulty clock extraction.