Recently, we discussed this merge request, and you (Tim) said you do not want 
to merge code that locks a mutex during audio processing due to **priority 
inversion**.

So, what does the lock protect here? There is one global fluid_synth instance 
that is used by both, the soundfont repo and the soundfont osc code. There is 
also a bunch of data shared between the soundfont osc modules that is protected 
by the lock. Locks are acquired

 * by the soundfont repo when loading/unloading soundfonts
 * by the soundfont osc modules when rendering audio

Like the wave repo code, we never load/unload soundfonts if the repo is 
prepared, so effectively the soundfont repo will not lock the global mutex 
while the project is playing.

The soundfont osc modules are
 * one common module that does the actual rendering (1)
 * per osc modules that just copy the data out, and maybe change the preset of 
the current voice (2)

But these modules are all executed within the engine process() callback so they 
effectively run with the highest priority we have. So **there is no priority 
inversion possible here**. Also note that while (1) takes a while because it 
renders the data, (2) is really cheap, because the audio data is already 
available.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/tim-janik/beast/pull/85#issuecomment-484055853
_______________________________________________
beast mailing list
beast@gnome.org
https://mail.gnome.org/mailman/listinfo/beast

Reply via email to