Does a jittery stream affect quality if reclocked?

[voodooless]

Here is an interesting thread:

XMOS-based Asynchronous USB to I2S interface

Thanks! The Wavecrest is a useful tool but not the best for this type of measurement. You are looking for the phase noise spectrum to get any real information. That is very closely related to the plots published in the Stereophile. The Wavecrest looks at the cycle to cycle spread of the master...

www.diyaudio.com

Why is USB audio relevant for an SPDIF interface? It’s a totally different principle.

 

[Mat]

i think this kinda got off the original question so i'll rephrase

If a jittery stream that's been reclocked sounds & functions perfectly fine, can a non-jittery stream (running through the same reclock process) sound better?

 

[Blumlein 88]

Let's say I have an ASRC DAC which gives different looking FFT graphs of source 12k sine signal coming from different streamers, I mean a digital domain here. What would be the explanation?

You would not get such a situation in the digital domain. If the bitstreams have the same bits, the FFT would be the same. In the digital domain there is no jitter. Jitter only happens when you convert from analog to digital or digital to analog. It comes from timing in the clock used for the conversion.

 

[voodooless]

If a jittery stream that's been reclocked sounds & functions perfectly fine, can a non-jittery stream (running through the same reclock process) sound better?

The first question is: can you hear a jittery stream at all (given that the receiver can keep lock)? Next, it will depend on the ability of the receiver to reject the jitter. There are various methods of reclocking, all with their own specifics.

In general though, jitter is no issue and is not audible unless the receiver is designed by a potato. Reclocking will therefore not make it sound better.

 

[Mat]

The first question is: can you hear a jittery stream at all (given that the receiver can keep lock)?

yes, like i said it sounds and functions perfectly fine after being reclocked

In general though, jitter is no issue and is not audible unless

Yeah this is the problem I've gotten into, so many threads and youtube videos describing what jitter sounds like or how it affects sound that I'm not sure if I'm hearing the results of jitter or its just in my head at this point

 

[voodooless]

Yeah this is the problem I've gotten into, so many threads and youtube videos describing what jitter sounds like or how it affects sound that I'm not sure if I'm hearing the results of jitter or its just in my head at this point

what does jitter ACTUALLY sound like?

In a previous post we had an encounter with jitter in audio. The talk about jitter is hard to miss these days. There are plenty of products on the mar...

www.sereneaudio.com

Note that these examples are extremes. Normal jitter is orders of magnitude smaller.

Also:

Understanding Jitter in Digital Audio: Measurements and Listening Tests

Yet another video, this time on topic of jitter. It is a tough topic to cover and I had to do it over and simplify it from my first "take." Hopefully you can follow it. :) Article: understanding digital audio measurements...

www.audiosciencereview.com

 

[Blumlein 88]

Slow down guys. Lots of incorrect information in this thread already. I'm assuming everyone is posting in good faith.

First digital streams have no jitter. Jitter occurs in conversions due to a clock not being perfect. No where in a .wav file for instance is timing encoded other than the rate of conversion. No timing is in it.

Now SPDIF embeds the clock in the format. So a receiving DAC has to lock onto that stream to extract timing. Usually with a PLL. Jitter can be in that signal and various DACs vary in their ability to filter it out or lock onto it.

USB does not work that way. Clocking is done at DAC chip by a free running clock that does not lock onto anything. Usually this is very low in jitter.

So the Op describes his DAC not locking onto an SPDIF source with skips and dropouts. It could be due to an overly jittery SPDIF signal or a DAC with poor ability to lock on. A reclocker in the middle of that could clean up the signal so he gets a good lock.

Now generally if you have a good lock it is very, very, uncommon for jitter to be at audible levels. Cannot say it cannot happen, but almost never does. At that point one source might have more or less jitter, but they won't result in slightly better or worse sound quality in terms that are perceptible.

 

[onlyoneme]

You would not get such a situation in the digital domain. If the bitstreams have the same bits, the FFT would be the same. In the digital domain there is no jitter. Jitter only happens when you convert from analog to digital or digital to analog. It comes from timing in the clock used for the conversion.

What do you think is this then?

Would you retrieve the same bits from the spdif carrier when there are different source devices with different clocks and your receiver doesn't lock to the incoming spdif clock?

 

[voodooless]

What do you think is this then?

View attachment 281639

An FFT of the analog conversion.

Would you retrieve the same bits from the spdif carrier when there are different source devices with different clocks and your receiver doesn't lock to the incoming spdif clock?

