Consider using static buffers?

[stevstrong]

In my applications I always prefer to use static buffers instead of dynamically allocate them.
This has the advantage of having a clear memory map from the beginning, and avoid possible crashes during runtime due to fragmented heap.

In particular, it wold be possible to declare the buffers statically in the header files.

In a similar way, the buffers in libelix-mp3/buffers.c could be also statically declared, so no need to call malloc when allocateBuffers() is called.

Furthermore, one could also simplify the functions maxFrameSize() and maxPCMSize(), because the max_frame_size and max_pcm_size could be initialized at the time the MP3 instance is created, so the check if they are 0 could be avoided.

[pschatzmann]

I opened the discussion folder since you are posting questions which are not really bugs.

Static buffers have their merits, if you have an application that is supposed to to this one thing.
However I prefer to have the flexibility to play and support multiple audio files from different decoders and then it is more important to be able to release the memory again.

It is also a question of what processors you are working with. Todays ESP32 and RP2040 have enough RAM that we can afford not to bother too much about this

[stevstrong]

I can follow you, using different decoders at different times would eventually benefit from dynamic allocation.

The question is how often you create an object and then destroy it. If yo do it often, well, then the heap can become de-fragmented quickly.

Supposing you have a music player which has to support several audio types. Then you select one file and play it. You will then create a different instance each time you play a file, and then destroy that instance after playback has finished. And maybe other instances from other libs have been also created meanwhile. Playback 20 files and your heap can already suffer...

On the other hand there are not so many different common audio file types supported. Maybe 4 (MP3, AAC, WAV, OGG)? Then in worst case you have statically allocated buffers for all 4 formats. No problem, also because, as you pointed out, modern MCUs have enough RAM.
Nevertheless, most people want to playback only MP3 (because of their reduced size on portable mediums), and/or eventually AAC.

The largest buffers are anyway those involved to stream out the PCM data to I2S or over SPI (preferably via DMA).

I ran several times into memory issues dues to "new" usage. Most INO examples of Arduino libraries will work, you run that simple example and think everything is fine. Then you build an application around it, create several times an instance in the background, destroy it in the background (and you don't know about it), and after a time (minutes, hours) your app will crash, and wonder why...

And I didn't even mention yet RTOSes.

[pschatzmann]

As you can see my list of supported encoders and decoders and is quite big.

But feel free to provide a pull request with some additional compile options.