On Thursday, 2 July 2020 at 11:13:41 UTC, claptrap wrote:
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
I think you can make a callback thread to D work if you have a
trampoline function and then call
thread_attachThis
rt_moduleTlsCtor
before calling the actual callback. Then the thread will be known
to D runtime.