No, but that’s not wat we’re seeing in your FFT. No lock is lost data, simple as that.

 

[onlyoneme]

An FFT of the analog conversion.

It's not. It's an FFT of reclocked spdif signal using ASRC miniDSP device, passed thru USB.

 

[Blumlein 88]

What do you think is this then?

View attachment 281639

Would you retrieve the same bits from the spdif carrier when there are different source devices with different clocks and your receiver doesn't lock to the incoming spdif clock?

Agreeing with Voodooless. I'd need to know more, but these are not the same bitstreams. Probably from analog conversions.

If you get a lock, you get the same data and an FFT of that data is the same. Once you convert it to analog the FFT may have differences.

If you don't get a lock, then you don't have an intact signal.

 

[Blumlein 88]

It's not. It's an FFT of reclocked spdif signal using ASRC miniDSP device, passed thru USB.

If that is a digital signal from start to finish you have some other issues. Can you slow down and describe in detail the signal path and how that FFT was obtained?

 

[onlyoneme]

Agreeing with Voodooless. I'd need to know more, but these are not the same bitstreams. Probably from analog conversions.

If you get a lock, you get the same data and an FFT of that data is the same. Once you convert it to analog the FFT may have differences.

If you don't get a lock, then you don't have an intact signal.

Those results are based on streams coming from different devices playing the same content, and captured on the same ASRC device.

 

[Blumlein 88]

Those results are based on streams coming from different devices playing the same content, and captured on the same ASRC device.

Captured how? You have to understand, by its design if all of that is digital, then they have to be the same, or at some point something has altered some of the bits. It is inherent in how digital audio works. Why is ASRC involved if these are all digital streams?

 

[voodooless]

It's not. It's an FFT of reclocked spdif signal using ASRC miniDSP device, passed thru USB.

Okay, so it’s essentially digitally resampled data. Looks like the SPDIF receiver and ASRC aren’t doing a good job. I’m guessing your source sample rate was 48 kHz and the DSP rate is also 48 kHz? Often this is a worst case scenario for an ASRC.

 

[onlyoneme]

Okay, so it’s essentially digitally resampled data. Looks like the SPDIF receiver and ASRC aren’t doing a good job.

Maybe they are not doing a good job, but as you could see the device which is responsible for that is giving 3 different results for 3 different source devices.

 

[onlyoneme]

Captured how? You have to understand, by its design if all of that is digital, then they have to be the same, or at some point something has altered some of the bits. It is inherent in how digital audio works. Why is ASRC involved if these are all digital streams?

Because it's quite helpful to use always the same internal sampling rate when DSP functions are used? To remove the jitter?
You do not transfer digital data literally, you have to retrieve it from the analog carrier, don't you?

 

[onlyoneme]

Okay, so it’s essentially digitally resampled data. Looks like the SPDIF receiver and ASRC aren’t doing a good job. I’m guessing your source sample rate was 48 kHz and the DSP rate is also 48 kHz? Often this is a worst case scenario for an ASRC.

Bad guess. It has been resampled from 48 to 96 kHz.

 

[voodooless]

Maybe they are not doing a good job, but as you could see the device which is responsible for that is giving 3 different results for 3 different source devices.

Possibly designed by a potato then It wouldn’t be the first time a MiniDSP device has less than stellar jitter handling.

Yet I doubt any of this is audible.

 

[amirm]

My question is: Would reclocking make both streamers equal in the end, or is giving the dac a signal with less jitter to reclock going to affect sound quality for the better in any way?

Standard mechanism for extracting the incoming clock is using a PLL (Phased Locked Loop). It acts like a flywheel to add mass and reduce/eliminate variations. The mechanism works really well for high frequencies but at lower frequencies, it is not very effective. Think of a turntable. You can slow it down by putting your hand on it and trying to get it to do so. You can make the flywheel or turntable platter heavier to make it resist lower frequency perturbations. But then it would take longer to get up to speed. Same thing happens with digital audio connection. More robust PLL takes longer to lock to incoming clock and annoy the user with silence while it is doing so. Practical implementations then get rid of high frequency jitter and let the low frequency ones get through.

Every PLL has a lock range outside of which it can no longer extract the incoming clock. This is the reason for losing audio streams. Here you are losing data. So fidelity is least of your worries.

Note that the mere fact of putting audio samples in a buffer doesn't help you. The data must be played using the incoming clock rate. So if you didn't have the above PLL, you would simply be transferring input errors to output.