Does a jittery stream affect quality if reclocked?

[onlyoneme]

Not locking means missing data (sometimes meaning duplicated samples as well, depending implementation). It would be very obviously audible.

For a device which relays on the incoming clock probably yes. But you don't need to know the external clock if you just retrieve the data from the spdif carrier to reclock it with ASRC.

So "no data", or just improper data when jitter is high?

 

[Blumlein 88]

For a device which relays on the incoming clock probably yes. But you don't need to know the external clock if you just retrieve the data from the spdif carrier to reclock it with ASRC.

So "no data", or just improper data when jitter is high?

None of this is helpful to the OP's question.

Jitter can be with proper data. No data or corrupt data is a different case. All this worry over jitter is misplaced.

 

[voodooless]

So "no data", or just improper data when jitter is high?

Essentially no data, or at best repeated samples. SPDIF has parity error correction, so 1-bit errors can be detected at least. Usually things like the preamble are also going wrong, leading to the receiver loosing lock. All of this is in very extreme cases, far beyond what you’d normally expect from the interface. If a streamer delivers this, it’s broken.

 

[onlyoneme]

Essentially no data, or at best repeated samples. SPDIF has parity error correction, so 1-bit errors can be detected at least. Usually things like the preamble are also going wrong, leading to the receiver loosing lock. All of this is in very extreme cases, far beyond what you’d normally expect from the interface. If a streamer delivers this, it’s broken.

Usually just slightly degraded data as shown in my example.

 

[onlyoneme]

None of this is helpful to the OP's question.

Jitter can be with proper data. No data or corrupt data is a different case. All this worry over jitter is misplaced.

Which question do you mean?
In case of this one
"Would reclocking make both streamers equal in the end"
I guess you would agree that in some cases like the one I've presented, streamers won't equal.

 

[voodooless]

Usually just slightly degraded data as shown in my example.

No! The digital data was fully intact. What you see is the clock jitter thought the ASRC process. It’s as if the data went though a DAC and ASC, just that the whole process was done in the digital domain.

 

[Blumlein 88]

Which question do you mean?
In case of this one
"Would reclocking make both streamers equal in the end"
I guess you would agree that in some cases like the one I've presented, streamers won't equal.

They would be audibly equal.

 

[onlyoneme]

No! The digital data was fully intact. What you see is the clock jitter thought the ASRC process. It’s as if the data went though a DAC and ASC, just that the whole process was done in the digital domain.

I would see all 3 cases the same if above is true, but they differ. And measurements with those differences are reproduceable.

 

[onlyoneme]

They would be audibly equal.

Well. DeltaWave software shows sound quality differences between sample tracks captured using all those devices. But I'm not going to decide what's audible and what is not.

 

[voodooless]

I would see all 3 cases the same if above is true, but they differ.

Yes, because of al the reasons already explained, not because of data corruption.

 

[onlyoneme]

Yes, because of al the reasons already explained, not because of data corruption.

What's the reason of differences between those 3 devices? It cannot be the ASRC jitter as the ASRC device is the same. It can be incoming signal jitter as it affects the audio stream just before the reclocking process, that's what I called "slightly degraded data".

 

[pablolie]

None of this is helpful to the OP's question.

Jitter can be with proper data. No data or corrupt data is a different case. All this worry over jitter is misplaced.

