Re: [fluid-dev] Thread safety

[jimmy]

> Date: Tue, 19 May 2009 07:28:07 +0200
> From: David Henningsson <address@hidden>

> 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

David,

One quick way you can test the realtime responsiveness is to play some notes 
with vkeybd while having kmid (or other apps) playing a midi sequence.  
Clicking on a piano key in vkeybd (or press a valid key on the PC keyboard 
while vkeybd has proper keyboard focus) should render the sound almost 
instantly.  If there is perceivable delay before a sound is heard then the 
latency may be a problem for live playing.

You can try with the current behavior and the new code to have an idea.

I suggest that, because I don't normally build FS from source that often.

I think I understand some of the problem with FS is because the way it set and 
get nested structure variables directly without checking for null (which could 
be (un)set by any thread).

IMHO, the real way to fix that is to change the codes to use getter/setter 
functions and check for nulls there.  But such changes will be a major code 
overhaul (everywhere in FS) and may potentially affect some api's too.  Of 
course, that will slow down FS somewhat, too.

Jimmy