MUSINGS: On SACD & DSD audio...

SONY multi-page spread (with hybrid SACD 'RS500' sampler!) - Rolling Stones magazine, December 2003.

Okay, now that I have posted a number of measurements over the last months, permit me a moment to play "Speakers Corner" and talk a little about the state of affairs around DSD now in early 2013...

Firstly, remember that DSD isn't anything new. It's basically a digital format based on Delta-Sigma modulation which has been used in consumer digital audio since the late-80's and early 90's - remember those old Sony 1-bit and Panasonic MASH players from around that era? It was said that as the CD patents were set to expire, Sony and Philips decided to create a new disk format for the 21st century - hence the birth of SACD around 2000 using the "1-bit" encoding method instead of multibit-PCM carried on DVD-like disks capable of higher data capacity (multi-bit ended up being DVD-A of course). Sound quality was said to be better because of things like "100kHz frequency response", better noise floor and in time, multichannel. Of course in creating this new standard, copy protection was job one and they did a great job. I remember in 2004 visiting China and seeing pirated DVD-A's which were easily "cracked" soon after release, but not so SACD's.

MEASUREMENTS: Oppo BDP-105 does DSD.

Well, it's out...  The March 26, 2013 BETA firmware for the BDP-105 that allows native DSD playback from this unit's USB ports as DFF and DSF files on a USB stick. As far as I know, there are no plans currently to allow computer playback connected to the USB port as a DSD DAC.

With this recent development, I headed back to my friend's place to run a few more tests...

Here's the basic premise of what I did...

Using the freely available KORG AudioGate 2.3.1, synthetic 24/192 test signals from RightMark 6.2.5 were converted over to DSD64 (2.8MHz sampling) and DSD128 (5.6MHz) for testing. We soon found out that the DSD128 files created could not be played back properly by the Oppo (it would play but the DSD128 files had timing issues - played too slow). Presumably there is a bug here somewhere with the beta firmware or the AudioGate converter. As such, I was only able to test DSD64 playback.

The first thing done was to go through the Oppo's settings menu making sure there were no volume settings, bass management, etc. active. I believe if any of these are turned on, the DSD will get converted to PCM.

The hardware setup is similar to what I did with the original BDP-105 tests (only difference being use of the front USB connector):
Patriot Rage XT USB2 memory stick 16GB with test files --> front USB port of BDP-105 --> shielded 6' RCA --> E-MU 0404USB --> Win8 AMD X4 laptop

RightMark results:

The first 3 columns are the tests done in PCM mode at various hi-res sampling rates. These essentially measure <1 dB different compared to my original tests using the Oppo's USB asynchronous DAC. Nice confirmation of inter-test reliability.

The last column is with the 24/192 test signal converted to DSD with the KORG software. As you can see, it's almost the same. Note however that RightMark is calculating these parameters just within the audible spectrum between 20Hz - 20kHz (AES17 standard).

Frequency Response:

First hint/reminder of the DSD effect. There's some high frequency noise breaking through up in the 70kHz range. Otherwise, the curves are relatively comparable with -5dB extension out to around 40kHz for DSD and 50kHz for PCM 24/192.

Noise:

Demonstration of the DSD noise shaping through the Oppo. From 20kHz onwards, the noise level rises quite remarkably as you can see. It's all ultrasonic of course so unlikely to cause an audible problem and would only matter if this creates any strain on your amp/speaker system or if nonlinearities cause distortion in the audible spectrum.

Although also not a problem, notice the noise floor from about 12kHz to 20kHz is not as flat with DSD.

THD:

Another view of the ultrasonic noise.

Jitter:
The J-Test cannot be used with DSD of course. This is just for completeness. I've already shown previously that jitter isn't an issue with the Oppo...  Here's just what the 24-bit Dunn J-Test looks like going through DSD transcoding.

If we compare it to the PCM:

Note the loss of the regular modulation pattern. Basically this is telling us that the LSB in the 24-bit signal has been affected and effectively dithered over by the conversion process to DSD.

