You are reading the older HTML site

Positive Feedback ISSUE 59
january/february 2012


Announcing the DSD Open Standard Movement
by Andreas Koch, Playback Designs, Andy McHarg, dCS, Rob Robinson, ChannelD


[Andreas Koch of Playback Designs is one of the leading thinkers and audio engineers in the realm of DSD theory and practice. He has sent to me this brief article, outlining a specification for an open standard for the transport of DSD files by using PCM frames via USB, which he developed in cooperation with Andy McHarg of dCS, and Rob Robinson of ChannelD. They have done an excellent job of developing a straightforward specification that slices the Gordian Knot of DSD over USB, which would otherwise remain a dismal tangle.

This is a very exciting and momentous development for DSD as a computer-based fine-audio ultimate reference-standard format, since other great designers/manufacturers have indicated their support for this new standard. We are publishing Andreas' article for the general good of fine audio, and in the hope that other audio designers and companies will join this open standard movement for DSD.

Dr. David W. Robinson

Editor-in-Chief, Positive Feedback]


Over the last few months I have been working with various companies—hardware manufacturers and computer software developers—to define an open standard for transferring DSD via PCM frames. As you may already know, neither computer OS manufacturers nor the USB specification support the DSD format specifically. Apple is the worst, as it only supports PCM. USB and Windows also allow "raw data" formats that can be used for DSD, but there is no standard that specifies that in detail. The attached is a specification for using the regular PCM channels for DSD data.

Besides the fact that we worked out and agreed on this standard, it is also remarkable that it brought together a number of manufacturers, some of whom are directly competing with each other. But the common goal of defining an open standard for DSD united them. That alone should be a strong and welcome message to the market. End users may not be interested in the details of this, but I wrote it so they can see that the united effort behind it.

USB Link for DSD Audio via PCM Frames

Version 1.0

The USB Audio specification 2.0 defines multiple formats for audio, of which standard PCM is only one. A general "raw data" format was also defined that can be used for any kind of data, including audio, but unfortunately, no specific format was defined for DSD. With the ongoing proliferation of USB converters in the current market, it appears that the opportunity for the official USB specification to adopt a single common method of transferring DSD audio via USB is slowly disappearing. This open standard specification for DSD-over-PCM frames via USB is an attempt of uniting as many manufacturers as possible, and jointly defining a method for transferring DSD via USB.


The manufacturers developing audio playback software want to minimize the number of formats they need to support for a USB link. Ideally, there is only a single such format. Likewise hardware manufacturers want to make their hardware compatible with as many playback platforms as possible. That, of course, only happens when all use the same format.

As mentioned above, USB Audio already supports a "raw data" format that could be used for DSD, and that would create a clear separation to any audio data path containing PCM. However, the latest release of Apple's operating system, OS 10.7, incorporates a USB driver that only supports PCM. Furthermore, the central audio engine, CoreAudio, inside the OS only supports PCM as well, luckily with no limitation on sample rate. (Earlier versions of the Apple OS supported a mode that was compatible with raw data mode, but that is history). Since the architecture of Apple's OS forces audio software developers to use CoreAudio for everything that is audio related, there is basically only 1 format left for the Mac platform: PCM. Creating a separate path for DSD would involve a lot of surgery, if it is even possible. So we have no choice (if we wish to have universal compatibility with the two major Oss) but to use a PCM path to transfer DSD audio, by using special flags or headers that allow the receiving hardware to detect a format change, and switch their decoder accordingly.

When using the Windows platform things are little easier: Windows by nature does not fully support USB Audio 2.0, and what it does support is limited to PCM only at a sample rate of 96kHz or less. There is no native driver support for higher resolution PCM, and it is clear from the beginning that a custom driver needs to be created for this platform whether it is for regular PCM or DSD. Luckily, a 3rd party software developer (Steinberg Audio) jumped in and created a driver (called ASIO) already many years ago that supports PCM and DSD, with no limitation on sample rate or word-length. It has become quite popular, and many software vendors support this in the meantime. ASIO is not directly a hardware driver, but sits between the audio playback application and the hardware driver. Each hardware manufacturer still needs to develop a custom hardware driver for their own hardware, but ASIO then creates a common interface standard for all application software.


