Can I call AudioMemory() more than once?

G

Greg-R

Member
I am working on the T41 radio project which uses the Teensy 4.1.
What I want to do is conserve memory, but I have a function called only occasionally which uses a lot of audio memory.
So I want to temporarily increase the number of audio blocks, perform some work, and then go back to normal operion with a reduced number of blocks.
Is it possible to call the AudioMemory() function more than once with predictable results? Will it properly free and allocate increased
or decreased number of audio blocks? Or is it restricted to one-time use in the setup() function?

Thank you,
Greg
 
No, it won’t free blocks. In fact it’ll waste all but the last-created set. If you look at the contents of AudioStream.h you’ll see it’s not a function but a macro which defines a static set of audio blocks and then initialises them.

Assuming the function is yours, you could presumably flip it from inactive to active, and malloc() its working memory at start and free() it when done. Just keep an eye out for heap fragmentation…
 
Yeah, I discovered it's a macro from calling AudioMemory() from within other functions. The heap gets eaten up without even calling those functions!
 
Maybe I have to create a class which inherits from AudioStream? Then make a new method to free "num" blocks?
There are protected methods which do this, but for only a single block. Since "initialize_memory()" is used by the AudioMemory macro,
maybe all I have to do is create a "free_memory()" method. The code implies a pool is being used, so maybe it is already resistant to fragmentation?
 
Yes, the audio blocks exist permanently (static…), and are allocated on demand by the various audio objects which inherit from AudioStream. They typically only stay allocated for one or two update() cycles, and are released back to the pool for re-use. Nothing enforces this, so incorrect code can exhaust the pool and audio stops working.

Some objects, like AudioEffectDelayExternal or the arbitrary wave option for AudioSynthWaveform, rely on memory other than the block pool. It seems like your application would best suit that sort of approach.
 
Greg-R said:
So I want to temporarily increase the number of audio blocks, perform some work, and then go back to normal operion with a reduced number of blocks.
Click to expand...

Because this goes against the design of the audio library in some pretty fundamental ways, you'll (probably) have a very difficult time trying to make it work. Before I mention any details, I want to be clear about my overall message: this isn't how the audio library works.

One big problem you'll face is how to know when all the extra memory is actually free. Audio objects and even the connections between them are allowed to keep memory allocated. Most which do this only hold them for 1 more update, but that's not required. Effects like delay can hold memory for quite a long time.

If you try adding code to prioritize allocation of certain blocks over others, and handle releasing blocks differently depending on their type, you'll alter another subtle design aspect of the audio library, its deterministic timing. Perhaps this isn't as critical now that we're running on 600 MHz Cortex-M7 rather than Cortex-M4 at 48 to 96 MHz in the early days of Teensy 3.x. But you should at least be aware of the intended design. The idea is allocating and releasing memory is designed to always require a fixed amount of work. When the audio library is performing certain amounts of processing, the CPU time required stays fixed because all the library's infrastructure is designed for deterministic timing.
 
I think I may have an exception, because the particular code which is temporarily using more blocks uses only input and output queues.
All of the signal processing is done in the sketch.
I am going back and see if I can throttle down the maximum blocks used with methods like setMaxBuffers() method of the play queues.
 
You must log in or register to reply here.
Back
Top