Analogue Output:
Lets now have a look at what a 1kHz -6dB sample looks like after going through the DSD process. What I did here was record a few seconds of a pure 1kHz test tone in 24/192 to have a look at the waveform zoomed in.

PCM 24/192 FLAC played back:

DSD64 KORG transcoded DFF file played back:

The high frequency noise in the DSD signal can be seen (you might have to click on the images to get a good look). Not a big deal in that this is not audible but a reminder that DSD64 cannot reproduce a simple 1kHz sine wave as smoothly as that produced by the reconstruction filter in the PCM domain.

Impression:
As I had hoped when I wrote that piece on the Pioneer DV-588A last month, here are some results from a device that performs "pure DSD" decoding.

Within the audible spectrum, DSD64 produced by the KORG AudioGate software looks good. Standard measurements like dynamic range, noise floor, distortion are all looking great and reminds us of the high level of performance the Oppo BDP-105 is capable of. I was disappointed that I could not get the KORG-encoded DSD128 test signals to play properly. I don't know if this is due to the KORG software or the beta firmware. Maybe I'd have better luck with Weiss Saracon if I had access to this conversion software... Oh well, maybe next time :-)

As a reminder, all the tests I've shown were converted from the 24/192 PCM domain into DSD64 and therefore will be subject to the limitations of the conversion software and PCM source (note that at 24/192, this is not likely a technical issue).

An interesting observation; even though the encoded DSD128 could not play, free downloads of demo material from 2L worked just fine on the Oppo! They sounded great with a wonderful sense of space, timbre, and dynamics.

Bottom line: The Oppo did a great job with DSD playback just like it did with PCM. Limitations of DSD are clearly seen (ultrasonic noise pollution mainly). From a purely technical perspective, within the 20Hz-20kHz audio spectrum, there's really nothing to differentiate all these hi-res formats. However, if you include ultrasonic characteristics, PCM is definitely cleaner.

Given the frequency response curve demonstrated, this KORG DSD64 conversion + Oppo playback system can likely be encapsulated within the parameters of a good 24/88 system.

MEASUREMENTS: [UPDATE] Adaptive AUNE X1, Asynchronous "Breeze Audio" CM6631A USB, and Jitter...

In late February, I received an interesting USB2 --> SPDIF box from Asia. It's based on the C-Media CM6631A chipset (it says "Breeze Audio" on the metal case and "CM6631-V1.4" on the PCB) which communicates with an asynchronous USB2 protocol (recall that the Asus Essence One uses the CM6631).

Total price ~$50USD shipped.

Although it's said to be plug-and-play compatible with Mac OS X, I've run into a few snags which I won't discuss here - just be aware if you're planning to use this on the Mac (SEE ADDENDUM - ISSUE FIXED!)...  However, I'll restrict these measurements to the Windows 8 environment only where the custom drivers work well.

The idea I wanted to explore was whether using an asynchronous converter like this connected to the AUNE X1 would be better in terms of jitter than the adaptive USB port of the X1 itself. Also, how sensitive is jitter to computer load?

Note that beyond jitter, there are some other obvious reasons to do this... Firstly, using the CM6631A box allows hi-res TosLink/coaxial output up to 24/192 if you don't have a USB2 DAC. Secondly, it might be better to keep peripherals all running at high speed if you're going to be plugging this into a USB2 hub.

