On Thursday, 2 July 2020 at 10:13:02 UTC, Dagmar wrote:
On Monday, 29 June 2020 at 21:29:31 UTC, Ali Çehreli wrote:
Then don't turn it off. :)
I understand there are programs where an undeterministic delay
in processing is unacceptable but those programs all run on
real-time operating systems anyway, right? ;)
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.
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.
This can be mechanically checked by the compiler with the @nogc
attribute.
The point is even in C++ you should never ever do malloc/free in
the audio thread, you might get away with it under low CPU load,
but if you're running at high load it can barf the audio. So GC
is just a variation on the same problem. Dont call malloc/free,
dont use GC in anyway.
You also have to make sure that the GC knows about your pointers,
so if you have a pointer to something, make sure it's reachable
from stuff the GC will scan. If it exists only on the stack in
the audio thread the GC could collect it as it wont know it is
still in use.
Also see this...
https://github.com/AuburnSounds/Dplug
