Allocation introduced in AudioFormatWriter


I’ve just updated the version of JUCE that we’re using and it has introduced some failing tests in our audio engine. This is because of the change of an array to a std::vector in AudioFormatWriter::writeFromFloatArrays in commit 31a7c62. The vector reserve will allocate.

While this function doesn’t promise to avoid allocation, it seems that it doesn’t necessarily need to. Would it be possible to change from a std::vector to a std::array as the data size is known in advance?

Thanks :smiley:!

Curious - in what way(s) are your tests failing wrt to this? It’s not like it’s the only the class/method/function that can allocate on a whim, so why and how was this singled out?

We have some tests that run our audio engine with allocation guards (overriding all the different flavours of new) to check that nothing allocates. This particular test is running in an ‘offline’ context, so the fact it allocates isn’t a big deal - we were clearly relying on the previous implementation.

This was changed in order to avoid some warnings under MSVC about excessive usage of stack memory. Switching back to a std::array would still use a lot of stack space. If the current implementation is causing problems for you we will try to find a better solution, but it sounds as though avoiding allocations is not critical to your use-case.

Alternatively, you could consider using AudioFormatWriter::ThreadedWriter, which is designed to be safe for use in realtime contexts.

No worries! I’ve removed the test that was clearly dependent on an implementation detail. Clearly it’s okay for the AudioFormatWriter to allocate as it also writes to disk!