Lets take a look at the adaptive USB jitter spectrum directly from the AUNE X1 (remember, only up to 16 bits, so I'll be using the 16/44 Dunn J-Test signal) [UPDATED April 1, 2013 - SEE BELOW]:
(Setup: i7 computer --> shielded USB --> AUNE X1 --> shielded RCA --> E-MU 0404USB)

Numerous sidebands with spurious noise. I guess this is pretty typical of a very pedestrian adaptive USB1 interface. It doesn't "look" good but for the most part, these spikes are down below 100dB from the 11kHz primary tone.

Not only is adaptive USB said to be bad for jitter, but some believe it's especially prone to timing errors if you're multitasking...  Lets see what happens when the CPU is under 100% load (Prime 95, 8 threads), and to make it worse, lets also run the GPU (nVidia GTX 570) 100% with FurMark:

Essentially no difference to the spectrum whether the computer is fully loaded or not! You see a bit of noise showing up between 8-9kHz but it's all very low amplitude (again >100dB below the 11kHz peak).

Let's now put the CM6631A asynchronous USB --> SPDIF in the chain. Here's the setup now starting with a proper coaxial SPDIF 'digital' cable (Acoustic Research brand):
i7 computer --> shielded USB --> CM6631A --> shielded digital coaxial --> AUNE X1 --> shielded RCA --> E-MU 0404USB

This is a very nice 16/44 J-Test graph with minimal data correlated sidebands and most of the peaks are just due to the 16-bit J-Test modulation tone.

What happens with the CPU and GPU running at 100%?

No difference!

What about we use the TosLink output from the CM6631A instead?
(Setup: i7 computer --> shielded USB --> CM6631A --> decent plastic TosLink --> AUNE X1 --> shielded RCA --> E-MU 0404USB)

In this setup, the TosLink interface is almost exactly the same as coaxial (I'm actually impressed by this since TosLink often tends to be significantly worse than coaxial).

What about CPU & GPU running full tilt at 100% using TosLink?

Again - no difference! (Ignore that FurMark banner... Just got in the way of the screen capture.)

OK. We've also heard that a poor coaxial cable could be bad for jitter...  That is, if there is severe impedance mismatch between connectors (supposed to be 75ohms), the theory goes that there could be reflections which could damage the digital signal transitions. Furthermore, it is said that a short 3' cable is worse than a longer cable due to the transition time for these reflections.

What then would jitter look like if I replaced a proper shielded coaxial with cheap "freebie" 3' RCA connector that came with an old Pioneer DVD player (I used the red connector)?

Eh? That's all? Really no different than with the "proper" coaxial cable!

How about with CPU and GPU running 100% using the cheap RCA cable?

Again, that's all!?

Realize that in the analogue domain, I can measurably prove that the cheapo RCA is worse than the shielded proper coaxial digital cable based on noise floor differences. But in terms of jitter (digital phenomenon) which we're stimulating here with the Dunn J-Test, in this "real world" setup, I cannot show any significant difference despite the likely poor impedance match and 3' length! (Note that I'm not saying a cheap RCA cable is as good as proper coaxial in general, just that in this inexpensive setup, it works fine... I have measured in other situations like with my ASUS Essence One paired up to a Squeezebox Touch where a cheap RCA cable actually resulted in very severe jitter issues.)

Summary:

1. The asynchronous USB2 interface works to lower jitter! Having said this, I think we have to also recognize that apart from some noise spikes, the actual jitter sidebands with the adaptive USB interface wasn't terrible and likely not audible given how low in amplitude they were.

2. Whether the computer was running full-tilt at 100% or not, I could not demonstrate any change in the jitter characteristic! This applied to adaptive USB as well as asynchronous USB --> SPDIF. IMO, this makes me question the belief in "software-induced" jitter. I suppose if your computer is totally bogged down such that the audio buffer cannot be filled on time, you'll hear severe audio degradation. However, some people believe even light multitasking worsens sound quality, or the importance of shutting down background OS processes or running "stripped down" OS'es. By extension, some people swear by various playback programs having an effect on the audio quality (ie. Decibel vs. Amarra vs. JPlay vs. Audirvana vs. iTunes vs. foobar...) even if all that's promised is "bit perfect" output. It almost always comes back to "jitter" as the explanation some how. Really? Is there any objective proof for such beliefs or even a testable hypothesis?

As I have hinted in previous posts, even though I (obviously!) believe that jitter exists and is measurable, I do not believe it is audible with music unless extreme like maybe >10ns. It's also worth remembering that research into the threshold of jitter audibility decreases with higher frequencies; but this also correlates with human hearing losing sensitivity the higher up we go - especially as we get older (therefore, sensitivity to jitter should decrease with age). These days, well engineered "high fidelity" gear should not be even close to showing 10ns jitter. Likewise, software player programs should be capable of "bit-perfect" output without difficulty or cause timing errors.

Over the years, I have also tried many software players like Amarra, Decibel, JPlay, etc... Ultimately I've never been convinced of significant differences in sound between them (so long as EQ and plugins not active). Foobar + ASIO driver sounds great to me on the PC side and I use Decibel for the Mac simply because it's inexpensive and works well to switch sampling rates.

Bottom Line: Don't worry about jitter! It's more than likely inaudible in a modern computer system and with decent (not necessarily expensive) audio gear. I see no evidence that high CPU/GPU load makes any difference to jitter. Isolating your DAC from electrical noise polluting the analogue output seems much more important.

ADDEDDUM (April 1, 2013):

I found out why there was the 15kHz peak in the adaptive USB1 tests with the AUNE X1. Had to do with some old ASIO4All drivers I had installed on the i7 computer...  A good reminder of how easy it can be to mess up settings when using a PC for audio playback!

Anyhow, for completeness, here are some updated graphs of the X1 using adaptive USB measured off my Win8 AMD Phenom X4 laptop. Note that even though the graphs look different, the conclusions are the same - asynchronous USB2 is less jittery, and when the computer is at high load, the noise floor worsens for the adaptive USB case only.

Adaptive USB1, AUNE X1 using WASAPI for 16/44 J-Test:

Now with 4 threads running Prime95:

Notice that slight noise floor elevation from 8-9kHz. Not as extreme as my i7 testbed with the powerful GPU running.

Asynchronous CM6631A --> shielded coaxial --> AUNE X1, WASAPI, 16/44 J-Test:

Nice and clean...  Looks just like with the i7 testbed. What happens with Prime95 running?

No change.

Asynchronous CM6631A --> TosLink --> AUNE X1, WASAPI, 16/44 J-Test:

Now again with Prim95 running on all 4 cores:

No difference...

OK. So I have now shown that the jitter results with the CM6631A device is reproducible on 2 platforms (i7 & AMD Phenom X4) as being low for both coaxial and TosLink. Also, the CM6631A device seems quite immune to noise from the main computer (compared to the adaptive USB interface). Both ASIO and WASAPI work well for the CM6631A. Still no evidence that the jitter pattern itself changes with increased CPU load.

ADDENDUM (March 31, 2013):

Noticed this very useful post on diyaudio.com from 'bvs':

I've recently found a solution for issue that caused when CM6631A module is connected to any Mac USB 2.0 ports. When you connect module to Mac it is detected as USB Audio Class 1.0 device and you have no ability to use anything more than 48/16. Module has a reset chip LM810M3-2.93 (http://www.nscrus.ru/content/catalog/pdf/LM810.pdf), but as we can see from the CM6631/32 datasheet, the CM6631A has a power-on self-reset. So, reset chip has been removed from a board and now the module is always correctly detected as USB Audio Class 2.0 device on any Mac USB port. This method has been tested on MacBook Pro, Mac Mini and this CM6631A module: New CM6631 USB Module Assembled Board for DAC3 AD1955 DAC7 WM8741 by Weiliang | eBay LM810M3-2.93 is a 3-pin chip located on the top of CM6631A.
So, with a needle-nosed plier, I went to work on removing that little 3-pin chip (labelled "SA B" on the board)...  Here's the result (chip removed): The unit works as expected on my MacBook Pro's now with full playback up to 24/192, no need for an external power supply, and no need for custom drivers. Remember, this modification is for the CM6631A only. Earth to Microsoft - isn't it about time we got native UAC2 driver support in the OS!? Especially considering that it's been available for OS X and Linux since 2010!

MEASUREMENTS: Sony Playstation 1 (PS1) - SCPH-5501 as CD player.

I got a kick out of this article by Stereophile awhile back (2008):
http://www.stereophile.com/cdplayers/708play/

Imagine, audiophiles using an "archaic" (circa 1994) game console as a CD player for thousands of dollars worth of expensive amps and speakers downstream!

That Stereophile article reviewed the first PS1 version which was the SCPH-1001. Instead of that older model, what I have here is the slightly later SCPH-5501; said to be superior for audio by some PS1 aficionados!

Here's an interesting post from a fellow on the Steve Hoffman message board going by the alias "rhing":

I recently purchased a used Playstation1 Model SCPH-5501 from a local video game store for about $25. I bought it based on the fact that it uses the same Asahi Kasei AK4309AVM DAC as Model SCPH-1001. The most obvious difference between Models SCPH-1001 and SCPH-5501 is that Model SCPH-1001 is the only Playstation 1 with RCA stereo audio output jacks. For some people, this is important to getting the ultimate performance from a Playstation 1. Model SCPH-5501 outputs stereo audio through a 12-pin Sony A/V Multiport jack that uses an A/V breakout cable with RCA jacks for Right Audio (red), Left Audio (white) and Composite Video (yellow). In addition to the RCA jacks on the rear, Model SCPH-1001 also has the same Sony A/V Multiport jack. The benefit to using the A/V Multiport jack is that there are no cheap NJM2100 op amps in the signal path between the DAC and the output. The RCA jacks are connected through a pair of op amp buffers that can adversely effect the sound quality. In fact, most Playstation 1 audiophile modders bypass the op amp buffers, or use the A/V Multiport to get the same effect of better sound. Other improvements were incorporated in the later Model SCPH-5501:

1) An improved Nichicon SMPS that generated less heat that could distort adjoining plastic components such as the lid and chassis that could lead to mistracking or binding of a spinning CD disk.

2) Positioned the laser assembly away from the power supply to reduce heat damage and RFI noise.

3) Implemented an auto-biasing feature for proper tracking. Model SCPH-1001 requires manual biasing of the laser circuitry to maintain tracking.

