(01-Apr-2018, 10:43)Confused Wrote:

(01-Apr-2018, 09:29)Jean-Marie Wrote:

(01-Apr-2018, 09:03)Confused Wrote: 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/forums/topic/38493-blue-or-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.

(01-Apr-2018, 09:03)Confused Wrote: Bits are bits, yes, but bit perfect can sound different.

(01-Apr-2018, 13:38)thumb5 Wrote:

(01-Apr-2018, 09:03)Confused Wrote: 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.

(01-Apr-2018, 11:28)K4680 Wrote: Hi, worth knowing about jitter etc!
http://www.jitter.de/english/engc_navfr.html

(02-Apr-2018, 14:22)yabaVR Wrote:

(01-Apr-2018, 11:28)K4680 Wrote: 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

(02-Apr-2018, 14:22)yabaVR Wrote:

(01-Apr-2018, 11:28)K4680 Wrote: 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

(02-Apr-2018, 15:04)thumb5 Wrote:

(02-Apr-2018, 14:22)yabaVR Wrote:

(01-Apr-2018, 11:28)K4680 Wrote: 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.

(02-Apr-2018, 15:04)thumb5 Wrote:

(02-Apr-2018, 14:22)yabaVR Wrote:

(01-Apr-2018, 11:28)K4680 Wrote: 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.