Re: [fluid-dev] Thread safety

[David Henningsson]

Dave Serls skrev:
> On Sun, 17 May 2009 10:20:18 +0200
> David Henningsson <address@hidden> wrote:
>> Given that priority list, we should make the fluid_synth_t class
>> single-threaded and avoid mutexes altogether. One reason for this is
>> that one of Fluidsynth's most important usages are as a virtual
>> instrument in MusE/Rosegarden/etc, and there I assume it is used
>> single-threaded anyway. And given the current behavior (some amount of
>> synchronization but not fully functional), I think we could say that
>> getting rid of the synchronization would be backwards compatible.
>    Just a dumb abuser here.
>    I just want to make sure that this serialization does not effect the
>    performance and responsiveness of libfuidsynth clients like qsynth.
>    It's multi-engine capability for simultaneous rendering of soundfonts is so
>    wonderfully useful.
> 

Here's an answer for you, jimmy, and anyone else whose questions can be
shortened to "you won't break anything, will you?" :-)

First, to me it seems like the current synchronization handling is very
broken, and I see ticket #43 as evidence of this. So something really
needs to be done.

As for the latency/performance issues, I haven't noticed any difference
in responsiveness when I've tried it here. There is a theoretical
possibility though, that

1) midi events in some cases will be delayed up to 64 samples, i e 1.5
ms with the normal sample rate, but on the other hand, in some other
cases the current handling will delay the midi events instead.

2) since the audio thread has to do more work, this might increase the
possibility for an underrun. That would be if you trigger very many midi
events at the same time. (Note: If you use MIDI physically, i e the
5-wire DIN connection, this won't be an issue. That protocol is so slow
that it can only insert approximately one midi event per millisecond
anyway.)

Last, I will test my patch here before I commit it. But I won't test all
platforms and applications, so I count on you to do that when my patch
has reached the repository. If it turns out that it breaks
responsiveness or anything else, we can either improve the patch, or in
worst case, throw it away.

// David