Task Watchdog triggers from `usb_mic_task` in `usb_device_uac` even with minimal setup (AEGHB-1077)

[Ziamor]

Answers checklist.

• I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Summary:

When using the usb_device_uac component with a minimal configuration (dummy input/output), the system triggers a Task Watchdog timeout due to usb_mic_task hogging the CPU.

Environment:

• ESP-IDF v5.4.1
• ESP32-S3
• usb_device_uac via managed component
• Default USB Audio Class 2 config (microphone interface active)

---

Minimal Test Code:

#include <stdio.h>
#include <string.h>
#include "esp_log.h"
#include "esp_err.h"
#include "usb_device_uac.h"
#include <inttypes.h>

static const char *TAG = "usb_uac_test";

static esp_err_t uac_device_output_cb(uint8_t *buf, size_t len, void *arg)
{
    (void)buf;
    (void)len;
    (void)arg;
    return ESP_OK;
}

static esp_err_t uac_device_input_cb(uint8_t *buf, size_t len, size_t *bytes_read, void *arg)
{
    *bytes_read = len; // Return silence
    return ESP_OK;
}

static void uac_device_set_mute_cb(uint32_t mute, void *arg)
{
    ESP_LOGI(TAG, "Mute: %" PRIu32, mute);
}

static void uac_device_set_volume_cb(uint32_t volume, void *arg)
{
    ESP_LOGI(TAG, "Volume: %" PRIu32, volume);
}

void app_main(void)
{
    ESP_LOGI(TAG, "Starting minimal USB UAC test");

    uac_device_config_t config = {
        .output_cb = uac_device_output_cb,
        .input_cb = uac_device_input_cb,
        .set_mute_cb = uac_device_set_mute_cb,
        .set_volume_cb = uac_device_set_volume_cb,
        .cb_ctx = NULL,
    };

    ESP_ERROR_CHECK(uac_device_init(&config));
}

---

Observed Output:

E (6561) task_wdt: Task watchdog got triggered. The following tasks/users did not reset the watchdog in time:
E (6561) task_wdt:  - IDLE1 (CPU 1)
E (6561) task_wdt: Tasks currently running:
E (6561) task_wdt: CPU 0: IDLE0
E (6561) task_wdt: CPU 1: usb_mic_task
E (6561) task_wdt: Print CPU 1 backtrace

This happens repeatedly

---

Suspected Cause:

• usb_mic_task runs in a tight loop with no vTaskDelay() or esp_task_wdt_feed().
• This prevents the idle task from running → WDT thinks the system is hung.

---

Suggested Fix:

Inside usb_mic_task() in usb_device_uac.c, add:

static void usb_mic_task(void *pvParam)
{
    while (1) {
        ...
        vTaskDelay(1);  // 🔧 Prevent CPU starvation
    }
}

---

Impact:

• This issue occurs even without real audio I/O
• Breaks minimal working examples
• Prevents production use without manual patching

---

Request:

Please patch the default usb_mic_task implementation to avoid watchdog starvation

[Ziamor]

Update:
In addition to the task watchdog issue described above, I found that usb_mic_task also runs without regard to the configured MIC_INTERVAL_MS, causing it to pull microphone data far more frequently than expected. This breaks USB audio behavior, leading to distorted or "crunchy" audio output and incorrect timing.

A minimal delay like vTaskDelay(1) avoids the watchdog, but does not fix the core issue, it does not enforce correct USB audio pacing.

I've submitted a proper fix in PR #512 that uses vTaskDelayUntil() to throttle usb_mic_task according to the configured MIC_INTERVAL_MS. This:

• Prevents task watchdog timeouts ✅
• Aligns audio fetch rate with USB audio packet timing ✅
• Resolves audio distortion/glitches caused by data rate mismatch ✅

[lijunru-hub]

Thank you for your question.

Even when using virtual input/output, it's important to introduce a delay in the uac_input_cb_t function that aligns with the actual audio sampling rate, rather than returning the requested data immediately. Failing to do so will inevitably lead to incorrect system behavior.

[Ziamor]

PR #512 moves the delay into the driver itself, matching the mic_interval_ms used in the USB descriptors. That keeps packet timing consistent and removes the need for every app to add its own vTaskDelay(). Unless there’s a valid use-case where the descriptor interval and the callback pacing should differ, the PR fix seems cleaner and safer than forcing each user to handle the delay manually.

Thoughts?