Digital Audio Links
Oct 21, 2004 at 12:13 AM Thread Starter Post #1 of 21

gaboo

100+ Head-Fier
Joined
Apr 20, 2004
Posts
465
Likes
0
I've not given up on a FAQ yet, but with little time to write it, I've decided to "dump" most of the relevant links here.


Paper on CD Audio. Despite the name, it covers the basic concepts of digital audio: sampling, aliasing, quantization, dither, jitter. Good intro.


Julian Dunn was commissioned to write a series of four tech notes for Audio Precision, a testing equipment manufacturer. These are the most comprehensive, easy to read articles I found on the web on these "hot" issues. You should read them in this order (as they contain backward references):

Jitter Theory
ADC Measurements
DAC Measurements
AES/EBU & S/PDIF

From the same author, the famous S/PDIF flawed ? paper (1992).


Articles from Stereophile archives. Take the year into account when reading, generalizing comments about equipment should be viewed in that perspective.

Jitter, Bits, & Sound Quality (1990): their first stab at jitter, theory & simulations
The Jitter Game (1993): their first measurements
Jitter & the Digital Interface(1993): more of the same, better intro
Bits is Bits, but clock is clock (1996). Updated version of Julian Dunn's "S/PDIF flawed ?" paper.


Reducing jitter in the world of S/PDIF (& AES/EBU). From a manufacturer of such devices, but seems fairly unbiased.
Innards of a reclocking chip: CS8427. Basically: decoder, buffer, encoder.
Word clock is a simple, but non-standard addition the standard AES/EBU. It is mentioned in appendix B of AES11.

S/PDIF alternatives:

I2S allows the DAC to be the master clock. It only defines a bus, it's not a complete standard. Several physical implementations exist, most noticeable I2S enhanced.

USB Audio allows for both isochronous and asynchronous transfers. The asynchronous version completely eliminates transmission jitter, at the risk of buffer underrun.
Breaking news (10/23/04, thanks to 00940): Hitoshi Kondoh, from Burr Brown has writen a detailed article on the USB implementation of their PCM2702 USB DAC (adaptive isochronous mode), and how SpAct (basically a time-optimal PLL) came to be. The claim is that using SpAct one can achive both low jitter, and a fast locking PLL, thus avoiding noticeable startup delays. We're still waiting for part 3 of the article to show up online...

Firewire audio (IEC-61883-6) is unfortunately jittery.


More to come. Stay tuned, and please contribute!
smily_headphones1.gif
 
Oct 21, 2004 at 12:20 AM Post #2 of 21
You should also include this paper which is short but describes the basics of digital audio (though not as extensively as the one you linked) and digital compression (as in file size reduction, not dynamic range reduction).
 
Oct 21, 2004 at 12:43 AM Post #4 of 21
Quote:

Originally Posted by Mr.Radar
You should also include this paper which is short but describes the basics of digital audio (though not as extensively as the one you linked) and digital compression (as in file size reduction, not dynamic range reduction).


I'm not very much into lossy encoding, and there are quite a few algorithms to cover, some proprietary. If you'd like to cover this, please go ahed. Your post is right under mine, so it will be a nice follow-up.
smily_headphones1.gif


The best resource for that is probably hydrogenaudio.org, they have FAQs for all major formats, etc.

I have some stuff on high-res formats, and some so-so papers on audio > 20Khz, but I need to find urls to them...
 
Oct 23, 2004 at 8:55 PM Post #7 of 21
These links are quite amazing.

It is just unbelievable how much energy these guys spend on digging themsleves out of the first wrong decision to implement isochronous versus asynchronous USB audio. This thinking is deeply entrenched in audio folks and really hard to overcome.

Since USB is fundamentally an asynchronous bus and you have to construct your isochronous rate by sending packets that on average match your target data rate they end up with these bizarre problems.

All that PLL business goes away as soon as you do burst mode with flow control. All you have to worry about at that point is a stable local clock that feeds the data from the local buffer to the DACs or digital output.

You still ave to make sure that the voltage swings from receiving packets don't interfere with the rest of your logic but you could use the power from the usb bus to drive the receiver. Then galvanically separate the signal from the rest of the circuit which runs of it's own separate power supply.

