I am developing what is essentially a USB soundcard using a K60 device. I am a little concerned about how to sync the USB packet rate from the PC through the K60 to the hardware codec connected to it with I2S. I have read that adaptive or aynchronous modes of the USB audio class are the way to go for low jitter and high quality reproduction.
Competitors' offerings contain a PLL which synchronises the 1ms SOF packets and the codec Master Clock. Does Kinetis have this functionality? If not, how would synchronisation be implemented?
To work with Audio, you need to use isochronous transfer to ensure timeliness.
You can have Audio device class examples in Freescale USB stack ver 3.1
Thanks for your reply. I agree isochronous is a definite requirement for the guaranteed throughput of an audio stream over the USB.
Isochronous is split up into sub-modes of which adaptive and asynchronous are the most important for high quality reproduction. My question is more to do with the implentation of these sub-modes, in particular syncing the USB sample rate to the Hardware Codec to avoid buffer overrun or high jitter. I was after any details of support within Kinetis for this, either hardware or software.
Competitors' devices seem to implement a hardware PLL to do this job. Has anyone used Kinetis for async /adaptive sub-modes? Maybe a soft PLL to control an external clock synth chip is required?
I think the USB Adio class from Freescale using synchronous mode but not adaptive or asynchronous
There is an example which they combine USB Audio class with SGTL5000 stereo code in MQX 3.8, using dual buffers to prevent overrun... Not sure if its quality is good enough or not.
I think I am going to need an external clock chip to provide the Master clock to the hardware codec in order to get synchronisation with the USB packet rate. The Kinetis will have to control the clock chip, issuing corrections when buffers are nearing their endstops.
Dave, as you said, USB Audio requires a way to keep the audio clocks synched.
When the MCU is the sink (receiving audio data):
Adaptive: you can recover the clock from the data rate. Meaning that you would need an external PLL or clock synthesizer to adjust the audio clocks (go faster or slower) to avoid buffer underrun or overrun.
This is a good method, however, you're adjusting clocks, adding some jitter and impacting audio quality.
Asynchronous (with feedback): On this method, the audio clocks are fixed, no need to change clocks (a plus against adaptive).
On this synch method, the MCU keeps tracks of the audio buffers and rate. For instance, you have a circular buffer, USB audio is the write pointer and the I2S is the read pointer. You can measure the distance between both pointers and evaluate if there are too close or too far.
If there are too close, you request less samples to the USB host thru the feedback endpoint, if there are too far, you request more samples to the USB host.
Example can be, if you have 48Khz audio and detect that the pointers are too close, you require less samples, send a 47.9 samples to the host or if you require more samples, then send a 48.1.
This will translates into one more or one less sample per channel on a USB audio packet.
In the case the MCU is the audio source (microphone), the adaptive implements the feedback endpoint. And you can use the same method as the asynchronous to ask the host to request less or more data.