On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
I'm working on virtual audio instruments and effect processors and they do their job in real-time. GC is luxury in this context. If I switched to D, I'd have to also switch from OOP to simple C-like structured programming and implement my own basic set of algorithms and data structures.
I work in audio effects, use no GC, and use OOP since TypeInfo is there.
You are right about basic set of algorithm and data structure.
If you're doing a plugin the host callback thread wont be known to the D runtime and so the GC wont pause it. So as long as you dont call anything that might trigger the GC while in the callback you wont get GC pauses affecting the audio rendering.
That was how we did it for a while, the speed hit was immeasurable.
Generally, if a callback thread can own GC things, it needs to be registered and deregistered at exit.
The problem with the D runtime can be (depends on when): - macOS compat in a shared lib - D host hosting D client can be tricky
The point is even in C++ you should never ever do malloc/free in the audio thread
Pet peeve, lot of practical audio applications do this (at startup) :)
You'll find mutexes in the audio thread in the most well known audio frameworks... all of them since spinlocks-style algorithms have worse worse-cases.
If the event is rare enough, it won't really matter and chasing it would be a lot of effort just to stay holier.
But it's a good talk topic so regularly people will berate other about how it's a bad thing.
Also see this... https://github.com/AuburnSounds/Dplug
Note that we disabled the runtime (and GC) for reasons I cannot entirely collected, we've tried to enable it back several times and it's hard.
D is very fitting for audio.
