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.
0 comments:
Post a Comment