As seen above, the Windows platform basically offers a solution with the ASIO driver and the raw data format supported by USB Audio 2.0. This is not as ideal as having a dedicated DSD path via USB, but this is safe and straightforward.

Since the Apple OS only allows a PCM path, we have to find a way to put DSD audio data into PCM frames that then get sent via the native USB driver. DSD has a sample size of 1-bit and a sample rate of 2.8224MHz. In other words the data rate is 2.8224M-bits/sec. This is equivalent to the data payload of 16-bit PCM at a sample rate of 176.4kHz. In order to clearly identify when this PCM stream contains DSD and when it contains PCM, we will need additional bits. The PCM format with the next higher bit rate is 24-bits at a sample rate of 176.4kHz. This larger bit rate gives us 8-bits for this marker or identifier. It seems a bit overkill if all we need is 2 states (8-bits give us 256 states), but we will see that this extra overhead comes in handy. Here is how we can use the 24-bits in each sample and for each channel:

The 8 most significant bits are used for the DSD marker, and alternate with each sample between 0x05 and 0xFA. Each channel within a sample contains the same marker. This has been chosen to minimize the click that might be experienced when the receiving hardware misinterprets the data as PCM, when it really is DSD. (If this should happen it would create a tone around 88kHz and roughly -40dB, nothing harmful and something that most D/A converters would suppress to some degree before it even reaches the loudspeaker.) It should be pointed out that hardware manufacturers and software developers alike can easily use common safeguards to prevent such cases of erroneous format switching, and that such errors may only be limited to times during development of hardware and software. It is their responsibility to prevent misinterpreted cases and to test their products thoroughly before release. Misinterpretation of PCM data as DSD may create less predictable clicks.

The remaining 16 lower bits are then used for the DSD data, first or oldest bit in slot t0. The USB Audio specification assigns each PCM Frame to a specific channel (left, right, etc.), and when used for DSD streaming each PCM Frame contains only DSD data corresponding to its assigned channel.

Recommended implementation for receiver

While there is certainly more than one way to implement this solution on the receiver side, the authors found the following implementation to work reliably:

  • In order to switch from PCM to DSD mode, the receiver has to detect 32 consecutive DSD marker bytes on all channels used.

  • In order to switch from DSD to PCM mode, the receiver has to detect at least 1 single missing DSD marker byte in at least 1 channel.

This introduces an additional latency of around 180usec. If the USB buffers are accessible for reading while the USB microframe is still being received, then no additional delay is necessary.

Industry Support

The following have contributed to this document and/or pledged their support for this format (alphabetical order):

Aesthetix - Jim White

Audirvana - Damien Plisson

ChannelD - Rob Robinson

dCS - Andy McHarg, David J Steven

JRiver, Inc. - Matt Ashland

Merging Technologies - Dominique Brulhart

Playback Designs - Andreas Koch

Sonic Solutions - Jon Reichbach

Wavelength Audio - Gordon Rankin

XMOS - Ali Dixon

Independent - Dustin Forman

Revision History







Andreas Koch, Andy McHarg, Rob Robinson

Initial version



Andreas Koch, Andy McHarg, Rob Robinson

Updated Industry support section, added recommended implementation



Andreas Koch, Andy McHarg, Rob Robinson

Updated industry support section, clarified channel assignment, deleted recommendation about ASIO driver.



Andreas Koch, Andy McHarg, Rob Robinson

Release version 1.0


It is the hope of the authors that the announcement of this open standard for DSD-over-PCM frames via USB will encourage all other interested parties to join us in supporting this specification. Those interested in joining the open standard movement for DSD should contact Andreas Koch at