[Zoide]

Is there any relation between the sampling rate (eg. by resampling in foobar) and the effect of jitter when using an external DAC?

I would suppose that these would be related, since jitter involves timing errors and sampling rate basically tells us how many samples there are per second.

I would suppose that if at a higher sampling rate we are sending more samples per second, the effect of jitter could be less noticeable. In a way, there would be more redundancy in terms of the sound information.

Then again, I'm not really qualified to make these comments. Hence my question to those who'd really know

 

[Mr.Radar]

[Guess]I'd think that with high samplerates that jitter would be more of a problem because the data needs to travel faster over the connection and the timing needs to be even more precise than with lower samplerates[/guess]

 

[Publius]

Increasing the sample rate with a fixed amount of jitter can't, a priori and IMHO, reduce the audibility of the jitter; in the best case, it would simply move around the modulation spectrum to a less audible area, because jitter extending beyond fs/2 would be mirrored back.

In reality, I would expect data jitter (due to trace capacitance) to increase quickly with sampling rate increases. I'm working on measuring these effects with my RME in loopback using extremely long FFTs. Preliminary results are... interesting. And forthcoming.

 

[thomaspf]

If I recall this correctly there is an inverse relationship between the threshold for audible impact of jitter and the sample rate.

If have read in some AES paper that the impact of jitter on the waveform becomes negligible for 16/44.1 data when the jitter is lower than 10-15ps.

If you go to 96Khz sample rate than you need even lower jitter.

For the higher sample rates I don't know whether the imperfections in the wave form manifest themselves only in the higher frequencies or impact the whole spectrum.

Cheers

Thomas
P.S. Publius, are the ADC and the DAC on the RME card independently clocked?

 

[MiChael.]

Quote:

Originally Posted by Mr.Radar [Guess]I'd think that with high samplerates that jitter would be more of a problem because the data needs to travel faster over the connection and the timing needs to be even more precise than with lower samplerates[/guess]

Heh, by that theory SACD might be quite bitch, its samplerate is 2822.4khz

 

[thomaspf]

Since the conversion principle on DSD is quite different from a PCM converter that is not necessarily the case and I do not know how jitter in the DSD stream manifests itself in the waveform.

However, I do understand that DSD converters produce a dramatically higher degree of high frequency noise in the ultrasonic range and have lower S/N ratio over 15Khz. Newer design apply more signal processing to compensate for that problem but it is still there.

I recall reading some lively discussions between Lip****z/Vanderkooy and Reefman.

Cheers

Thomas

 

[Wodgy]

Quote:

Originally Posted by Publius In reality, I would expect data jitter (due to trace capacitance) to increase quickly with sampling rate increases. I'm working on measuring these effects with my RME in loopback using extremely long FFTs. Preliminary results are... interesting. And forthcoming.

Publius, I'd be very interested in seeing your results. Be sure to post them when they're finished.

 

[Wodgy]

Quote:

Originally Posted by thomaspf If have read in some AES paper that the impact of jitter on the waveform becomes negligible for 16/44.1 data when the jitter is lower than 10-15ps.

That seems like a very challenging threshold to meet from an engineering perspective. e.g. TI claims that DIR1701 averages 80ps of jitter but doesn't go into details in the datasheet; most other receivers claim at least three times that amount of jitter.

Do you, perchance, have a link to the paper or the abstract? I'd be very interested in reading it.

 

[Publius]

I don't have the original paper itself, but this is a very informative article that mentions the results.

 

[Publius]

Quote:

Originally Posted by Wodgy Publius, I'd be very interested in seeing your results. Be sure to post them when they're finished.

I'll post them as soon as I'm comfortable with them. There are just way too many systemic pitfalls I'm figuring out that prevent me from making any sort of hard performance statement right now. The results will certainly be a lot messier than those cute pretty jitter graphs in Stereophile, that's for sure, but they should definitely be useful and validatable.

To answer Thomas's question: I honestly have no idea. If by what you mean is that I can play at 48k and record at 96k, then yes, they are independently clockable. If you're asking if they're using two completely separate clock systems (including the crystal), I strongly suspect not, although in the pictures it sort of looks like there's both a crystal AND an oscillator on board - no clue what's going on there. (I'm too lazy to take my case off and look at the board myself right now.)

 

[thomaspf]

Hi Publius,

this seems to indicate that the input and output are actually independent. I would probably verify this and see whether you can record a 44.1Khz signal at 96Khz.

If the ADC is in any form correlated to the clock of the sending DAC, then trying to measure jitter might not be very successful since the same jitter would apply in the same way to both in a loopback configuration.

Cheers

Thomas

 

[Publius]

Quote:

Originally Posted by thomaspf Hi Publius, this seems to indicate that the input and output are actually independent. I would probably verify this and see whether you can record a 44.1Khz signal at 96Khz. If the ADC is in any form correlated to the clock of the sending DAC, then trying to measure jitter might not be very successful since the same jitter would apply in the same way to both in a loopback configuration. Cheers Thomas

I realize that. The general problem is that recording jitter essentially performs the inverse operation of playback jitter on the sound, so even if I had playback and recording on two completely separate systems with different sound cards, any common jitter modulation lines would be attenuated - it's not just playback and record on the same card. One could test with a matrix of different cards to try and characterize jitter lines as being specific to one card, but even then you're basically hosed on any common component (like, say, 60hz).

One idea I'm considering is to use the phase information to better classify the results. Jitter lines due to recording should be of an opposite "polarity" than lines due to playback. The big catch here is that amplitude modulation lines may look pretty similar to each of them under the right circumstances, so either I'd need to assume they don't exist or do some more clever footwork.