I agree but that adds complexity and like I said I'm aiming at an implementation with a good effort/results ratio.
Jitter slightly changes sample duration, this could be compared with a form of PWM. With PWM we can change the exact amount of energy a pulse or sample holds. In digital audio it causes bit errors. Max. allowable timing fluctuations can be calculated when sample rate, oversampling factor, bit depth and tolerable bit errors are specified.
Max. allowable timing errors for max. allowable bit errors can be calculated by following formula:
1 / (sample rate * oversampling factor) / (bit depth / (1 / allowed bit error)).
For 44.1/16 NOS and max. tolerable bit error of 0.5 LSB (15.5 bit resolution), gives 1 / (44,100 * 1) / (2^16 / (1 / 0.5)) = 173ps. For verification, this calculated value is also specified by Kusunoki:
kusunoki
Similar for:
44.1/16 NOS, 0.1 LSB (15.9 bit resolution), 1 / (44,100 * 1) / (2^16 / (1 / 0.1)) = 34.6ps.
44.1/16 NOS, 0.01 LSB (15.99 bit resolution),1 / (44,100 * 1) / (2^16 / (1 / 0.01)) = 17.3ps.
44.1/16, 8 * oversampling, 0.5 LSB error (15.5 bit resolution), 1 / (44,100 * 8) / (2^16 / (1 / 0.5)) = 21.625ps.
44.1/16, 8 * oversampling, 0.1 LSB error (15.9 bit resolution), 1 / (44,100 * 8) / (2^16 / (1 / 0.1)) = 4.32ps.
44.1/16, 8 * oversampling, 0.01 LSB error (15.99 bit resolution), 1 / (44,100 * 8) / (2^16 / (1 / 0.01)) = 432 femtoseconds.
96/24 NOS, 0.5 LSB (23.5 bit resolution), 1 / (96,000 * 1) / (2^24 / (1 / 0.5)) = 310 femtoseconds.
96/24 NOS, 0.1 LSB (23.9 bit resolution), 1 / (96,000 * 1) / (2^24 / (1 / 0.1)) = 62 femtoseconds.
96/24 NOS, 0.01 LSB (23.99 bit resolution), 1 / (96,000 * 1) / (2^24 / (1 / 0.01)) = 6.2 femtoseconds.
96/24 8 * OS, 0.5 LSB (23.5 bit resolution), 1 / (96,000 * 8) / (2^24 / (1 / 0.5)) = 38.8 femtoseconds.
96/24 8 * OS, 0.1 LSB (23.9 bit resolution), 1 / (96,000 * 8) / (2^24 / (1 / 0.1)) = 7.76 femtoseconds.
96/24 8 * OS, 0.01 LSB (23.99 bit resolution), 1 / (96,000 * 8) / (2^24 / (1 / 0.01)) = 776 attoseconds.
192/24 NOS, 0.5 LSB (23.5 bit resolution), 1 / (192,000 * 1) / (2^24 / (1 / 0.5)) = 155 femtoseconds.
192/24 NOS, 0.1 LSB (23.9 bit resolution), 1 / (192,000 * 1) / (2^24 / (1 / 0.1)) = 31 femtoseconds.
192/24 NOS, 0.01 LSB (23.99 bit resolution), 1 / (192,000 * 1) / (2^24 / (1 / 0.01)) = 3.1 femtoseconds.
192/24 8 * OS, 0.5 LSB (23.5 bit resolution), 1 / (192,000 * 8) / (2^24 / (1 / 0.5)) = 19.4 femtoseconds.
192/24 8 * OS, 0.1 LSB (23.9 bit resolution), 1 / (192,000 * 8) / (2^24 / (1 / 0.1)) = 3.88 femtoseconds.
192/24 8 * OS, 0.01 LSB (23.99 bit resolution), 1 / (192,000 * 8) / (2^24 / (1 / 0.01)) = 388 attoseconds.
Here are some jitter measurements on practical digital playback systems:
What Slaving Does : LessLoss high end audio power cables, audiophile power cables, audiophile cables
Imagine we have a top performance 192/24 DAC with slaved source that manages to achieve max. 20ps timing error.
According to above formula this would leave approx. 13.5 error-free bits with given jitter amplitude of 20ps.
Based on these calculations I think jitter could make a difference.
The audible impacts are more resolution, better transparency and less distortion. In order to understand what this exactly means, visit a live performance of classical music for example, then listen to similar music on your audio set and find the differences.
Last edited:
Could we agree on the following:
Asynchronous reclocking using multiple cascaded flip-flops and a low jitter clock for reclocking can't lower output clock jitter amplitude below that of the source clock and introduces extra jitter.
Synchronous reclocking using one single flip-flop can lower output sampling jitter amplitude below that of the source clock, provided flip-flop setup times are met.
Buffer memory needs a controller that generates interference and causes crosstalk (EMI, power supply, stray capacitance), you have at least 2 non-synchronized clocks in this system (source clock from the incoming data, and local masterclock). Unless crosstalk is 100% blocked, throughout the entire circuit, I doubt that this approach results in desired jitter reduction.
Example, we designed a digital audio source, based on solid-state memory card that produced as little interference and jitter as possible. Even software loops and controller load were meticulously tuned to minimize interference. The controller was almost idling during playback. This source is very small and can be easily integrated with a DAC, both sharing a single ultra low jitter masterclock.
This way, all circuits, SD-card, processors, synchronous reclockers, DAC chip always run fully synchronized and there is little or no source jitter to block because it is already very low.
I used discrete ultra low noise voltage regulators with very high bandwidth and resolution, capacitance multipliers for attenuating ripple voltage, and 3-stage stepped rectifiers to minimize diode rectifier switching noise.
With this seemingly ideal setup we don't even have to bother about ground loops, interlink issues, source noise, jitter, and EMI generated by WiFi microwaves. Still it turned out to be extremely difficult to meet or improve on target jitter levels of 17.3ps.
I think you overestimate the influence of the controller crosstalk. At lest you can design as best you can to neutralize those influences. You have a controller in ANY player/transport regardless, bits don't move by themself to the DAC.
Source jitter cannot be eliminated other way, but with a memory cache IMO - if the source was at ANY point an optical medium (read by an optical laser assy).
Agree with you on the async flip-flop statement.
Disagree on the sync D-FlipFlops statement - those "timings" are the issue. They cannot be kept in the proper "position" without a PLL loop to sync the local clock to the input one. And in this way you will still have the incoming jitter influence and you add the PLL own jitter.
Also you calculations for the jitter tolerance are... biased towards NOS.
There is no influence of the NOS or OS mode in the jitter tolerance. The only real influence factors are the initial samplerate and desired bitdepth error.
Oversamplig factor that you introduced in there, would have to be introduced also in the numerator of the fractions, because if it is done corectly it is also multiplying the number of the bits with the same factor:
1 / (sample rate * oversampling factor) / (bit depth * oversamplig factor/ (1 / allowed bit error)) = 1 / (sample rate) / (bit depth / (1 / allowed bit error))
Source jitter cannot be eliminated other way, but with a memory cache IMO - if the source was at ANY point an optical medium (read by an optical laser assy).
Agree with you on the async flip-flop statement.
Disagree on the sync D-FlipFlops statement - those "timings" are the issue. They cannot be kept in the proper "position" without a PLL loop to sync the local clock to the input one. And in this way you will still have the incoming jitter influence and you add the PLL own jitter.
Also you calculations for the jitter tolerance are... biased towards NOS.
There is no influence of the NOS or OS mode in the jitter tolerance. The only real influence factors are the initial samplerate and desired bitdepth error.
Oversamplig factor that you introduced in there, would have to be introduced also in the numerator of the fractions, because if it is done corectly it is also multiplying the number of the bits with the same factor:
1 / (sample rate * oversampling factor) / (bit depth * oversamplig factor/ (1 / allowed bit error)) = 1 / (sample rate) / (bit depth / (1 / allowed bit error))
Last edited:
There is no doubt that jitter can make a difference. The question is; how much jitter is audible?
The figures you calculate (173 pS @ 16/44k1) correspond to a timing error equivalent to 1/2 LSB amplitude error, 1/2 LSB being considered an acceptable error for CDs.
Reading the study by Ashikara et. al. they calculate a more demanding standard of 121pS for a 20kHz recorded signal, based on the maximum slope of the signal. In this case the jitter is random, and it's effect would surely be inaudible to the majority of the population outside their teens. Experimentally (in controlled listening tests) they discovered a threshold of 250nS for random jitter.
http://www.jstage.jst.go.jp/article/ast/26/1/50/_pdf
Hawksford & Dunn OTOH http://www.scalatech.co.uk/papers/aes93.pdf suggest that modulated jitter mixes down to lower frequencies in the audio band and that jitter as low as 20pS at 18.5kHz on a recorded tone of 22kHz is audible (this for 16/44k1).
The study by Benjamin and Gannon, while criticised for it's methodology, which, it was suggested, led to an exaggeratedly low threshold for audibility, nevertheless found in listening tests that modulating jitter only became audible around 10-20nS.
CDs were designed to achieve a bandwidth just better than the capacity of human hearing at its best, and a dymanic range well in excess of that encountered in a concert hall, so to suggest that the calculation you have made is applicable to 24-bit systems is questionable. Systems rarely exceed 20 bits of true resolution, 20 bits =~120dB of SNR, and the LSB of a 24-bit system is certainly inaudible.
w
Your question, as worded, presents a False Dichotomy. Sampled audio is two-dimensional because it involves a quantized amplitude and a defined timeline. It is possible for the quantized amplitude to be bit-perfect while still introducing harmonics that were not part of the original, all due to the errors in the defined timeline.
In other words, the answer to your question is: "Both."
How does a slaved DAC detect the track boundary on a CD?
It's far better to slave the media to the DAC than to try slaving the DAC to the media source.
How big of a burst are you talking about? A whole song? A tiny fraction of a second?
If you only mean to burst a tiny fraction of a second of audio, then that's exactly how computer audio works everywhere (as opposed to CD player and SPDIF standards).
If you're describing bursting much longer blocks than are already being used, then it's really overkill. Also, the disadvantage of larger blocks is the latency involved. This is particularly problematic when the audio needs to be synchronized with video.
All you need to do is slave the media source to the DAC. With FireWire, ethernet, and modern USB, that's easy. By 'modern' USB, I referring to the fact that USB Audio has allowed async since 1998. Just because interfaces only started showing up last year doesn't mean it wasn't fully possible for a decade or more.
Jitter is just as important as the difference between 16-bit and 24-bit. Of course, if your DAC is 16-bit to start with, then jitter could reduce its effective quantization performance far below 16-bit accuracy. To say that jitter doesn't really make any difference is almost exactly the same as saying it doesn't matter whether you use a 12-bit DAC or 24-bit DAC. Keep in mind that an audio waveform is two-dimensional; moving a point by changing its voltage quantization is no less destructive than moving that same point by maintaining a precise voltage but moving it forward or backward in time. In either case, the curve is changed, and distortion results.
I agree with the second part of your sentence, though.
That they were not present in the original bits is undisputed. However to continue to use the term 'harmonics' when by no stretch of imagination could they be at integer multiples of the original frequency is just propagating misleading terminology. How about 'unwanted additional frequencies' ?
Agreed. 24-bit is very important for recording and mastering, but any listening room is going to have fewer than 20 bits of resolution regardless of the DAC quality. That's based on the simple physics of ambient noise, the threshold of human hearing, and the maximum comfortable SPL.
Its also misleading to characterise a digital audio signal chain in terms of 'resolution' (though it is indeed very popular to do so). As a competently engineered system uses TPF or even Gaussian dither, the system really needs to be characterized by its noise floor rather than its resolution. Use of the correct dither gives resolution below the LSB however many bits are used.
Having said that, I do agree with you that 20bits of dynamic range are more than adequate. 😀
What? Nooo... Corect dither gives resolution down to the last LSB, not below.
Well, yes. But that doesn't stop the DAC manufacturers to manufacture the "32 bit DAC's" (Sabre, TI, Wolfson).
That is an urban legend. If you try to rigidly "lock" the optical media player to the DAC xtall, how can you adjust for the laser pickup iregularities? The spindle motor will not spin perfect all the time, tracking will not be perfect all the time, all those induce small variations in instanteneous rotational speed and therfore jitter in the data stream. Uless the transport has some kind of buffer memory and mechanism to use it (like an IDE optical drive that might have 2MB cache), you cannot directly sync the pickup mechanism with a fixed external frequency. Not without a PLL loop. All the cipsets used to drive optical trasports have that PLL loop integrated. So just slaving the transport with the external DAC alone will NOT give better results than internal xtall - unless the optical drive itself has cache memory (I have only one DVD player that uses an IDE drive - DSL 710A).
So the main issue is the buffer memory and how big is necessary to be. Slaving is not solving the jitter problem.
Last edited:
So then, according to you an SAA7350/TDA1547 DAC has only one bit resolution?
Haven't seen TI or Wolfson's 32 bit offerings. Got any links to share? [I'm not counting PCM1795 which is obviously a fudge 😛]
Errata: An IDE optical drive in the WRITING mode is slaved to the source frequency and thats why have 2MB cache - to compensate for the eventual differences in the two data streams (the one coming from the source and the one efectily gooing on to the disc). But that buffer is not used for reading.
TI has just that PCM1795. It is a 24 bit DAC with the interface modified to accept 32 bit words.
There is no DAC capable more than 22 bit effective individual resolution. Even Sabre is not better than that without paralleling all 8 internal DAC's.
And yes, a delta-sigma DAC has just 1 bit resolution. But that bit is not PCM, is serial delta-sigma, you cannot compare directly the bit number with a 16-24 bit parallel PCM. The same like the DSD signal if you like.
TI has just that PCM1795. It is a 24 bit DAC with the interface modified to accept 32 bit words.
There is no DAC capable more than 22 bit effective individual resolution. Even Sabre is not better than that without paralleling all 8 internal DAC's.
And yes, a delta-sigma DAC has just 1 bit resolution. But that bit is not PCM, is serial delta-sigma, you cannot compare directly the bit number with a 16-24 bit parallel PCM. The same like the DSD signal if you like.
Last edited:
My understanding is that, at least for lower audio frequencies, correct dither gives resolution below LSB. In principle, given a 1-bit converter and the right sort of noise, you can measure a DC level to arbitrary precision. You are basically relying on the Central Limit Theorem. The same applies in modified form to a changing signal.
So what do you mean by 'resolution'?
Why not? As far as I can see, the only difference is the dither - with bitstream the dither is out of band whereas with multibit, its in-band. So how about 6bits delta-sigma like the BB/AD oversampled DACs? Also not parallel PCM in your book?
I suggest that these "unwanted frequencies" be viewed as what they most resemble; intermodulation products. While the resulting images are not integer multiples in harmonic distortion terms, they do appear to act just like any other intermodulation products. They are mathematically defined by the sum and difference of the sampling frequency and the signal frequency. The sampling frequency acts much like a carrier wave and the baseband signal (the audio) acts much like a modulating element.
Last edited:
Depends of the money that studio has 🙂
One manufacturer example:
ADC16 at 4000USD.
System1000 with one of those ADC.
Last edited:
Reads like classic salesman's Fear, Uncertainty and Doubt. In order to sell a solution to a problem, first you have to exaggerate it so the victim feels he must be really stupid not to have noticed it for himself.
- Status
- Not open for further replies.