...

He goes on comparing the PS1 with other gear he has. Good read. I can't verify the comments but it certainly sounds well thought out and worth considering. For those wondering, the AK4309 is a 1-bit delta sigma "bit stream" DAC.

So, without further ado, here it is:

Notice the lack of RCA direct outputs at the back; there's a supplied multi-AV cable with RCA out instead.

   

Setup:

Playstation 1 --> stock multi-AV to RCA cable --> E-MU 0404USB --> shielded USB --> AMD Windows laptop

I used the stock PS1 power cable as per the photograph.

RightMark result:

As you can see, for convenience in comparison, I included the 16/44 results for a number of the other DAC/streamer units I measured over the last while.

Compared to the rest, the PS1 is clearly outmatched in terms of dynamic range. These measurements indicate that it's capable of around 15-bit dynamic range. At first, I thought it may be the fact that this is a CD player with all kinds of electronics in there perhaps lowering the dynamic range. However, when you have a look at the AK4309 datasheet, indeed the rated dynamic range for this part is 'only' 90dB.

Frequency response:

Some slight deviance from flat response curve up above 3kHz - unlikely to be noticeable through speakers and room interactions. Note the green plot for the Muse Mini TDA1543x4 for comparison to show what a typical NOS DAC measures like. Old school early 90's 1-bit delta sigma vs. NOS! :-)

