diyAudio (
-   Digital Source (
-   -   High Resolution Multi-Channel Digital Interface (

Brian Brown 14th November 2003 09:55 PM

High Resolution Multi-Channel Digital Interface
This is an update on my experiments with a real-time direct-digital audio interface.

Highlights of my present implementation:

- Excellent sound quality (IMHO).
- Multichannel support (six channels).
- Good electrical noise immunity.
- ESD protection.
- Power supply sequencing between interconnected units can occur in any order.
- Tolerant of live plug-in and disconnect.
- Master (low jitter) clock can be located next to DAC or digital amplifier.
- Flexibility with multiple source formats (DSD, I2S, RJ24, various sampling frequencies).
- Destination format is standardized at 24bit I2S (sampling frequency up to 200KHz, dependent on master clock).
- Low cost, standardized interconnect cables and connectors (CAT5).
- Suitable for short-distance (six inch box-to-box) as well as longer distances (Iíve tried up to twenty-five feet, but it should be able to go even further).


A couple of years ago, I was inspired by the availability of new digital amplifier chipsets, audio processors, as well as the coming of multichannel DVD-A and SACD. I had long wanted to implement an all-digital signal path, including digital speaker crossovers and room correction. Digital amplification offered a more practical implementation of the large number of separate amplifiers that I would require. Iíd already formed a rather strong opinion that for a given cost, a digital amplifier could offer better sound quality than a traditional DAC / analog amplifier combination.

I spent most of the first year studying digital amplifiers and working on some preliminary designs. It became very apparent that the lack of a standard commercial multichannel digital interface was going to be a roadblock to both my digital processing and digital amplifier experiments.

I bought a Panasonic SA-XR10 receiver as an experimental platform after discovering that it utilized TIís Equibit digital amplifier chip set. One of the things that really startled me was how much better CDs and 2-channel DVD-As sounded through S/PDIF compared to using the analog link: Disk player >>> DAC >>> ADC >>> Digital Amp. (I knew that bypassing this analog patch job was going to be an improvement, but I didnít expect it to be such a big one.)

This revelation caused me to drop everything else and focus my attention on a new digital interface.


The present S/PDIF standard only supports Stereo PCM (up to 96KHz) without compression. I wasnít interested in compressed multi-channel formats such as AC3, DTS, MP3, etc. (If I happen to want to play an AC3, DTS, or MP3 disk, Iíll use the player to decode it before sending it over the interface.) Also, S/PDIF uses an imbedded clock that has some data-dependant clock recovery issues.

The only direct-digital SACD and DVD-A interfaces that Iím aware of are proprietary to certain manufacturers and will only work with their equipment.

The upcoming IEEE-1394 digital audio interface requires a tremendous amount of overhead. It probably will offer excellent sound quality, but it will be very DIY-unfriendly.

USB looks promising for DIY. TIís TUSB3200A supports eight channels of USB to PCM interface. Their reference design should help reduce the work required to get this up and running. Still, it requires a lot of overhead. I may reconsider it in the future, but I decided that I wanted to stay with a synchronous interface for now.

LVDS over twisted-pair appeared to be the best type of signaling to use for an interface. There are many support chips available for it, as well as it becoming a standard on newer FPGAís. It isnít dependent on a standardized supply voltage, it has good noise immunity for this type of application, the timing accuracy is very good, and the bandwidth exceeds the requirements of digital audio.

Initially Iíd thought to use discreet parallel LVDS links for each of the I2S lines. The biggest problem with this is that for multi-channel, it would require expensive cable and connectors. There also could be a problem with timing skew between the links, especially with longer distances.

A Serializer-Deserializer (SERDES) approach offers quite a few advantages over parallel: Multiple signals can be sent over a single twisted pair. This allows a much cheaper CAT5 cable and modular connector system to be used. Since the data is reclocked, buffered, and synchronized at the receiving end, SERDES is virtually immune to skewing, and offers additional jitter rejection.

SERDES can be implemented either with a clock embedded into the data (a single LVDS pair required), or a clock separate from the data (two LVDS pairs required). (Most SERDES chipsets with imbedded clocks have managed to avoid the data-dependant clock recovery problems that are associated with S/PDIF.)

The SERDES transmitter requires a control clock that is synchronous to and a multiple of the data being transmitted. In this case that clock would be the MCLK of the disk player. Most disk players use either 256fs or 384fs for their MCLK. The possible frequency range for MCLK then becomes 11.2896MHz (44.1KHz CD w/ 256fs) to 73.728MHz (192KHz MLP DVD-A w/ 384fs). This turned out to be the primary consideration in choosing a particular SERDES chipset. The SERDESí PLLs need to be able to operate over this frequency range.

The only SERDES chipset that I was able to identify with this PLL frequency range was TIís MuxIt devices. This is a four chip solution for one data link: a PLL (SN65LVDS150) and a Multiplexer (SN65LVDS151) for the transmitter side, and a PLL (SN65LVDS150) and Demultiplexer (SN65LVDS152) for the receiver side. MuxIt uses separate LVDS clock and data pairs. It can be configured to pass between four and ten parallel data lines (not including MCLK).

A CAT5 cable has four twisted pairs. A MuxIt link requires only two of these pairs.
I use one of the extra twisted pairs as a ground link between the transmitter and receiver units. The juryís still out on whether itís better to have this ground connection or not. It can prevent the LVDS signals from exceeding the common mode range of the devices, but it also could possibly introduce a ground loop. So far, I havenít experienced any problems with it connected or disconnected.

There are a couple of possible uses for the fourth twisted pair: remote power, or a master clock signal to the transmitter from the receiver. This master clock could be used to synchronize the transmitter (such as a disk player) to the DAC or digital amp. There are two constraints with this: the transmitter would have to be able to synch off of an external clock, and the receiver would need to know what frequency the transmitter required (this might change for different disks). Because these constraints make it harder to implement a Ďuniversalí interface, I choose not to send back a master clock at this time.

I tried running a MuxIt link from a DVD-A player to the SA-XR10 digital amp, using the recovered clock sent from the DVD-A to clock the Equibit section. Not only was I able to hear multichannel surround without the analog link for the first time (wow!), I found there to be a substantial sonic improvement on regular stereo CDís compared to the S/PDIF interface (the thing that inspired me to focus on this exercise in the first place). I realized that the S/PDIF link on these units was hardly optimized (lots of board-to-board interconnects, etc.), but I still was surprised. To help convince myself that this wasnít purely psychological, I A/Bíd the interfaces (using a button on the remote) for several people. Everyone preferred the MuxIt interface, saying that they could hear better detail, or that things sounded clearer. By contrast, the difference going from the analog link to S/PDIF was more along the lines of improved depth and imaging. (I want to avoid debates on comparison testing or subjective descriptions. This is what I tried, this is the best I can do to describe it in print.)

(continued in part 2...)

Brian Brown 14th November 2003 09:56 PM

(...continued from part 1)

I then added three (for six channels) Asynchronous Sample Rate Converters (ASRC) after the MuxIt receiver. This allowed the use of a local MCLK at the digital amp for further jitter reduction (fixed at 96KHz), as well as accommodating PCM format conversions. The MCLK from the transmitter isnít used for anything other than for the receiver PLL. I configured the MuxIt multiplier as times six and send five audio data lines (BCLK, LRCLK, FDATA, SDATA, and CSWDATA). I have a jumper on the transmitter for the sixth data line to indicate whether the source is I2S or Right-justified 24bit format. This format line is fed to the mode pins of the ASRC devices, allowing them to automatically handle format conversions.

I laid the board out to accommodate either the AD1896 or SRC4192 ASRC devices. Theyíre mostly footprint compatible. The AD1896 requires a daisy chain link to keep multiple devices synchronized in Matched Phase Mode (The SRC4192 doesnít require these links and ignores them). The SRC4192 requires an external oscillator for its internal logic (the AD1896 can also use a crystal).

So far, Iíve only used the AD1896 devices (Iíve got SRC4192 devices on backorder). Itís a little strange: on some recordings they seem to make a big improvement, on others thereís little or no difference. This distinction doesnít seem to fall along a boundary of what I would consider good quality recordings vs. lessor quality recordings. Some Ďgoodí recordings seem to sound better with the ASRC, some donít. Some Ďlesserí recordings seem to sound better with the ASRC, some donít. At least there havenít been any instances where I thought the sound was degraded. I have to point out that these observations are even more subjective than the MuxIt vs. S/PDIF comparisons. I donít currently have the capability to do a pushbutton A/B comparison.

The ASRC devices do definitely make it much easier to interface to a variety of units.

For SACD, I added a SM5816AF DSD to PCM converter to the transmitter board. This chip outputs 8fs PCM (six mono 352.8KHz 28bit bitstreams) or 2fs PCM (88.2KHz 28bit I2S). Iím using the latter, since itís I2S. (Thereís an upcoming SM5819AF that offers 4fs PCM (176.4KHz I2S), but I havenít got my hands on any yet.)

I decided to stick with I2S PCM for the time being because itís what I know. I still donít have a strong opinion on the SACD vs. DVD-A debate. I think they both sound better than any of the previous available consumer formats. For me, the important thing is that some recordings are coming out on SACD only, and some are DVD-A only. I want to be able to play either.

Thatís about it for the overview description. Iíll try to get some pictures and schematics posted later this weekend.


Brian Brown 14th November 2003 10:27 PM

2 Attachment(s)
PCM MuxIt Transmitter Board:

Brian Brown 14th November 2003 10:29 PM

2 Attachment(s)
MuxIt Receiver and ASRC Board:

Brian Brown 14th November 2003 10:31 PM

2 Attachment(s)
DSD to PCM MuxIt Transmitter Board:

jwb 15th November 2003 05:03 AM

Outstanding, and good looking work. Care to share any artwork? There have been some other threads on using LVDS and MDR twinax cables for sending the three-wire I2S signal.

Brian Brown 15th November 2003 05:09 AM

2 Attachment(s)
PCM MuxIt Transmitter Schematic
(.zip of .pdf)

Brian Brown 15th November 2003 05:48 AM

2 Attachment(s)
MuxIt Receiver and ASRC Schematic
(.zip of .pdf)

Sorry, but I really had to crank down the resolution to get this under the 102.4K attachment limit.

Brian Brown 15th November 2003 05:57 AM

2 Attachment(s)
PCM MuxIt Transmitter Gerbers
(.zip of 274x)

Note, I've made a few minor tweaks to this since the first board was made. I think it's good, but it's untested.

Brian Brown 15th November 2003 06:01 AM

2 Attachment(s)
MuxIt Receiver and ASRC Gerbers
(.zip of 274x)

Note, I've made a correction, and a few other minor tweaks to this since the first board was made. I think it's good, but it's untested.

All times are GMT. The time now is 10:57 PM.

vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2