How to improve Jitter issue via USB/ETHERNET ?

[K4680]

Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

[Jean-Marie]

An interesting, if stupendously overlong, thread has emerged on CA.  Unless you have vast amounts of time to kill, I would suggest reading the first page or two, then jump to the posts from 26 March 2018, which start from page 54.

https://www.computeraudiophile.com/forum...-red-pill/

Bits are bits, yes, but bit perfect can sound different.

Fascinating, thanks for pointing this out. 

I’m only half way through the thread, and now would like to understand in detail the setup, and in particular the software player used as well as audio PC. 

Assuming that everything remains bit perfect, this would only leave (as far as I can think of) as mechanisms to explain:
1) Timing related variations
2) Electric perturbations induced by the difference of interface and protocols from which the PC is getting the bits and transmitted either through the USB interface or though the power circuit. 

Those visitation would then have to affect the behavior of the DAC (most likely) and / or the Amplifiers (less likely) in an audible manner. 

Jean-Marie

They were using XXHighEnd as the software player.  This is developed by "PeterSt", who is a regular poster in the thread.

I agree with your thoughts in points 1 & 2 by the way, but it will be interesting to see if they ever manage to objectively measure or prove the precise reason.

You have my respect if you are reading the entire thread!  There is an awful lot of bluster and nonsense to read, although maybe it's worth it for the odd gem of good information that does gets occasionally posted.

I did not read it entirely, but found out some very relevant info in post https://www.computeraudiophile.com/forum...ent=799593