THD:

Since the Transporter uses the newer generation AKM DAC (AK4396), here are the THD plots in comparison. Obviously, the Transporter is capable of measurably lower noise level with a cleaner graph notably above 10kHz.

In comparison, the TDA1543 (NOS DAC) measures much worse with numerous harmonics:

Jitter (16/44 Dunn J-Test):

Looks fine. Sidebands peak below -100dB from the primary 11kHz signal.

Conclusion:

There you go, the Sony Playstation 1 SCPH-5501 measured as a CD player. I can't say how it sounds compared to the even older "first-version" SCPH-1001 but as I quoted above, there are reasons to believe this version should perform better. Last night, for some late-night R&R, I listened with this unit through my AUNE X1 as headphone amp with Sennheiser HD800 headphones. Tunes on tap: Muddy Waters "My Home Is In The Delta" (downsampled Classic Records HDAD), Cat Stevens "Wild World" (2011 Analogue Productions), Nat King Cole "The Very Thought Of You" (2010 Analogue Productions), Akon "I Wanna Love You", eRa "The Mass", Joe Satriani "Crowd Chant", Jheena Lodwick "It's Now Or Never", Stephen Layton & Britten Sinfonia "For Unto Us A Child Is Born" from Handel's Messiah. They all sound great through the headphones. Nice details throughout, bass nice and deep on "I Wanna Love You", no accentuated sibilance with female vocals (that Jheena Lodwick track can be nasty), "The Mass" may have sounded a bit congested during the louder & more complex segments but really nothing to detract from enjoyment. I do not believe the measured 'limited' dynamic range negatively affected enjoyment at normal listening levels at all. Remember that ~90dB dynamic range is better than the majority of analogue sources.

