IQ Test Results for Arcam rDAC
Having examined the timing behaviour of the Cambridge Audio DACMagic with and without the Halide Bridge I decided to try the Arcam rDAC. To do this I used the same ‘IQ Test’ method. The results I obtained are shown below for various sample rates and sizes.
As for the earlier tests, the rDAC was fed LPCM Wave sourced audio from a Shuttle PC running Ubuntu Linux and using the basic ALSA ‘aplay’ command. The analogue output from the rDAC was recorded using a Tascam HDP2 recorder running at 192k / 24bit. These recordings were then analysed to give the following “wow and flutter” spectra of the timing of the replay rate. Various source file sample rates were tried, with both 16 and 24 bit sample values.
The IQ Test software can be found at: http://www.audiomisc.co.uk/software/index.html
More details of the test method can be found at: http://www.audiomisc.co.uk/Linux/Sound3/TheIQTest.html
The above shows the fluctuations in timing uniformity when the rDAC was fed with Audio CD standard data. The vertical scale is in parts per billion (i.e. thousand million). Looking at the plot you can see that there is a particular component at about 0·1 Hz. This means that the replay rate is smoothly hunting up and down every ten seconds or so in a regular manner.
Considered as timing ‘jitter’ these results can be viewed in a different way. The above graph shows the same 44k/16bit results for the rDAC, but this time displayed in terms of the peak Jitter spectrum at low fluctuation frequencies. Frequency variations with a long period have a long half-cycle time over which to build up a large timing error. So, for example, a wow of 100 parts per billion at 0·1 Hz corresponds to a peak timing Jitter component of nearly 200 nanoseconds – i.e. almost 200,000 picoseconds!
Compared with the more familiar short-term jitter levels people obtain from the standard ‘J Test’ such a value seems very large. But it should be remembered that the audible impact is different, so we may be comparing apples with oranges. Variations over timescales much longer than a second may be heard as a a tiny periodic variation in pitch, or be inaudible. Whereas relatively small short term variations at higher ‘flutter’ frequencies may alter the timbre or sound quality of what we hear. So it seems fairer to focus on considering the low frequency results of the IQ Test in terms of frequency ‘wow and flutter’ rather than in terms of timing jitter values.
The above plot shows the results when the data file being played has 24 bit samples, but is still at the audio CD sample rate of 44,100 samples/sec. The result is similar to the 16bit case. In fact, the behaviour proved to be much the same when playing audio at various rates. The following plots show other examples for higher sample rates.
Comparing the rDAC results with those for the DACMagic you can see that the asynchronous USB input of the rDAC gave me smoother timing than using the DACMagic’s USB input. The behaviour is more like the DACMagic + Halide Bridge combination in terms of the low level of the low frequency fluctuations, although the details of the spectrum of variations differ. However the DACMagic + Halide Bridge combination does not exhibit a distinct component in the 0·1 Hz like that produced by using the rDAC.
The results indicate that the rDAC gives USB replay that is more stable in the longer term than the DACMagic. But the DACMagic + Halide Bridge performs very well indeed. So overall the DACMagic + Halide Bridge combination can be argued to give slightly better measurably behaviour so far as the IQ Test is concerned.
A potential drawback of the rDAC is that it gives the user no sign of the input sample rate (or sample size) of the stream it is receiving. Whereas the Cambridge DACMagic has a set of LEDs that indicate the sample rate. It also has spdif outputs which can be used to monitor what the DACMagic is being fed if you have suitable equipment. To set against that, the rDAC’s USB input showed much better timing performance than the DACMagic – which required the addition of the Halide Bridge to beat the rDAC. And is available with a local wireless link for input.
In principle the lack of any indicators on the rDAC should not matter. But my experience is that it may be all too easy for a computer system to send data that is not at the correct ‘raw’ sample rate or size for the source file being played. So, unless I know from other tests that a computer system (including the chosen audio playing software) is always sending the correct data stream I am happier using a DAC that gives a clear indication of what it is being fed. Personally, I find the DACMagic + Halide Bridge excellent as a versatile combination. But the rDAC also sounds fine given good input material, and is less costly than the DACMagic + Halide Bridge combination.
Jim Lesurf
July 2011
