Audio 'on the stack' or 'on the heap' ?

[stef-ladefense]

hi schreibfaul1, the first thing I say is thank you, thank you for this library of rare quality.

I'm working on a complex project that uses your library to create a web radio station (as you might expect from the errors I'm reporting). I tested it by working on the heap instead of the stack, and I'm getting excellent stability.

1. Audio audio;
   The memory space required to store the audio object is directly reserved on the stack. If the Audio library is large, allocating the audio object on the stack can consume a significant portion of this limited space, risking a stack overflow if too many objects or functions are stacked.

2. Audio *audio = new Audio();
   The memory space for the Audio object is reserved on the heap. The audio variable itself is a pointer (a memory address) that is allocated on the stack, but the actual Audio object it refers to is located on the heap. This approach is advantageous for large objects, such as those from a voluminous library, because it does not impact the limited stack space, instead using the heap.

Both methods work. I get stack-based crashes when using a web frontend (using ESPAsyncWebServer), which disappear when using the heap.

The only problem is that m3u8 links don't work with the heap-based function. Their management is too recent to worry about, but you might get some insight on this.

I would like to have your opinion on this use, and if you have a little time to test, here is a piece of code where you will be able to switch from one to the other on a standard link and an m3u8 link.

// comment for standard use
//#define alternate

#ifdef alternate
Audio *audio = new Audio();
#else
Audio audio;
#endif

// callbacks
void my_audio_info(Audio::msg_t m) {
    Serial.printf("%s: %s\n", m.s, m.msg);
}

void setup() {
    Audio::audio_info_callback = my_audio_info;    // optional
    Serial.begin(115200);
    WiFi.begin(ssid.c_str(), password.c_str());
    while (WiFi.status() != WL_CONNECTED) delay(1500);

#ifdef alternate
    audio->setPinout(I2S_BCLK, I2S_LRC, I2S_DOUT);
    audio->setVolume(21);    // default 0...21
    audio->connecttohost("http://stream.antennethueringen.de/live/aac-64/stream.antennethueringen.de/");
    //audio.connecttohost("https://live.m6radio.quortex.io/webpHJPXnXrN7B6J7Q8mcqmxP/webradio/rtl/202/audio-64000/index.m3u8");
#else
    audio.setPinout(I2S_BCLK, I2S_LRC, I2S_DOUT);
    audio.setVolume(21);    // default 0...21
    audio.connecttohost("http://stream.antennethueringen.de/live/aac-64/stream.antennethueringen.de/");
    //audio.connecttohost("https://live.m6radio.quortex.io/webpHJPXnXrN7B6J7Q8mcqmxP/webradio/rtl/202/audio-64000/index.m3u8");
#endif
}

void loop() {

#ifdef alternate
    audio->loop();
#else
    audio.loop();
#endif

    vTaskDelay(1);
}

[schreibfaul1]

Hi @stef-ladefense,
For statically generated objects, the stack can simply be enlarged.
SET_LOOP_TASK_STACK_SIZE(12 * 1024);
You can use uint32_t HWM = audio.getHighWatermark(); to check how much space is left.

With dynamically generated objects, it will probably also be a memory problem, because it seems to work in principle.
https://github.com/schreibfaul1/ESP32_Arduino_ESPIDF/blob/master/src/main.cpp

[stef-ladefense]

I increased the stack to 16384, then to 24576, and it's still unstable.
The only thing that saves me is working on the heap.

I use
custom_sdkconfig =
CONFIG_ARDUINO_LOOP_STACK_SIZE=24576

My stack size is 23212 bytes
getHighWatermark: 956 bytes
whether on the stack or the heap

I used the syntax in your link above, no m3u8 playback.

I made a copy at https://github.com/stef-ladefense/ESP32-audioI2S-3.4.2a-testM3U8
see logCompile.txt

[schreibfaul1]

Small correction: audio.getHighWatermark is only the stack for the internal task.

    log_w("audiotask .. stackHighWaterMark: %lu bytes", (long unsigned)audio.getHighWatermark() * 4); // audio task
    log_w("looptask ... stackHighWaterMark: %lu bytes", (long unsigned)uxTaskGetStackHighWaterMark(NULL) * 4); // loop task

[stef-ladefense]

ok,
why *4 ?

[schreibfaul1]

These are DWORDs, i.e. 32-bit variables.

[stef-ladefense]

I'm an idiot, it's even written in the log.
ARDUINO_LOOP_STACK_SIZE 24576 words (32 bit)

[schreibfaul1]

Another idea: If space is really tight, you can put the stack of the internal task in the PSRAM.
This is hardly possible with the ESP32 (too slow),
sufficient with the ESP32S3
and ideal with the ESP32P4.

[stef-ladefense]

I don't really have a problem with running out of space.
There's a web frontend based on ESPAsyncWebServer that crashes or causes Audio to crash when retrieving the stream.
However, I no longer have any crashes using heap instead of stack, so I'll stick with this configuration.
The only thing I miss a little is not being able to use the m3u8 station, because playback doesn't start (however, in stack mode, it works...).

Here are the current values ​​in use:
[4285881][I][main.cpp:799] loop(): looptask ... stackHighWaterMark: 16064 bytes
[4300874][I][main.cpp:798] loop(): audiotask .. stackHighWaterMark: 3824 bytes

[stef-ladefense]

Hi, I've been tracking down the bug, and I no longer have stack overflows with ESPAsyncWebServer and JSON.
It works even now with a base stack of 8k words.
But I doubled it to 16k words because it was limited.
I tested with 3.4.2p, and it works.