Clearly compared to modern DAC's, the PS1 has inferior noise performance and concomitantly lower dynamic range. The other measurements like THD and IMD are respectable and jitter is not of concern. If we look at the TDA1543 DAC unit (DAC chip designed around the same era), the NOS unit has better dynamic range but with much more THD and IMD along with the typical high frequency roll-off at 44kHz sampling rate (of course you could feed the NOS upsampled 88/96kHz data to smooth this out). Between the two ultimately, it's one of subjective preference, especially for a "colored" DAC like the TDA1543 NOS (I've yet to measure a tube analogue output DAC). Personally, I'm of the "technically perfect" camp and would probably pick the PS1 over the TDA1543 even if a bit noisier - reasonably low level of noise like this is generally less objectionable than distortion.
 
I don't have any digital gear from the late 80's left, but by the mid-90's, "CD players" like this one sound and measure fine (though far from great in the case of the PS1 here)...

MEASUREMENTS: Pioneer DV-588A - DVD-A and SACD "universal" player!

Hey guys, remember the SACD vs. DVD-A "war" back in the early-mid 2000's?

In the heat of the battle, it was nice that a few manufacturers gave us these "universal" DVD players that could handle both competing formats. Pioneer was one of them and in mid-2003, released to the world the very reasonably priced DV-563A (~$200). A year or so later, this model under consideration, the DV-588A was released. I remember browsing around Future Shop (owned by BestBuy these days) in 2005 to pick up this unit since my previous Panasonic DVD player failed on me. At <$200, I figured I couldn't go wrong since this would 'in a pinch' also play my small collection of DVD-A and larger collection of SACD's.

The innards of this player revolves around the MediaTek MT1389EE SoC chipset which graced many <$400 players back in the day (including the Oppo DV-981HD and Sony NS955 [chip apparently relabeled as Sony CXD9804R]). Although it has been said that this chip is capable of "PureDSD", I do not believe any of the lower priced units operated in this mode because multichannel and bass management were performed in the PCM domain. As a result, the 1-bit DSD (actually DSD64 for the 64 x 44.1kHz = 2.8224MHz SACD sampling rate) in these machines are converted to 24/88 prior to conversion by the DAC (supposedly a BB DAC is used in this unit).

With the advent of PS3 SACD digital ripping in 2011 and a firmware upgrade to the Pioneer, this unit joined the ranks of the relatively few SACD players capable of playing backup SACD-R's.

Given the low price, let's see how well this player measures... First I created a DVD-A with the RightMark test signals along with the J-Test to have a look at how it performs as a hi-res PCM unit.

Setup: Pioneer DV-588A --> 6' shielded RCA --> E-MU 0404USB --> AMD X4 laptop, battery power, Win 8 x64
- Equipment plugged into Belkin PureAV PF60 power filter (same general setup as what I used for the Transporter previously).

Okay, so far not too bad for a budget player...  It can benefit from 24-bit audio with a dynamic range around 17-bits. Here's the 24/192 frequency response:

And here's the noise level (useful when we look at the SACD graph) - reasonably flat to about 50kHz:

As usual, I plotted the Dunn Jitter Test (24/48):

Quite jittery as you can see with a number of sidebands congregated +/- 1kHz around the 12kHz main signal.

Now as I mentioned above, this player is capable of SACD-R playback. So, I downloaded KORG AudioGate and went about converting the 24/192 PCM RightMark test and calibration signals and 24/48 Dunn J-Test into DSD64. With the help of a friend who's into this stuff, we got the tracks authored onto a SACD-R for testing.

Here's what RightMark looks like playing the SACD-R:

Not good... Just marginally better than DVD-A 16/44.

Lets have a look at the frequency response curve:

Not unexpectedly, the fact that it's resampled to 24/88 leads to an earlier cut off in frequency response than the DVD-A 24/192 spectrum above. I wonder if AudioGate is imposing a low pass filter starting around 30kHz to create that early steep drop off...

Noise spectrum:

Note that extra "bump" at 25 to 44kHz thanks to the DSD noise shaping (absent in the PCM noise graph above) - remember that this is a log scale so it's all scrunched up in the corner. The fact that the noise gets truncated at ~44kHz makes sense for the 24/88 PCM conversion, that's why I wondered above if AudioGate is cutting off the frequencies of the test signal earlier at 30kHz.

Although the Dunn J-Test is invalid in terms of stimulating worse-case jitter in the DSD domain, for the heck of it here's the spectrum (again 24/48 test):

It's cleaner than the PCM graph above. Possibly the resampling from DSD to PCM done internally - like ASRC's - is cleaner than the direct PCM from the DVD transport (I don't think it has to do with corruption of the LSB jitter modulation tone since even a straight 12kHz sine wave looks very jittery in DVD-A).

Summary:
Hey, I got to measure a DVD-A / SACD player with my custom SACD-R & DVD-A disks :-)! I've often wondered how this old Pioneer compared in terms of SACD vs. DVD-A playback. Subjectively, I've always thought it sounded good but not exceptional. I never bought the same title on both DVD-A and SACD to actually compare how the two would sound. Even if I did, there would be no assurance that the mastering would be identical anyways. Although I have about 30 SACD's still, they're barely listened to compared to the computer music server and my Squeezebox players. The fact that I do have a dedicated SACD changer still (the venerable Sony SCD-CD775) also means I don't bother with the Pioneer for music playback the few times I spin a disk not for the purpose of audio ripping.

Overall, the objective data points to a 'fair' DVD-A player for its price and a 'mediocre' SACD player with dynamic range just a hair above that of an ideal 16-bit CD. Of course I'm converting my test tracks from PCM to DSD and then the player is re-converting back to PCM again so this will affect the sound quality negatively...  Furthermore, I haven't played with AudioGate enough to get a sense of how good it is as a PCM to DSD converter compared to something like Weiss Saracon which is much too expensive for the casual hobbyist. Nonetheless, since RightMark is measuring dynamic range at 1kHz (should be quite good for DSD64), it should still measure better than what I got assuming the digital data conversion was done competently and the 24/88 internal conversion algorithm is good.

The question of course is how well does a good "pure DSD" SACD player measure compared to something like this budget Pioneer? Can anyone suggest a good SACD unit to try which can play back SACD-R's?

[It would have been nice to convert 24/176 test audio to DSD rather than 24/192 due to the even multiple 44kHz sampling rate. Unfortunately the EMU-0404USB seems unable to handle this sampling rate well for me. Ideally of course, DXD 24/352 would be even better!]

MEASUREMENTS: The hunt for load-induced jitter...

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

(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):

Conclusion: The motherboard's internal DAC is relatively jittery compared to the USB DAC's tested below. But symmetrical jitter sidebands are no different whether CPU or GPU load high. Bottom line...  I can't even seem to stimulate more jitter with the motherboard's own internal DAC by increasing CPU or GPU load. One consistent finding though is that bit of noise between 8-9kHz - usually whenever I strain the GPU.

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.