Table of Contents | ||||||
---|---|---|---|---|---|---|
|
...
A playback stream carries audio data over an isochronous OUT endpoint. There is a one-to-one relation between an isochronous OUT endpoint, an AudioStreaming interface and a Terminal. 101482827 presents the audio data flow implemented inside the Audio Processing module. The playback path relies on a ring buffer queue to synchronize the playback task, the core task and the codec ISR.
...
Panel | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||
(1) The host activates the AudioStreaming interface #X by selecting the operational interface (request SET_INTERFACE sent for alternate setting 1). The host then sets the sampling frequency for a certain isochronous IN endpoint by sending SET_CUR request. The function (2) When processing the SET_CUR(sampling frequency) request, the audio class will also start the record stream on the codec side by calling
(3) Once the first DMA transfer has completed, the audio peripheral driver will obtain the next receive buffer from the ring buffer queue by calling (4) The buffer will be filled with audio samples given by one or more ADCs (one ADC per logical channel). The buffer will contain 1 ms worth of audio samples. This 1 ms of audio samples should be encoded, either directly by the codec (hardware) or by the audio peripheral driver (software). Most of the time, the codec will provide the chunk of audio stream already encoded. The driver signals the end of an audio transfer to the record task by calling the function (5) The record task wakes up and retrieves the ready buffer from the audio peripheral driver by calling the audio peripheral driver function (6) To prime the audio stream, the record task waits for a certain number of buffers to be ready. The pre-bufferring threshold is always equal to ( There is a special situation where the record task can submit a new transfer. When the stream communication loop is broken, that is there are no more ongoing isochronous transfers in the USB device driver, the record task restarts the stream with a new USB transfer. (7) The USB device driver will send isochronous audio data to the host during a specific frame. (8) Upon completion of the isochronous IN transfer, the core task will call the callback
(9) The core task submits all the ready buffers it can to the USB device driver by calling
(10) Once the audio stream is initiated, the steps 3 to 8 will repeat over and over again until the host stops recording by selecting the default AudioStreaming Interface (request SET_INTERFACE sent for alternate setting 0). At this time, the Audio Processing will stop the streaming on the codec side by calling the audio peripheral driver function
|
...
Panel | ||||
---|---|---|---|---|
| ||||
Figure - Adding a Sample in Case of Underrun illustrates the algorithm to add an audio sample in case of underrun situation.
...
Warning |
---|
This stream correction is convenient for low-cost audio design. It will give good results as long as the incoming USB audio sampling frequency is very close to the DAC input clock frequency. However, if the difference between the two frequencies is important, this will add audio distortion. |
Figure - Removing a Sample in Case of Overrun illustrates the algorithm to remove an audio sample in case of overrun situation.
...
The playback stream correction offers the possibility to apply your own correction algorithm. If an underrun or overrun situation is detected, an application callback is called. Listing - Example of Playback Correction Callback Provided by the Application shows an example of playback correction callback prototype and definition provided by the application.
...
Panel | ||
---|---|---|
| ||
(1) Prototype of your playback correction callback. (2) Upon configuration of an AudioStreaming interface with the function (3) Definition of your playback correction callback. Once the playback is open by the host and the built-in playback correction is enabled (
Beside the AudioStreaming alternate setting configuration structure, you will know the situation type (underrun or overrun via |
...
Consequently, if the lower limit is reached, you have an overrun situation, that is the USB side consumes a little bit faster than the the codec can produce. Conversely, the upper limit corresponds to an underrun situation, that is the USB side does not consume fast enough the audio samples produced by the codec. As opposed to the playback stream correction, no software algorithm is needed to add or remove an audio sample. The audio class will adjust the audio peripheral hardware by using the number of required record data bytes indicated by USBD_Audio_RecordBufGet()
. The correction is done implicitly by the audio peripheral hardware by directly getting the right number of audio samples (-1 sample frame or +1 sample frame) to accommodate the overrun or underrun situation.
The frequency at which the record stream correction is evaluated is configurable via the field CorrPeriodMs
of the structure USBD_AUDIO_STREAM_CFG
.
Playback Feedback Correction
...
The feedback value update to the host is evaluated every refresh period. The refresh period is configurable via the field CorrPeriodMs
of the structure USBD_AUDIO_STREAM_CFG
. When the refresh period is reached, if there is a correction to apply, the feedback value update is sent to the host by calling the function USBD_IsocTxAsync()
. If there is no correction necessary, the audio class does not prepare an isochronous IN transfer. Thus when the host sends an IN token, a zero-length packet is sent by the device. The host interprets this zero-length packet as "continue to apply the previous valid feedback value". The feedback value is sent in 10.14 format.
...