Asynchronous USB DAC clock source

Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Jump to Latest
H

Hitec

Member
Joined 2010
I would like to discuss about USB DAC clock sources. I have somewhat clear vision of the DAC I am about to design but the clocking is unclear.

So I have a µcontroller equipped with USB and I2S and I have a DAC chip that has an I2S connection. Where do I get the sample clock reference? Take for instance the PCM1792 DAC. It has three clock inputs: LRCK, BCK and SCK. LRCK is the clock that tells which channel to output the current sample to, BCK is the clock that clocks single bits on the data line and then there is SCK that is the system clock.

The question is: where do I put my 100€ 0.0001ppm oscillator to? :) As far as I know, the µcontroller "orders" samples from the host computer and outputs them to I2S IF but does it work as a master or slave? That is, does it deliver the clock to the DAC or not?

It sounds rather "not hifi" if the DAC does not work with its own well defined clock source. Or do I just have to take care of that the µcontroller I2S buffer never gets empty and it will clock the data to I2S with low jitter? PCM1792 DS: "The PCM1792A requires the synchronization of LRCK and system clock, but does not need a specific phase relation between LRCK and system clock" --> how do I achieve this?

I have been thinking of a USB DAC for a while but I just got into details and I am in a hurry as I have to have gerbers ready on Monday and nothing is on the paper right now :)

And sorry if there is already a thread for this. Did not find with quick search (I have read the threads about WaveIO etc.).
 
H

Hitec

Member
Joined 2010
Well anyway, there is my protoboard schematic in case someone wants to review it: PCM1794A-DAC.

There is not much to see anyway. It's almost a direct copy of the PCM1794A DS "typical application circuit". I just added an oscillator to SCK. I don't yet know if I need it though. The complete prototype includes an MBED board that has USB, I2S and nice libraries so even an electronics engineer may be able to write some functional code :rolleyes:

I will draw the layout now so lets see what pops out :)

Oh and I didn't draw diff2single converters as my speakers like differential inputs.
 
C

counter culture

Member
Joined 2011
A typical USB DAC employs isochronous mode for transfer. Data is sent in bursts every millisecond. There is no error-checking and no re-transmit.

A TI DAC chip, such as the PCM2706/7 is often employed as the USB receiver. This will have a 12MHz crystal external to it providing the clock reference. The actual (audio) clock frequency is negotiated between the DAC and the USB host on the basis of the host's clock, but TI provide no details of exactly how this is achieved.

These chips have built-in audio (analog) processing, but can also be used to supply S/PDIF or I2S digital outputs.

The PCM2706 has I2S outputs which will be routed to a second DAC chip such as the PCM1792A if the design calls for a higher quality chip to be used. The PCM2706, with its external clock, will be responsible for providing the timing information implicit in the I2S outputs.

This arrangement means that no driver requires to be written for the DAC, both Windows and Linux provide a built-in audio drivers which are compatible with the PCM270x series chips. When plugged into the USB port on the computer the chip wakes up and provides information to the computer which enables the set-up of USB end-points sufficient for the normal operation of the DAC

If it is desired to employ a second clock to re-clock the data at the DAC, it would be necessary to intercept the I2S output from the chip, buffer it, and re-send it to the second DAC, in order to account for any possible differences in speed between the 2 clocks.

It is, of course, possible to implement a DAC using a uProcessor as you describe.

Here is an application note describing the setup of an (isochronous) Audio Class device using a uProc http://www.silabs.com/Support%20Documents/TechnicalDocs/AN295.pdf

Later standards for USB audio exist which provide for genuine asynchronous communications, but only 3rd-party drivers exist under Windows, although an open-source driver is available under Linux. The 3rd-party drivers are not available free under Windows.

The task becomes much more difficult in this case, since a custom USB driver is required, and, since the introduction of Windows 7, Microsoft requires an expensive validation certification to create custom USB drivers. It may be possible to circumvent this using the available HID interface, but you would have to investigate this for yourself. See:- Building a PIC18F USB device - WFFwiki
 
H

Hitec

Member
Joined 2010
Ok thank you for good explanation. I was about to do this board using PCM2706/7 but then found out the MBEDs USB-audio libraries and thought it would be nice to try higher sampling rate than that of the PCM2706/7 (limited to 44.1k I think). And I don't touch the MS crap at home :) At work I am limited to it but there it doesn't matter which sound output I have.

I am not a programmer and try to avoid that kind of stuff and that's why the PCM2707 sounded tempting. But with MBED it goes like this (a bit like Arduino but with more professional goals I think):

Code: 
// Hello World example for the USBAudio library
 
#include "mbed.h"
#include "USBAudio.h"
 
Serial pc(USBTX, USBRX);
 
// frequency: 48 kHz
#define FREQ 48000
 
// 1 channel: mono
#define NB_CHA 1
 
// length of an audio packet: each ms, we receive 48 * 16bits ->48 * 2 bytes. as there is one channel, the length will be 48 * 2 * 1
#define AUDIO_LENGTH_PACKET 48 * 2 * 1
 
// USBAudio
USBAudio audio(FREQ, NB_CHA);
 
int main() {
    int16_t buf[AUDIO_LENGTH_PACKET/2];
    
    while (1) {
        // read an audio packet
        audio.read((uint8_t *)buf);
 
        // print packet received
        pc.printf("recv: ");
        for(int i = 0; i < AUDIO_LENGTH_PACKET/2; i++) {
            pc.printf("%d ", buf[i]);
        }
        pc.printf("\r\n");
    }
}

I just don't know what USB audio mode it is using but I have to get into it later when I get my hands on the prototype.

But so far I don't understand why the complicated reclocking and buffering is needed (like the I2S FIFO project introduced here). I always like simple and elegant solutions. Is it really so that there exist no DACs that work as I2S masters and clock the data from the µcontroller by its own clock and the µcontroller would just take care of the audio buffering in asynchronous base.

Well I have also drawn a board that includes SRAM and an FPGA so maybe this will be my "the ultimate audio project" :)


EDIT: the MBED USB audio library is using isochronous mode. But there are also references that the I2S can be used in slave mode so I think it should be possible to clock the PCM1704 with its own oscillator and then to use a low jitter PLL to clock out the bits from the MBED as an I2S slave. It would buffer the samples. But is it so that the isochronous transfer mode keeps sending packets at its own pace and this will eventually lead to lost packets as the two clocks differ slightly? So I think what I want here is really the asynchronous mode.
 
Last edited:
C

counter culture

Member
Joined 2011
It is really so that very few USB DACs have independent low-jitter clocking. USB Audio Class 2 asynchronous DACs do offer clocking from the DAC's own clock and data download from the PC on demand.

You might like to look at this thread which details a scheme for reclocking (S/PDIF data) using an FPGA and shows some VHDL: http://www.diyaudio.com/forums/digital-source/185996-wakibaki-s-huff-puff-fll-asynchronous-reclocking-spdif-receiver.html

You can see some other discussions of USB audio here:- http://www.diyaudio.com/forums/digital-source/184313-what-am-i-missing-async-reclocking.html
 
tiefbassuebertr

tiefbassuebertr

Member
Joined 2005
tiefbassuebertragung.de
Last edited:
Status
This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.
Top Bottom