Just two more remarks.
1. Note that I think there is a wrong understanding what happens in the way you
describe the bug:
> E.g. for a polyphonic track, thread 1 might be processing a fluid voice,
> while threads 2,3,4 try to process polyphonic voices of the same track which
> leads to blocking on the mutex held by thread 1 instead of picking up other
> modules that need processing.
For a polyphonic track there will only be *one* single sound font osc
instantiated. This one sound font osc handles all voices for this track, no
matter how many voices are active. So to stall the engine in the way you
describe, you need many tracks with sound font oscs (which is however a valid
use case, I won't deny this).
2. "full multi-threaded processing of the sound engine" may not actually be
faster than single threaded processing.
I've tried to measure how much faster party monster renders when given multiple
cpus here:
https://mail.gnome.org/archives/beast/2018-July/msg00009.html
The result: not at all, the engine is slower if more cpus are used. But this
again may not always be the case (if something else than party monster were
used to measure performance), and even if it were, I'd agree that we're looking
at two issues here, one in the soundfont code and one in the engine, and the
engine inefficiency should be fixed in the engine.
--
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/issues/84#issuecomment-430750475
_______________________________________________
beast mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/beast
