UAC2.0 Microphone: Audio artifacts with STM32L432 DMA > tud_audio_write() - Need guidance on proper buffering

[martijnvdwoude]

Hi! I'm working on a UAC2.0 FS microphone using the STM32L432 and cannot get audio to work properly. I'm new to this, and I have been trying to get this to work for a few weeks now and cannot figure out what I'm doing wrong.

SYSCLK and ADC from HSI16: 72MHz
TIM2 for sampling the ADC: 48kHz
USB: HSI48 with CRS

I have hardware oversampling enabled and it outputs 16-bit unsigned integers at 48kHz: confirmed working.

Now I need to send these samples over USB.

Using flow control in tusb_config.h:

//--------------------------------------------------------------------
// AUDIO CLASS DRIVER CONFIGURATION
//--------------------------------------------------------------------

// Audio interface - 48kHz mono microphone
#define CFG_TUD_AUDIO_FUNC_1_SAMPLE_RATE              48000

#define CFG_TUD_AUDIO_FUNC_1_DESC_LEN                 TUD_AUDIO_MIC_ONE_CH_DESC_LEN

#define CFG_TUD_AUDIO_FUNC_1_N_AS_INT                 1
#define CFG_TUD_AUDIO_FUNC_1_CTRL_BUF_SZ              64

#define CFG_TUD_AUDIO_ENABLE_EP_IN                    1
#define CFG_TUD_AUDIO_FUNC_1_N_BYTES_PER_SAMPLE_TX    2         // 16-bit samples
#define CFG_TUD_AUDIO_FUNC_1_N_CHANNELS_TX            1         // Mono
#define CFG_TUD_AUDIO_EP_SZ_IN                        TUD_AUDIO_EP_SIZE(CFG_TUD_AUDIO_FUNC_1_SAMPLE_RATE, CFG_TUD_AUDIO_FUNC_1_N_BYTES_PER_SAMPLE_TX, CFG_TUD_AUDIO_FUNC_1_N_CHANNELS_TX)

#define CFG_TUD_AUDIO_EP_IN_FLOW_CONTROL              1

#define CFG_TUD_AUDIO_FUNC_1_EP_IN_SZ_MAX             CFG_TUD_AUDIO_EP_SZ_IN
#define CFG_TUD_AUDIO_FUNC_1_EP_IN_SW_BUF_SZ          4 * CFG_TUD_AUDIO_EP_SZ_IN // Buffer for audio samples

DMA buffer sized to 48*2:

#define ADC_BUFFER_SIZE         96

static uint16_t adc_buffer[ADC_BUFFER_SIZE];

void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc)
{
    if (hadc->Instance == ADC_INSTANCE) {
        // Pass first half of buffer (samples 0 to 47)
        uint32_t half_size = ADC_BUFFER_SIZE / 2;
        adc_callback(&adc_buffer[0], half_size);
    }
}

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)
{
    if (hadc->Instance == ADC_INSTANCE) {
        // Pass second half of buffer (samples 48 to 95)
        uint32_t half_size = ADC_BUFFER_SIZE / 2;
        adc_callback(&adc_buffer[half_size], half_size);
    }
}

void adc_callback(uint16_t* samples, uint32_t count)
{    
    // Convert samples from unsigned to signed 16-bit and store
    static int16_t signed_samples[48]; // Max samples per callback
    for (uint32_t i = 0; i < count && i < 48; i++) {
        signed_samples[i] = (int16_t)(samples[i] - 32768);
    }
    
    extern void store_adc_samples(int16_t* samples, uint32_t count);
    store_adc_samples(signed_samples, count);
}

// USB audio buffer for streaming
static int16_t usb_audio_buffer[AUDIO_SAMPLE_RATE / 1000]; // 48 samples

static volatile bool new_audio_data = false; // Flag set by ADC callback, cleared by main loop

// Function to store ADC samples directly in USB buffer
void store_adc_samples(int16_t* samples, uint32_t count)
{
    // Copy directly to USB audio buffer (simple memcpy equivalent)
    for (uint32_t i = 0; i < count && i < (AUDIO_SAMPLE_RATE / 1000); i++) {
        usb_audio_buffer[i] = samples[i];
    }
    new_audio_data = true; // Signal main loop that new data is available
}