I agree. Jitter is pretty much inevitable. With current networking speeds audio does not represent a worrisome load in most networks (I'd hope).

Jitter is addressed with buffering, as the OP mentioned. If you're using TCP (which most streaming music does these days, all major services do), between buffer and retransmission you really don't have to worry much - any competently designed device will feed the DAC data at the required rate to avoid starvation. When the latter happens these days, it's typically some bug in firmware caused by other stuff (network drivers, DHCP stuff or such). Bug free implementations should be pretty rock solid. There is very little -if any- benefit to very advanced synchronization stuff with audio, IMO. Plenty of algorithms to recover the clock from the digital signal.

 

[onlyoneme]

I agree. Jitter is pretty much inevitable. With current networking speeds audio does not represent a worrisome load in most networks (I'd hope).

Jitter is addressed with buffering, as the OP mentioned. If you're using TCP (which most streaming music does these days, all major services do), between buffer and retransmission you really don't have to worry much - any competently designed device will feed the DAC data at the required rate to avoid starvation. When the latter happens these days, it's typically some bug in firmware caused by other stuff (network drivers, DHCP stuff or such). Bug free implementations should be pretty rock solid. There is very little -if any- benefit to very advanced synchronization stuff with audio, IMO. Plenty of algorithms to recover the clock from the digital signal.

Jitter in the packet-based transmission like various forms of http streaming is a different thing that jitter in the isochronous transfer between the DAC and the streamer. I don't understand mixing those things together.

 

[pablolie]

Jitter in the packet-based transmission like various forms of http streaming is a different thing that jitter in the isochronous transfer between the DAC and the streamer. I don't understand mixing those things together.

Not sure I understand your point. Different domains, same solutions. Those interfaces have PLL written all over them. The issue is irrelevant at lower than 100G interfaces these days. If we can do 800GE interfaces that are error free, we prolly can cope with 44kHz. No magic dust there. It's 1980s tech these days.

 

[Abe_W]

I bought a Wiim Pro to compare Airplay streaming against my Airport Express and I need a little objectivity because A/B testing is getting neurotic and I'm not sure if perceived differences are in my head.

The Airport Express has enough jitter that a cheaper DAC I tested can't lock the signal without skipping like a CD discman. It also has some noise injected in the signal that I only discovered thanks to this thread, but would otherwise not have noticed. The Wiim on the other hand is clean and measures great here.

The thing is, my DAC has an internal buffer and reclocks the signal. This results in no skipping/locking issues I found with the other DAC. I've been using the Airport as a streamer for the past year and thought it was great.

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?

Try this streamer from Holo Audio. It is not crazy expensive, but, it seems to make everything sound very good in my setup, at least.
https://www.kitsunehifi.com/product/holoaudio-red-ddc-network-streamer/

It is hard to fix the cheap streamer donkeys, ime.

 

[Mat]

Try this streamer from Holo Audio. It is not crazy expensive, but, it seems to make everything sound very good in my setup, at least.
https://www.kitsunehifi.com/product/holoaudio-red-ddc-network-streamer/

It is hard to fix the cheap streamer donkeys, ime.

I want to try one of those out but it's a bit too crazy expensive for me right now. One of the reasons I wanted to determine the perceived difference between a good and bad measuring streamer, before biting the bullet on 'the best' on paper at some point

 

[onlyoneme]

Not sure I understand your point. Different domains, same solutions. Those interfaces have PLL written all over them. The issue is irrelevant at lower than 100G interfaces these days. If we can do 800GE interfaces that are error free, we prolly can cope with 44kHz. No magic dust there. It's 1980s tech these days.

No retransmission in the spdif for example. No situation that download rate is much higher than playback bit rate, which let to buffer easily.

 

[onlyoneme]

I want to try one of those out but it's a bit too crazy expensive for me right now. One of the reasons I wanted to determine the perceived difference between a good and bad measuring streamer, before biting the bullet on 'the best' on paper at some point

But how to define or measure a perceived experience when talking about audibility? What's that "bad measuring streamer", how bad it should be to be considered as a "bad measuring" one? I had measurement differences for devices I've shown here including both WiiMs Mini and Pro, and I couldn't hear any difference in the same audio path.

 

[onlyoneme]

BTW, that's what ChatGPT can tell about ASRC conversion without a locking to the incoming clock:

If a device uses an Asynchronous Sample Rate Converter (ASRC) instead of recovering the clock from the incoming S/PDIF signal, it essentially decouples the input and output clock domains. In this case, the device does not rely on clock recovery, as it converts the incoming audio data to its internal clock domain.

Here's how it works:

1. The incoming S/PDIF signal is decoded, and the audio data is extracted.
2. The ASRC estimates the input sample rate based on the incoming audio data.
3. The ASRC then resamples the audio data from the input sample rate to the internal (output) sample rate using its internal clock.
4. The resampled audio data is sent to the device's DAC or other processing stages.

By using an ASRC, the device can effectively mitigate the effects of clock-related issues, such as jitter or other timing inaccuracies, in the input signal. This is because the ASRC operates independently of the input clock, relying on its internal clock for the output domain.

However, it's essential to note that ASRC performance can vary, and the quality of the resampling algorithm plays a crucial role in preserving the audio signal's integrity. High-quality ASRCs can provide excellent audio performance, while lower-quality implementations may introduce artifacts or degrade audio quality.

 

[voodooless]

By using an ASRC, the device can effectively mitigate the effects of clock-related issues, such as jitter or other timing inaccuracies, in the input signal.

But it can only work effectively if #2 properly works. Clearly in your case, it does not.