The question comes back to the USB-audio driver in the popular OSs. If asynchonous audio is supported building a high quality USB DAC should not be to hard.

Cheers

Thomas
 
Oct 23, 2004 at 10:02 PM Post #8 of 21
Quote:

Originally Posted by thomaspf
The question comes back to the USB-audio driver in the popular OSs. If asynchonous audio is supported building a high quality USB DAC should not be to hard.


The default Linux USB audio driver supports an asynchonous audio pipe. I've read the source myself and say so.
icon10.gif
Don't know how many USB receivers support that though...

Anyway, the article linked by 00940 has this awesome subtitle (in part 2 towards the end): The Terrors of the Isochronous Mode.
eggosmile.gif
 
Oct 23, 2004 at 10:05 PM Post #9 of 21
Quote:

Originally Posted by gaboo
Don't know how many USB receivers support that though...


That's the whole problem. And among those hypothetical receivers, how many do support hardware config ? I hate to play with microcontrollers.
 
Oct 25, 2004 at 12:19 PM Post #10 of 21
Nice set of links, thanks for posting. I read the one about firewire jitter.
I'm not sure I understood all of it. But I think the topology they used
for their "test" circut is not representative of what might exist in a
typical home playback system. They had 15 nodes between the sender and receiver of data. Each node introduces jitter through the reclocking of the relayed data. In a typical home system it is more likely to have just the sender and receiver on the bus, no need for 15 intervening relay nodes (disks would be put on a different firewire bus).

According to this paper:
"8.4.5 For applications with only one destination and with a source, such as a
playback device, that can have it’s transmission rate manipulated the destination
receiver could control the synchronisation. This mode of operation is used in some
consumer audio equipment now in order to avoid jitter from clock recovery circuits.
This control could be based on flow control instructions (software handshaking) or on
the timing of another isochronous “sync-channel” from the signal receiver back to the
signal transmitter."

I wonder if this is being done in most "consumer audio equipment". Specifically I wonder about my m-audio audiophile firewire. This paper was written in 1999. I wonder what, if any, advancements have been made since then...
 
Oct 25, 2004 at 4:02 PM Post #11 of 21
The standard implementation of audio over firewire IEC-61883-6 does to my knowledge only specify an isochronous transfer mode.

However, individual equipment vendors like Pioneer have implemenented proprietary modes that works between their own equipment which are slaving the the source from the clock of the DACs.

I have no knowledge about the M-audio firewire but the link between the PC and the breakout box is probably an M-audio proprietory protocol. Have you asked theor technical support whether it is asynchronous?

Cheers

Thomas
 
Oct 27, 2004 at 9:16 PM Post #12 of 21
To the question on wether the Windows USB Audio System driver supports asynchronous sinks, the answer seems to be yes!

However, there seem to be few devices out there in the market that implement this. Can anyone point to a chip that implements this mode in theor USB audio stack.

Cheers

Thomas
 
Oct 28, 2004 at 7:08 AM Post #13 of 21
Quote:

Originally Posted by thomaspf
To the question on wether the Windows USB Audio System driver supports asynchronous sinks, the answer seems to be yes!

However, there seem to be few devices out there in the market that implement this. Can anyone point to a chip that implements this mode in theor USB audio stack.

Cheers

Thomas



Dallas used to make DS4201. I think that's the one Linux kernel makes reference to. But Dallas was bought out by Maxim. Their product is no more. Info from here.

Don't know any existing chips.

EDIT: Maxim only makes cheap DACs. All their 16bit DACs talk SPI (Motorola) protocol. This is overkill for a DAC because you don't need two way communication. But it can be interfaced with Motorola microcontrollers easily.
I think they target mobile phones and stuff like that.
 
Oct 28, 2004 at 9:34 PM Post #15 of 21
I've been waiting to get my hands on this information. Actually, waiting is the keyword here, as I can clearly see that I didn't look hard enough!
Anyway, I think this thread deserves to be a sticky one. And BTW, it would be great if people just kept posting more links to good documents like these.
rolleyes.gif
 

Users who are viewing this thread

Back
Top