while (1) {
    // Handle USB stack
    tud_task();
    audio_task();
}

void audio_task(void)
{
    // Only process when ADC callback has signaled new data
    if (!new_audio_data) return;
    
    // Only send audio when interface is actively streaming
    if (!audio_streaming) {
        new_audio_data = false; // Clear flag even if not streaming
        return;
    }
    
    // ADC callback already filled usb_audio_buffer directly
    const uint32_t samples_per_ms = AUDIO_SAMPLE_RATE / 1000; // 48 samples
    const uint32_t buffer_size = samples_per_ms * CFG_TUD_AUDIO_FUNC_1_N_BYTES_PER_SAMPLE_TX;
    
    // Send samples to TinyUSB (data already in usb_audio_buffer)
    tud_audio_write((uint8_t*)usb_audio_buffer, buffer_size);
    
    // Clear flag after processing
    new_audio_data = false;
}

I have also tried it without an audio_task and just call tud_audio_write directly in the DMA callback, but this produces the same bad audio:

void adc_callback(uint16_t* samples, uint32_t count)
{
    static uint32_t callback_count = 0;
    callback_count++;
    
    // Convert samples from unsigned to signed 16-bit
    static int16_t signed_samples[48]; // Max samples per callback
    for (uint32_t i = 0; i < count && i < 48; i++) {
        signed_samples[i] = (int16_t)(samples[i] - 32768);
    }
    
    // Send directly to USB
    const uint32_t buffer_size = count * 2; // 2 bytes per 16-bit sample
    tud_audio_write((uint8_t*)signed_samples, buffer_size);
}

Descriptors look good to me with asynchronous and 98 bytes:

Endpoint Descriptor:
    bLength                 7
    bDescriptorType         5
    bEndpointAddress     0x81  EP 1 IN
    bmAttributes            5
        Transfer Type            Isochronous
        Synch Type               Asynchronous
        Usage Type               Data
    wMaxPacketSize     0x0062  1x 98 bytes
    bInterval               1
    AudioStreaming Endpoint Descriptor:
        bLength                 8
        bDescriptorType        37
        bDescriptorSubtype      1 (EP_GENERAL)
        bmAttributes         0x00
        bmControls           0x00
        bLockDelayUnits         0 Undefined
        wLockDelay         0x0000

But I'm seeing artifacts in the audio. Noise, crackle and incorrect tones. The audio sounds modulated/robotic with pitch shifts. See the screenshot (should be a fairly clean tone at ~330Hz). I have found that these 'cuts' happen at exactly 288 samples (6 ms):

I know my analog front-end is working fine, confirmed by an oscilloscope. Signal looks good on the ADC. Hardware oversampling is producing clean 16-bit values as expected.

I know I'm probably doing this the wrong way and my buffering and handing the samples to TinyUSB is naive.

1. Do I need a DMA size of twice the number of samples per packet? Or should I use smaller DMA buffer size for tud_audio_write?
2. What is the recommended way to get my DMA samples to tud_audio_write?
3. Are there some examples or documentation for this? I have looked at uac2_headset and cdc_uac2 but these don't show how to implement this with real hardware DMA callbacks.
4. Could this be a clock domain issue between my device's 48kHz and the host's 48kHz? I understand CFG_TUD_AUDIO_EP_IN_FLOW_CONTROL should handle this, but maybe I'm not using it correctly?

I would really appreciate some pointers or just a short general high-level description on how to implement this would be great. What am I missing here?

Thank you in advance for any help and for writing this great library!

[martijnvdwoude]

Sorry, but is this an AI generated response?

[martijnvdwoude]

Just an update FWIW. When I substitute the 48 ADC samples in the DMA callback with a simple sawtooth I get artifact-free data. This seems to confirm that the timer and flow control is working correctly, and the problem is instead with my ADC/DMA setup. Not sure why yet, but it indicates to be a problem with my implementation.

[HiFiPhile]

I'm in vacation without my PC so can't help you a lot.
To test ADC+DMA you can:

1. Create a timer interrupt for every 1ms
2. Save the DMA data in a ram buffer
3. Play a 1khz test tone with your phone
4. Check if you got right amount of data in the buffer between 2 interrupt, then plot the data if you can get 1khz sinus.

It's fine to write data to USB directly from DMA interrupt, no need to count 48 samples for each write, audio class has flow control to correct clock drift.

