AudioMemory() - what parameter should I pass?

Status
Not open for further replies.

pjrcbear

Well-known member
Is there a doc that I missed that specified this?

I gathered from the forums and from the code that you need buffers for the data going into the pipeline, and so if you're using delays you need more buffers, but I'm not sure what value to use for my own pipeline. I've got quite a few elements in it (mixers, biquads, etc), and not using any delays.
I've seen a few magic numbers in examples, but I have no clue what I should pick for my project, or whether there's a way to know that I'm running too short.

Any help is appreciated!

TIA!
 
I found best results using 2x The audio memory usage.
So if memory usage is 3, I use 6.

There is no justification for such rule. The use of audio memory is deterministic and can easily be calculated. Of course, you need to look into the audio library and do the maths. The rule FrankB gave, is reasonable, even if empirical and may require multiple trials, i.e. increasing memory usage until AudioMemoryUsageMax() is not reached or stays 2 or 3 units below the requested audio memory.

If one uses Queues (record/playback) then the you must consider the max queue size.

If you do not want to calculate and have plenty of spare memory, you can easily take a huge number (say 10000, or 1.28 MB), the system will limit audio memory to predefined max value.
 
There is zero benefit from unused audio memory allocation. If you are certain your design uses at most 3 audio blocks, you might as well allocate exactly 3.

But allocating more doesn't cause any harm either, unless you need that memory for non-audio stuff. If having extra makes you feel safer, and my word as the creator of this software doesn't give you enough comfort, then go ahead and allocate as much extra as you like. It does no good (unused memory does *not* help the audio library run any better or faster), but it doesn't slow things either or do any other harm, so waste as much memory as you like to sleep well at night. ;)

I put those maximum ever used (since the last explicit reset of the maximum) functions into the library so you could discover exactly how much your design has ever used, even if it allocated and released a block within an interrupt function, that can't be seen by rapidly reading the current value from non-interrupt context. If you're absolutely sure you've fully exercised your audio system and captured the true maximum, there is no technical reason to allocate any extra memory beyond that maximum.

But if you aren't 100% sure of the true maximum, allocate extra so you'll have enough to cover all cases. Especially for polyphonic synthesis with configurable effects, testing all possible uses to get the true maximum usage can be challenging. Many parts of the library avoid using memory when they're not creating or processing audio, and effects like delay and queues can use a variable amount depending on settings. So even with those maximum usage functions, you still need to find a way to cause your design to reach its true maximum case.
 
Last edited:
What happened was I was chasing a pop and click artifact in the recordings and tried everything. AudioMemory was at 12. It went away immediately when I used 6. Out of curiosity I googled and found a way to test how much audio memory I should allocate - Found the AudioMemoryUsageMax() and serial out to print the number I should use (3).

I decreased the to 3 and recorded and it sounded like a radio not stationed properly barely hearing the audio through it. Put 4 a was little better but 6 gave the cleanest recording.

Math is fine, but as with development you won't know until you actually test it. I can upload recordings if anyone is interested. This was not a simple ABA test. More like ABABABCADAA lol. I'm convinced the proper allocation fixed the pops and clicks, which in PC world sounded similar to buffer underrun in a DAW.

So maybe using twice is not a good rule, a bette rule would be to test and see what your system needs.
 
Last edited:
Status
Not open for further replies.
Back
Top