[url=https://www.computeraudiophile.com/forums/topic/38493-blue-or-red-pill/?do=findComment&comment=799593][/url]Basically 1 and 2 are the same playing chain with the only diffence being one parameter in the XXHighEnd software player: the SFS parameter that was set at 0.1 for (1) and 200 for (2). 

I’m still investigating what this parameter does exactly, but it seems to be standing for Split File Size.
So it should logically determine how much the player is loading in memory before sending to the DAC. 

If my understanding is correct and the parameter is linear (like seconds, number of samples or kB) it means that the rate of I/O to the disk has a 2000 factor between the two configurations. 

It turns out that they have been using a SPDIF which is both synchronous and not galvanically isolated. 

Now what would be interesting would be to put our hands on a time capture of the spdif inputted to the DAC as well as a capture of the output through the ADC. 

Still crawling though the thread. 

Jean-Marie

[thumb5]

Bits are bits, yes, but bit perfect can sound different.

But was that ever in doubt, really?

I read the complete thread and must admit to being rather underwhelmed at the result.  It seems that the player software is designed to manipulate the low-level timing with which bits are presented to the DAC via S/P-DIF, and this timing was what explicitly changed between the A and B (1 and 2) samples tested.  Given that the DAC has to recover clock from the S/P-DIF signal and is not isolated from the source (as I understood it), it is not altogether surprising that this could result in different analog output by either or both of the mechanisms Jean-Marie pointed out.

In the end, I don't see what this tells us that we didn't already know.  Am I missing something?

ETA: kudos to manisandher and mansr on CA for actually having the guts and determination to do the test - I didn't in any way mean to under-estimate the effort that must have been involved.

[Jean-Marie]

Bits are bits, yes, but bit perfect can sound different.

But was that ever in doubt, really?

I read the complete thread and must admit to being rather underwhelmed at the result.  It seems that the player software is designed to manipulate the low-level timing with which bits are presented to the DAC via S/P-DIF, and this timing was what explicitly changed between the A and B (1 and 2) samples tested.  Given that the DAC has to recover clock from the S/P-DIF signal and is not isolated from the source (as I understood it), it is not altogether surprising that this could result in different analog output by either or both of the mechanisms Jean-Marie pointed out.

In the end, I don't see what this tells us that we didn't already know.  Am I missing something?

ETA: kudos to manisandher and mansr on CA for actually having the guts and determination to do the test - I didn't in any way mean to under-estimate the effort that must have been involved.

I agree, and the fact that the DAC is a NOS DAC makes it very susceptible to any high frequency interference via intermodulation. 

Jean-Marie

[maxijazz]

SPS and other parameters as well as operation modes for the XXHighEnd software are explained on page 10 by PeterSt.

[yabaVR]

Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

Thanx for the link. These pages should be read by everyone who wants to contribute to any thread in 'Streaming' and 'Tweaker's Corner'. A lot of questions are answered there...e.g. why USB-cabels all sound different (and more).

gui

[K4680]

Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

Thanx for the link. These pages should be read by everyone who wants to contribute to any thread in 'Streaming' and 'Tweaker's Corner'. A lot of questions are answered there...e.g. why USB-cabels all sound different (and more).

gui

Hi yabaVR, that was the idea behind it!

[thumb5]

Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

Thanx for the link. These pages should be read by everyone who wants to contribute to any thread in 'Streaming' and 'Tweaker's Corner'. A lot of questions are answered there...e.g. why USB-cabels all sound different (and more).

gui

Perhaps predictably, I beg to differ.  The article is interesting but as far as I can see it talks specifically about clock jitter in S-P/DIF and Toslink, where the audio sample clock has to be recovered from the input signal.  It is misleading to think it's directly relevant to USB and Ethernet, because these protocols are clocked completely asynchronously to the audio samples; the samples are not expected to arrive at intervals of the audio sample period.  The concept of clock or inter-sample jitter doesn't make any sense - it's simply not defined - for samples delivered asynchronously like this.  In fact you get bunches of samples all at once at more or less predictable times (more predictable on USB, less so on Ethernet), and it's up to a higher-level agreement between the sender and receiver what the time period between individual samples is supposed to be.  The receiver then has to generate an independent clock at the agreed rate to play the samples; that clock will have some degree of jitter, but in any reasonably-designed system that should be completely independent of the USB or Ethernet clock.  There could be jitter in the USB or Ethernet clock, of course, but either that results in packet errors - usually meaning drop-outs - or it has no effect on higher layers.

[Jean-Marie]

Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

Thanx for the link. These pages should be read by everyone who wants to contribute to any thread in 'Streaming' and 'Tweaker's Corner'. A lot of questions are answered there...e.g. why USB-cabels all sound different (and more).

gui

Perhaps predictably, I beg to differ.  The article is interesting but as far as I can see it talks specifically about clock jitter in S-P/DIF and Toslink, where the audio sample clock has to be recovered from the input signal.  It is misleading to think it's directly relevant to USB and Ethernet, because these protocols are clocked completely asynchronously to the audio samples; the samples are not expected to arrive at intervals of the audio sample period.  The concept of clock or inter-sample jitter doesn't make any sense - it's simply not defined - for samples delivered asynchronously like this.  In fact you get bunches of samples all at once at more or less predictable times (more predictable on USB, less so on Ethernet), and it's up to a higher-level agreement between the sender and receiver what the time period between individual samples is supposed to be.  The receiver then has to generate an independent clock at the agreed rate to play the samples; that clock will have some degree of jitter, but in any reasonably-designed system that should be completely independent of the USB or Ethernet clock.  There could be jitter in the USB or Ethernet clock, of course, but either that results in packet errors - usually meaning drop-outs - or it has no effect on higher layers.

Absolutely, and it is interesting to note that in the blue pill vs red pill case, spdif was used, therefore a synchronous coupling between the DAC and the player. 

Jean-Marie

[yabaVR]

Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

Thanx for the link. These pages should be read by everyone who wants to contribute to any thread in 'Streaming' and 'Tweaker's Corner'. A lot of questions are answered there...e.g. why USB-cabels all sound different (and more).

gui

Perhaps predictably, I beg to differ.  The article is interesting but as far as I can see it talks specifically about clock jitter in S-P/DIF and Toslink, where the audio sample clock has to be recovered from the input signal.  It is misleading to think it's directly relevant to USB and Ethernet, because these protocols are clocked completely asynchronously to the audio samples; the samples are not expected to arrive at intervals of the audio sample period.  The concept of clock or inter-sample jitter doesn't make any sense - it's simply not defined - for samples delivered asynchronously like this.  In fact you get bunches of samples all at once at more or less predictable times (more predictable on USB, less so on Ethernet), and it's up to a higher-level agreement between the sender and receiver what the time period between individual samples is supposed to be.  The receiver then has to generate an independent clock at the agreed rate to play the samples; that clock will have some degree of jitter, but in any reasonably-designed system that should be completely independent of the USB or Ethernet clock.  There could be jitter in the USB or Ethernet clock, of course, but either that results in packet errors - usually meaning drop-outs - or it has no effect on higher layers.

This is a assumption on your side.
In theory everything is clear as day but if you compare two different brands of USB cables (each of the same length e.g. 1m) you get two different results in sound.
I even don't say one has to better than the other (well...it has to be...otherwise there's no difference) but you can clearly distinguish sound differences in one over the other (how to weight them is to you). This differences to a large degree comes from cable induced jitter (ok, this is my opinion but in common with many others). By your theory it should have no effect but even similar designed USB-cables sound different and it is the same with Ethernet-cables (at least my experience over many years in the business).
Now...can you fool someone/yourself in an AB session. Sure you can and even in an ABX session. There's no perfection. But it is most unlikely you are fooled or fool yourself within 30 years again and again.
If my experience is confirmed on every new occasion I don't care about old written theory...I'd care about new theories that explain what I'm experiencing...I want to know.

gui