[martijnvdwoude]

@HiFiPhile Thank you for your pointers! I appreciate you taking some time to respond.

We have done some more rigorous tests and are still getting regular 288-sample jump cuts in the audio when recording in Audacity. The audio is actually good for about

#define ADC_BUFFER_SIZE         96

static uint16_t adc_buffer[ADC_BUFFER_SIZE];

void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc)
{
    if (hadc->Instance == ADC_INSTANCE) {
        const uint32_t half = ADC_BUFFER_SIZE / 2;
        uint16_t *raw = &adc_buffer[0];

        // flip sign-bit in place
        for (uint32_t i = 0; i < half; i++) {
            raw[i] ^= 0x8000;
        }

        tud_audio_write((uint8_t*)raw, half * sizeof(uint16_t));
    }
}

void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)
{
    if (hadc->Instance == ADC_INSTANCE) {
        const uint32_t half = ADC_BUFFER_SIZE / 2;
        uint16_t *raw = &adc_buffer[half];

        // flip sign-bit in place
        for (uint32_t i = 0; i < half; i++) {
            raw[i] ^= 0x8000;
        }

        tud_audio_write((uint8_t*)raw, half * sizeof(uint16_t));
    }
}

We're feeding a 1kHz sine wave through the analog front-end.

Audacity recording:

The weird thing is that when I store 4096 of these samples to RAM in the DMA callbacks and dump them over CDC and plot them I see no cuts at all and everything looks fine:

This leads me to believe our PCB design and ADC/DMA/oversampling configurations are working fine. I have pretty much tried everything I can think of these last few weeks, but granted I'm new to this library and USB audio in general.

As I'm reading the audio_device.c/h code I can tell that the internal FIFO and flow control should handle this, as well as priming the first packet and keeping the buffer at the right level et cetera. But it looks like underrun or a buffering issue or something to me.

Could this be a bug? Maybe the flow control? fsdev driver? Any gotchas or configurations I'm missing?

Any help is very welcome! Would of course be open to send you any more data or share a test repository if you like.

Thanks again for the response! Also, enjoy your vacation!

descriptors.txt

EDIT:

I just noticed that if I increase the buffer size to something much larger like:

#define CFG_TUD_AUDIO_FUNC_1_EP_IN_SW_BUF_SZ          256 * CFG_TUD_AUDIO_EP_SZ_IN

Then the audio stays perfectly fine for about 412ms (19,813 samples), then starts having problems. If I keep it small like 4 * CFG_TUD_AUDIO_EP_SZ_IN, the artifacts start immediately. It seems like the FIFO is overrunning somehow, and this buffer size directly controls how long it takes before the overrun occurs. Or maybe my ADC is actually running too slow somehow.

[HiFiPhile]

I think the greatest possibility is clock deviation, didn't notice you are using HSI clock.

A clock of at least 0.1% precision should be used, 1% difference is pretty high, even noticable as a tone change.

Taking full speed 48khz as example, in theory flow control can tolerate 2% deviation by sending 47/49 samples short/long packet. But in real Windows doesn't like device sending consecutive short/long packet so the regulation only happens each 10 packets, in result the maximum allowed deviation become 0.2%.

You can log the fifo level like uac2_speaker_fb example with tud_audio_get_ep_in_ff() and tu_fifo_count().

[martijnvdwoude]

You were absolutely right about the clock deviation!

I found the root cause: my STM32L432's HSI16 trim register was somehow set to 0 instead of the factory default of 16, causing approximately 3-5% frequency error. This was way beyond your 0.2% tolerance requirement.

Adding __HAL_RCC_HSI_CALIBRATIONVALUE_ADJUST(16); in my board initialization fixed 99% of the audio corruption and downpitching issues. There are still occasional minor glitches (once per minute or so), but the difference is night and day.

Your explanation about Windows not tolerating consecutive short/long packets and the 10-packet regulation window leading to the 0.2% maximum deviation was incredibly helpful for understanding why the flow control was dropping samples.

It confirms the need to redesign the next prototype with a proper HSE crystal oscillator, but this HSI16 trim fix proves the theory and makes it somewhat usable for now.

Thank you for pointing me in the right direction!

EDIT:
Filed an issue for this: #3209