Talk by Herb Sutter: Bridge to NewThingia

[Guillaume Piolat]

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.