Talk by Herb Sutter: Bridge to NewThingia

Guillaume Piolat at
Thu Jul 2 13:03:12 UTC 2020

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 

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 

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...

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.

More information about the Digitalmars-d-announce mailing list