On Friday, 21 January 2022 at 13:00:31 UTC, Guillaume Piolat wrote:
> On Friday, 21 January 2022 at 11:27:51 UTC, Ola Fosheim Grøstad wrote:
> Makes sense to me for that particular niche. Might also work for embedded with the caveat that you need extra memory.
While it must be interesting, another solution you have in D is to deregister audio threads so that a GC pause would let them run free. The audio threads rarely owns GC root anyway.
Yes, for a plugin that is reasonable. I think an audio-friendly garbage collector would be more for a language-like application like Max, or maybe even a complex sound editor.
But even if you do make your realtime tasks independent of the GC, it is still better to have a collector that is throttling the collection in the background so it doesn't wipe out the caches or saturate the data bus. Then you get more headroom for your realtime tasks (you get a more even load over time).
> Amortized malloc is surprisingly cheap, you can merge allocation buffers, and you would do it only once at initialization. A lot of the audio buffers are also scoped in nature, with a lifetime that is the one of the processing treatment. So you can also leverage specialized allocators to mass release those buffers rapidly.
Hm, how would you use amortized algorithms in a real time thread where you want even load on every callback? I guess you could use "coroutines" and spread the load over many "interrupts"/"callbacks".
One strategy for dynamic allocation is to have "chunks" for same sized allocations (avoiding fragmentation and merging), and then do a worst case estimate for how many allocations can happen in one realtime-callback. Then a non-realtime thread can make sure that there is enough free space in the chunks to support N callbacks.
Another strategy I have used that may be used if you do not write a plugin, but create your own host, is to pass in the buffers needed in the events you send to the realtime thread. Then have a mailbox for returning the buffers and let a non-realtime thread do the cleanup.
> In Dplug plugins we got a GC back :) by integrating Wren as UI scripting language. It is expected to cause very few problems, as it has a max-heap size and doesn't touch audio.
Is that a dedicated GC for wren or is it a generic GC?