Talk by Herb Sutter: Bridge to NewThingia
first.name at gmail.com
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
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