WDT triggered after pause on AudioPlayer (ESP32, dual core, SD source)

[AlphaGaming7780]

Hey folks,
I'm running into a weird bug and could use a second pair of eyes.

I'm working on an ESP32 project where I’m using an AudioPlayer with an SD card as the audio source. The audio playback runs fine, and I’m running AudioPlayer.copy() in a task pinned to the other core (Core 0).

Everything works smoothly until I pause the playback. Then, exactly 2 seconds later, the Watchdog Timer (WDT) gets triggered and the ESP32 resets.

I want to keep the WDT active, so I’m not looking to disable it — I’d rather find out what's stalling during the pause.

Any idea what could be causing the task to stop feeding the watchdog after calling pause()?

Thanks in advance!

Note, here is my code in the task, if it can help.

void AudioPlayerLoopTask(void *parameter)
{

    bool *value = ((bool*)parameter);

    while (*value)
    {
        audioManager.audioPlayer.copy();
        esp_task_wdt_reset();
    }

    (*value) = true;

    while (true)
    {
        // Wait until this task get deleted by the main thread.
        esp_task_wdt_reset();
    }

}

[pschatzmann]

I think the easiest easyest implementation would be

void AudioPlayerLoopTask(void *parameter)
{
    while (true)
    {
        audioManager.audioPlayer.copy();
    }
}

This copies the data if it is active or just calls some small delay() if there is nothing to copy, to prevent exactly this issue!

[AlphaGaming7780]

Sorry for the delayed response.
First of all, thank you for getting back to me. I didn’t reply sooner because I’m currently unable to use the SD source anymore. An error that used to appear occasionally is now showing up consistently.

Every time I try to start the SD source, I get the following error and the ESP32 crashes:
assert failed: T& audio_tools::Vector<T>::operator[](int) [with T = float] Vector.h:257 (index < len)

[AlphaGaming7780]

Update: I fixed the bug.
Turns out, adding a delay actually solved the issue — which is pretty weird.
What’s strange is that calling the method that's supposed to reset the WDT doesn’t seem to actually reset it.