# Allocation introduced in AudioFormatWriter

**URL:** <https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242>\
**Category:** General JUCE discussion\
**Created:** [May 28, 2021, 2:01pm UTC](https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242 "2021-05-28T14:01:25Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![joenoel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/joenoel/32/893_2.png) [@joenoel](https://forum.juce.com/u/joenoel)\
**Post date:** [May 28, 2021, 2:01pm UTC](https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242/1 "2021-05-28T14:01:25Z")

</div>

Hello!

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 😃!

---

<div class="post-metadata">

**Author:** ![jrlanglois](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/jrlanglois/32/21372_2.png) [@jrlanglois](https://forum.juce.com/u/jrlanglois)\
**Post date:** [May 28, 2021, 2:30pm UTC](https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242/2 "2021-05-28T14:30:42Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![joenoel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/joenoel/32/893_2.png) [@joenoel](https://forum.juce.com/u/joenoel)\
**Post date:** [May 28, 2021, 2:46pm UTC](https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242/3 "2021-05-28T14:46:18Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![reuk](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/reuk/32/21494_2.png) [@reuk](https://forum.juce.com/u/reuk)\
**Post date:** [June 2, 2021, 9:40am UTC](https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242/4 "2021-06-02T09:40:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![joenoel](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/joenoel/32/893_2.png) [@joenoel](https://forum.juce.com/u/joenoel)\
**Post date:** [June 2, 2021, 10:03am UTC](https://forum.juce.com/t/allocation-introduced-in-audioformatwriter/46242/5 "2021-06-02T10:03:35Z")

</div>

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!