Blue or red pill?

[sandyk]

8 minutes ago, STC said:

You could be right about error correction as my knowledge about the workings of DAC is next to zero. Yet, it is hard to accept that digital comes without error correction.

 

 If there are errors in the Coax SPDIF stream to the DAC they will not be corrected in the DAC, and are likely to be heard as tiny clicks or missing samples etc.( IF they are even noticed.)

 Capturing the Analogue Output involves another conversion to a Digital File, and the differences are then either likely to be greatly reduced or not even heard.

[pkane2001]

7 minutes ago, STC said:

 

Capturing the analogue output proves nothing. If you heard a differences than what was coming out the analogue output must be different. 

 

Measure ( if that’s ever possible) what’s reaching before the conversion takes possible. 

 

You could be right about error correction as my knowledge about the workings of DAC is next to zero. Yet, it is hard to accept that digital comes without error correction. 

 

SPDIF carries with it inherent timing issues that will not be revealed in a digital capture. The clock that controls the output of samples at the DAC is derived from the SPDIF signal, in other words, fully subject to errors, noise, and other issues before or at the receiver part (such as a poorly implemented PLL).

 

An asynchronous receiver, such as used with USB, will eliminate most, if not all such issues by buffering the incoming data and using a local clock to control the timing of the output from the buffer.

[manisandher]

10 minutes ago, STC said:

You could be right about error correction as my knowledge about the workings of DAC is next to zero. Yet, it is hard to accept that digital comes without error correction. 

 

As a number of people have already said  (including Alex above)...

 

S/PDIF has no error CORRECTION. It has a parity bit to allow the receiver to detect errors, but there is no way of correcting errors once they've occurred.

 

The fact that all the digital captures were bit-identical proves that the DAC was receiving bit-identical data at its S/PDIF input, and that there were indeed no bit errors.

 

6 minutes ago, pkane2001 said:

The clock that controls the output of samples at the DAC is derived from the SPDIF signal, in other words, fully subject to errors, noise, and other issues before or at the receiver part (such as a poorly implemented PLL).

 

Totally accepted.

 

Mani.

[Summit]

S/PDIF has no error correction because it’s not needed, if had been an issue no one would use S/PDIF. It’s always best to send a signal that doesn’t need to be corrected in the first place.  

[PeterSt]

1 hour ago, STC said:

If I am not mistaken the DAC used in the Altmann DAC was PCM1604 which is rather dated and the error correction if any may not be as good as modern chips.

 

For clarification :

 

DAC chips don't do error correction.

DACs as a whole (as in : the complete design) also do not. A digital connection could but this is from transceiver to transceiver.

[STC]

31 minutes ago, PeterSt said:

 

For clarification :

 

DAC chips don't do error correction.

DACs as a whole (as in : the complete design) also do not. A digital connection could but this is from transceiver to transceiver.

 

41 minutes ago, manisandher said:

S/PDIF has no error CORRECTION. It has a parity bit to allow the receiver to detect errors, but there is no way of correcting errors once they've occurred.

 

41 minutes ago, manisandher said:

 

As a number of people have already said  (including Alex above)...

 

S/PDIF has no error CORRECTION. It has a parity bit to allow the receiver to detect errors, but there is no way of correcting errors once they've occurred.

 

The fact that all the digital captures were bit-identical proves that the DAC was receiving bit-identical data at its S/PDIF input, and that there were indeed no bit errors.

 

 

Totally accepted.

 

Mani.

 

Thanks guys for putting up with me. 

 

I understand that that Spdif implement unidirectional protocol and therefore it cannot correct the data. 

 

I am am looking at the function of the CRC itself. For an example, does Tascam implement a different type of CRC compared to the TDA1543 DAC? 

 

If you you look at analogue device DAC they implement CRC in the form of  packet error check. There are several method employed to detect errors and the difference in them could account for the difference in SQ. 

 

I am unable to connect the dots here but in digital filming a different kind of error detection is used due to the impossiblity to request for the data to be sent again. So is the any difference between error detection method between the Tascam and Altmann?

 

sorry for being a pain in you know where.  

[mansr]

20 minutes ago, STC said:

I am am looking at the function of the CRC itself. For an example, does Tascam implement a different type of CRC compared to the TDA1543 DAC? 

There is no CRC, only a single parity bit per sample. What the receiver does if it detects an error can of course differ, but we have no reason to believe any errors occurred during the test.

[PeterSt]

1 hour ago, STC said:

I understand that that Spdif implement unidirectional protocol and therefore it cannot correct the data. 

 

FYI and hopefully not more confusion : Isochronous USB (which is what a USB DAC would normally use) also doesn't do error correction (it may steer the USB transfer speed though).

[pkane2001]

29 minutes ago, PeterSt said:

 

FYI and hopefully not more confusion : Isochronous USB (which is what a USB DAC would normally use) also doesn't do error correction (it may steer the USB transfer speed though).

 

It can also detect an error and drop a micro frame containing a few samples. Or, try to do some interpolation/guessing to make up for the samples in the frame that's in error.

 

[STC]

7 hours ago, pkane2001 said:

 

It can also detect an error and drop a micro frame containing a few samples. Or, try to do some interpolation/guessing to make up for the samples in the frame that's in error.

 

 

(Scratching head emoticon)..... so got error correction?

[STC]

9 hours ago, mansr said:

What the receiver does if it detects an error can of course differ

 

So Tascam and the DAC can differ? A remote possibility? 

[pkane2001]

8 minutes ago, STC said:

 

