Re: [tim-janik/beast] Eliminate global Soundfont Mutex (#84)

[Stefan Westerfeld <notifications github com>]

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, view it on GitHub, or mute the thread.