I can't help it, I guess... I remain fascinated by this whole jitter issue, particularly with the belief that computer load can somehow alter the jitter/timing characteristic of a digital interface. After years of talk in the press about jitter, there's almost a mystique about this phenomenon. After all, jitter seems to be the central tenet to the concept that "bits are not just bits" because there is a timing component which somehow gets altered by the transport of said bits into the DAC for playback... As I have alluded in previous posts, software-side techniques to reduce timing errors have been reported to include:
- strip down OS'es - prevent unnecessary processes from running
- prefer simpler/older OS'es like Windows XP, or alternate OS like Linux with RT kernels
- use large memory buffers
- specialized music player software which presumably go beyond bit perfect
- play only WAV / AIFF files (ie. FLAC decoding can add jitter)
Closely related hardware mods include:
- use SSD instead of HD
- slower/faster RAM
- slower/faster CPU & FSB
While I would not be able to test out all these assertions, I think we can logically deduce that IF timing is an issue and can be altered by computer load (whether due to OS, player software, FLAC decode, etc...), we should see some kind of anomaly with the Dunn J-Test when the computer gets busy in realtime.
Here's a video showing realtime analysis of my computer's motherboard TosLink audio sent to the AUNE X1 DAC.
Setup: i7-3770K + ASrock Z77 Extreme4 TosLink (Win 8, no special tweaks) --> standard plastic TosLink --> AUNE X1 DAC --> shielded RCA --> E-MU 0404USB
- strip down OS'es - prevent unnecessary processes from running
- prefer simpler/older OS'es like Windows XP, or alternate OS like Linux with RT kernels
- use large memory buffers
- specialized music player software which presumably go beyond bit perfect
- play only WAV / AIFF files (ie. FLAC decoding can add jitter)
Closely related hardware mods include:
- use SSD instead of HD
- slower/faster RAM
- slower/faster CPU & FSB
While I would not be able to test out all these assertions, I think we can logically deduce that IF timing is an issue and can be altered by computer load (whether due to OS, player software, FLAC decode, etc...), we should see some kind of anomaly with the Dunn J-Test when the computer gets busy in realtime.
Here's a video showing realtime analysis of my computer's motherboard TosLink audio sent to the AUNE X1 DAC.
Setup: i7-3770K + ASrock Z77 Extreme4 TosLink (Win 8, no special tweaks) --> standard plastic TosLink --> AUNE X1 DAC --> shielded RCA --> E-MU 0404USB
(Notice a few hiccups with the realtime spectrum analyzer... Quite alot of numbers to be crunched to plot out the 131,072 point FFT while recording video and audio.)
Realize just how "basic" this setup is... I'm using just the built-in motherboard TosLink straight to the $200 DAC.
As I have shown so far in the other tests, jitter is measurable between different interfaces. Also, electrical noise is easily measurable (for example, see the "NOISY i7" condition with the Essence One testing). However, I am still unable to show that multitasking or running the CPU at high load has any ability to change the timing/jitter characteristics of the Dunn J-Test significantly much less to an audible degree. As far as I can tell, the jitter phenomenon is a property of the digital hardware interface itself (ie. TosLink and adaptive USB tend to be worse than coaxial, AES/EBU, and asynchronous USB). Therefore, my suspicion/belief is that so long as the computer software player is functioning properly (ie. no buffer under runs, feeding a bitperfect driver like ASIO), then there should not be any jitter issues other than the limitation of the computer-to-DAC interface (at least in this case with a modern CPU & motherboard chipset).
In an even more extreme situation, with the AUNE X1 adaptive USB interface running off a USB hub with a hard drive attached transferring 25MB/sec data plus the CPU running 100% while playing the jitter test, I have not seen deterioration in the J-Test spectrum. (I won't bore you with the J-Test graphs since they look exactly the same whether computer is idle or busy and transferring files over the USB hub!)
Realize that this finding is very good! It means that we're free to do stuff like realtime transcoding and use of fancy upsampling algorithms without fear that somehow it will deteriorate the sound and that jitter is an independent variable not affected by the audio processing itself.
If anyone has reason to believe otherwise, I'd love to have a look at the test set-up and evidence of software-induced jitter (especially if it's audible!).
--------------------
Addenda:
Since I'm obsessive-compulsive and pedantic, here are a few measurements related to the above...
1. Just to show what a modern motherboard's analogue output looks like (ASrock Z77 Extreme4 motherboard "HD" sound, RealTek ALC898 codec, all "enhancements" off). Here are the measurements using a shielded phono-to-RCA cable to the E-MU 0404USB:
24/96 Frequency Response:
24/96 THD graph:
Summary - OK for 16-bit audio in terms of noise floor and dynamic range. Incapable of going beyond 16-bit dynamic range at best with 24-bit audio data. I suspect this is quite typical of on-board sound output. Notice the deterioration with 24/192.
2. Does the jitter pattern from the motherboard's analogue output itself get worse with increased CPU load?
Setup: Analogue output from ASrock Z77 Extreme4 --> shielded Phono to RCA --> E-MU 0404USB
Used the 24/48 J-Test like in the video above (that one was of course with the computer TosLink).
Computer idle:
Computer with 6 of 8 threads running at 100%:
Computer with 6 threads running at 100% + GPU (nVidia GTX 570) at 100% (FurMark running):
3. I alluded to the AUNE X1 adaptive USB interface put under stress. Remember that in this case I'm using a separate external USB hub (not even the direct motherboard USB port); here are the boring graphs - 16-bit J-Test since the adaptive interface is incapable of 24-bit:
Computer idle: (note the 15kHz distortion at -90dB - discovered this to be a driver issue with ASIO4All - see April 1 update... Might never have noticed this if not for testing.)
Computer with 6 of 8 threads running 100%:
Computer with 6 threads running 100% + USB HD copying files at 25MB/s running off the external USB hub!
No difference... Yawn... Can't even get the adaptive USB DAC to show me bad jitter under these kinds of USB conditions!
4. Asynchronous C-Media CM6631A USB --> TosLink --> AUNE X1, same conditions as above plugged into external USB hub (16-bit J-Test for consistency):
Computer idle:
Computer with 6 of 8 threads running 100%:
Computer with 6 threads running 100% + USB HD copying files at 25MB/s running off the external USB hub!
No difference... Very good graphs with minimal jitter (the spikes are primarily the 16-bit jitter modulation signal from the J-Test). Clearly the asynchronous interface is better even going through the TosLink.
This whole 'jitter' thing is getting tired and boring :-). Yawn... I'm not using any exotic or expensive gear at all and yet I can't even get jitter anomalies to show up despite the strain I've put on the CPU/GPU and USB interface.
If you are obsessive & want to get to the bottom of this, why not try a test which has proven itself to reveal measured differences between USB devices - Jim LeSurf's IQ-Test http://www.audiomisc.co.uk/Linux/Sound3/TheIQTest.html
ReplyDeleteHe has measured differences between the outputs from DacMagic & Halide bridge http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html
And also the Arcam rDac http://www.audiomisc.co.uk/Linux/Sound4/rdac.html
His conclusions "Audio is very demanding in terms of the final output needing to be clocked in a very uniform and regular manner. So the unwanted ‘jumps’ here are likely to be due to things going on inside the computer system that get in the way of maintaining a carefully regulated flow of audio data to the DAC. For this reason the details of the flutter can be expected to vary from one domestic computer setup to another. And may also change if you alter what software is running or do something as innocuous as connect or disconnect some other device from the USB ports. What is clear is that the Halide Bridge can take control of the data flow and overcome these problems."
Nice link and methodology!
DeleteHere's the link of the Halide vs. DacMagic results:
http://www.audiomisc.co.uk/Linux/Sound3/TimeForChange.html
A nice, elegant way of comparing the audio output of 2 USB interfaces. Yes, too bad he didn't do measurements looking at CPU activity given his hypothesis.
From what I can see, the DACMagic is an adaptive USB interface with the limited sample rate of USB Audio 1.0 (16/44 or 48). The comments from the manufacturer talks about computer power-supply related jitter with this device (http://www.stereophile.com/content/cambridge-audio-azur-dacmagic-da-converter-manufacturers-comments).
On the other hand we have the Halide asynchronous USB device which can go up to 24/96. And it performs better in his tests, not surprisingly...
Basically this lines up with my results of the async CM6631A device doing better than the built-in adaptive AUNE X1. Notice the "may" in the concluding sentence: "And may also change if you alter what software is running or do something as innocuous as connect or disconnect some other device from the USB ports." Sure, we can suspect this to be the case, and theoretically more so with the adaptive USB interface... But where's the proof that this happens to a significant degree? Up to now, I do not believe I have seen demonstration of this phenomenon which should be relatively easy to show if one believes the effect is significant.
Also, I would like to quote something else he said that I think is very important:
"The IQ-Test is a new approach so it isn’t possible yet to really decide on its merits in terms of audible effects. But you can at least expect that errors and variations over such a range of durations may make it plausible that some of them may indeed be audible if the effects shown by the J-Test are audible."
As I've said before, I'm not sure if the usual J-Test results are audible either (into the low nanosecond range at least) even though they can be measured and compared quite easily...
He never did run any further tests to see if his conclusion was valid or not i.e does varying OS load vary the output? The software to run these tests are available on his site - just need compiling for windows. Maybe you would like to satiate you obsessiveness to get to the heart of this by using this test? I do believe it is far more sensitive than what you are using.
ReplyDeleteI'll have to look into this in time; should be able to run this off a VirtualBox Linux install since the actual recording can be done on the PC side I think (will have to look more into the methodology).
DeleteInteresting!
Yes, agreed - things can be measured that are not necessarily audible & the corollary seems to exist also - things are heard which currently we don't seem to have the correct measurement for - this being an example of a new measurement that reveals some changes which had remained unmeasured up to now.
ReplyDeleteBTW, I believe that using the J-test for USB jitter is mistaken as it was designed specifically to stress the SPDIF transport protocol & specifically the Inter Symbol Inetrference (ISI) aspect of that protocol which doesn't apply in USB transmission protocol
True, Julian Dunn's original paper(s) on the J-Test focused on the AES-3 digital interface and variants thereof.
Deletehttp://www.nanophon.com/audio/jitter92.pdf
Nonetheless, the spectrum measured is the spectrum measured :-); and the adaptive USB is clearly poorer compared to the asynchronous. Even if the J-Test is unable to stimulate a "worst case" situation through USB as was its intention, it's still demonstrable that there appear to be sideband differences between the two. Publications like Stereophile continues to use the J-Test for USB DAC's (see their AudioQuest DragonFly review for example).
But does it not invalidate your test i.e looking for differences when OS is loaded Vs when idle? Surely you should be using a test that will stress the USB interface to see any changes which will be subtle, if they exist.
DeleteJust because others such as Stereophile use the J-test for USB DACs doesn't mean that it is correct to do so.
Well, actually I don't think it totally invalidates the graphs posted. The reason being that the jitter sidebands can be found in very jittery gear even without the J-Test modulation (for example my recent Pioneer DV-588a DVD-A/SACD player); it's just that the J-Test stimulates it further and makes it even more obvious.
DeleteThe fact that straining the computer CPU and the USB interface (with HD copy and using an external USB hub in a very extreme situation I might add) does not change the analogue output characteristics down to -120dB puts into question just how audible any of this can be.
Until there's some kind of evidence otherwise, I really don't think there's any issue unless you're pushing the CPU so far to cause stuttering like from buffer under-runs. I also subjectively do not hear a difference while routinely do things like audio/video encoding while listening late at night in a quiet setting.
Great test and enjoyed the video, too! Brilliant.
ReplyDeleteI always thought transmission jitter is not exactly a problem as long as there's adequate buffering done at the receiving end. In absolute terms this kind of jitter has to be large enough to cause intermittent signal lock loss between the interfaces resulting in audible drops.
ReplyDeleteMore concerning is conversion jitter stemming from clock instability, more precisely, right output value at the slight wrong time so the reconstructed sine is not so smooth anymore, even after dithering.