(Scratching head emoticon)..... so got error correction?

 

Not correction, detection. To correct a bad packet retransmission would be required and that is not allowed in isochronous protocol.

[STC]

4 minutes ago, pkane2001 said:

 

Not correction, detection. To correct a bad packet retransmission would be required and that is not allowed in isochronous protocol.

 

 But interporpolation is a form of guessing what a bad data should have been. I may have mistakenly thought this is some form of error correction.

[pkane2001]

4 minutes ago, STC said:

 

 But interporpolation is a form of guessing what a bad data should have been. I may have mistakenly thought this is some form of error correction.

 

Interpolation is intelligent guessing, it'll almost never be exactly right but can get close. The protocol does not specify what should be done with bad packets. I assume in most cases, they will just be skipped.

[STC]

16 minutes ago, pkane2001 said:

 

Interpolation is intelligent guessing, it'll almost never be exactly right but can get close. The protocol does not specify what should be done with bad packets. I assume in most cases, they will just be skipped.

 

Paul, Isn't it true that DAC need to process the data continuously unlike the recorder where it can take extra few micro seconds to write the data. All DAC do have a sample buffer to collect the adequate data to prevent buffer underrun. The size of the buffer also responsible for latency. 

 

Now going back to the data coming from XXHE, can the SFS influence how much data reaches the DAC's sample buffer. Whether the smaller SFS creates more errors or delays in the sample buffer which translates to different latency and becomes audible?

[pkane2001]

8 minutes ago, STC said:

 

Paul, Isn't it true that DAC need to process the data continuously unlike the recorder where it can take extra few micro seconds to write the data. All DAC do have a sample buffer to collect the adequate data to prevent buffer underrun. The size of the buffer also responsible for latency. 

 

Now going back to the data coming from XXHE, can the SFS influence how much data reaches the DAC's sample buffer. Whether the smaller SFS creates more errors or delays in the sample buffer which translates to different latency and becomes audible?

 

DAC does, but the incoming data doesn't have to be in a continuous stream. In USB isochronous protocol (that's what we are still talking about, right?) the data is sent in small packets every 125µs, on the dot. Each packet contains a number of samples, and the number can be increased or decreased by one if the buffer is filling up too slowly or too quickly. The receiver on the DAC side decides to increase or to decrease packet size and communicates with the PC to do so.

 

The DAC itself is driven entirely by an internal clock that expects the buffer to at least have one sample left in it at the next clock cycle. If, despite the sample adjustments the buffer runs empty or overflows, samples will be lost, but that's an unusual condition and will result in audible clicks and pops.

 

[STC]

4 minutes ago, pkane2001 said:

The receiver on the DAC side decides to increase or to decrease packet size and communicates with the PC to do so.

 

So with SPDIF it is possible for the DAC to communicate to the PC?

[pkane2001]

Just now, STC said:

 

So with SPDIF it is possible for the DAC to communicate to the PC?

 

No.

[STC]

1 minute ago, pkane2001 said:

 

No.

 

 That means the Altmann DAC couldn't tell the pc to send the desired packet size. Can now the different SFS affcts the data in sample buffer? Or that is irrelevant....

[esldude]

2 minutes ago, STC said:

 

 That means the Altmann DAC couldn't tell the pc to send the desired packet size. Can now the different SFS affcts the data in sample buffer? Or that is irrelevant....

DAC has PLL or several or ASRC to keep time with the SPDIF timing.  If the SPDIF timing is wavering from jitter or some weird software interaction on the sending card or via polluting the PLL or the even via noise getting to the DAC clock itself then it could have analog consequences.  Assuming Mani didn't just get super lucky (still possible) something changed in the output.  The quest is to find out what was different in the analog signal and how it was changed. 

[pkane2001]

5 minutes ago, STC said:

 

 That means the Altmann DAC couldn't tell the pc to send the desired packet size. Can now the different SFS affcts the data in sample buffer? Or that is irrelevant....

Sorry, all we been discussing for the past few hours is USB, not SPDIF.

 

SPDIF is a very different protocol. The timing is controlled entirely by the PC. The data is sent continuously and the clock is embedded in the  data signal. This means the timing of the data must be very well controlled by the PC. There is simple parity check, but that does not help with timing errors. If the source clock is poor or noisy, the output of the dac will be jittery. 

[esldude]

Here is an example.  The DAC is the same in both cases.  In one case it is fed via a very poor SPDIF source in red, and by a good SPDIF source in green.  Toslink in both cases so it isn't electrical noise leakage.  1 khz, 11.025 khz and a max level twin tone IMD signal.  Notice the 1 khz difference tone in the IMD signal is 35 db higher with the poor SPDIF source.   Though not something you can tell from these graphs, the noise floor is heavily modulated by signal level. 

 

 

 

 

 

[STC]

Thank you Paul and Dennis. This is bit out of my depth. Thank you for your indulgence.

[opus101]

11 minutes ago, esldude said:

The DAC is the same in both cases

 

What's the DAC chip? Different chips have different susceptibility to jitter.

[esldude]

Just now, opus101 said:

 

What's the DAC chip? Different chips have different susceptibility to jitter.

I don't remember.  The DAC is an old Tact RCS 2.0 which has fair ability to reject jitter.  It isn't highly susceptible.  In fact I've tried it with many different sources and jitter signal plots look the same with only two exceptions.  The one graphed here.  And a Pioneer DVD player which on CD has huge tremendous levels of jitter whenever you switched tracks, but smoothed right out to a pretty low level by the 15 second mark.