Re: [fluid-dev] Thread safety

[David Henningsson]

address@hidden skrev:
> Quoting David Henningsson <address@hidden>:
>>
> Looking at how things are coded in FluidSynth, I'm amazed there aren't
> more issues, in real world use.  I suspect there are lots of issues
> lurking, those one in a million synthesis glitches or worst case, crashes.

Then you and I have come to the same conclusion.

> 
> 
>>>
>>> I wonder what the effect would be of using mutexes.  In real life, how
>>> bad would the lock contention be and would it lead to audio underruns?
>>>  Identifying the areas where mutexes are needed would help with this.
>>
>> Perhaps we could have "big" mutexes (i e one for everything), but on the
>> voice level instead of the synth level. And on the synth level we try to
>> use the atomic functions, I assume that's doable.
>>
>> The downside is more mutexes (one per playing voice), but on the other
>> hand they should be finished more quickly. So we win in the worst case
>> but lose in the average case.
>>
>> Another wild idea would be to preprocess the voices so we're always a
>> few buffers ahead for every voice. A lower priority thread (or several,
>> for multicore CPUs) could handle this. The audio thread would then just
>> mix the voices together. Care has to be taken that MIDI events will
>> throw already created buffers away.
>>
> 
> I think ideas like these are good.  Having each voice be processed and
> then mixed, would only require one buffer (64 bytes) per voice and
> would not require much extra CPU.  This could also facilitate moving
> to the multi-thread voice processing model.

I guess you would need at least an audio-buffer-size of samples to make
any difference in practice though. While this would add stability, it
will also add some CPU consumption and increase memory usage (and
bandwidth). So perhaps this would be something that should be enabled or
disabled.

> I've been thinking about what the ideal FluidSynth thread model would
> be for lock-free (or as close to lock free as possible) and of course
> crash free ;)
> 
> Here are some initial thoughts, though perhaps faulty by design and
> lacking completeness.

Right, and we should not forget about the embedded / rendering case,
which probably still would benefit from being single-threaded. (And
also, they must be predictable.)

> * Make active voices and voice pool private to the synthesis thread.
> 
> * Parameter updates (MIDI events, etc) go through a lock free FIFO queue.
> 
> * Voices are allocated outside of the synthesis process, initialized and
> added to the FIFO queue for processing.
> 
> * Note-off events are also appended to the event queue.

Do I understand you correctly, that you want to treat note-on events
differently from the rest of the events, based on the assumption that
these events are the only that will take a large amount of time?

> This would leave the main synthesis thread (and future helper threads)
> to do the dirty work, without pesky meddling from other threads.
> 
> The issue that I have run into, is that I haven't been able to find a
> FIFO queue algorithm which allows multiple producers.  

I think that can be solved with one FIFO for every producer thread. That
leaves us however with another problem of how to add and remove FIFO
queues dynamically in a thread-safe way...

> A lock free FIFO
> with single producer and consumer is pretty trivial, 

Will these support resizing if the FIFO gets full? And if they don't, is
that feature important?

>> My idea was that if I commit my patch in its current state, at least we
>> will have something more stable (fix for ticket #43). And I think the
>> possibility to route midi events through the sequencer makes a valuable
>> addition to the sequencer. And when we have improved the synth thread
>> safety, we will simply revert the three lines in fluidsynth.c that
>> inserts the sequencer in the chain. What do you think?
> Sure, if it improves things in the short term, go ahead add it.  Fixing
> FluidSynth's threading issues, and doing it right, is likely going to be
> a bit of a larger task than doing simple fixes.  So it might be good to
> try and address the more severe issues, while coming up with a long term
> solution.

In an open-source project where people can suddenly disappear without
notice, my assumption is that taking a lot of small steps (while keeping
it stable) is often better than taking one big step, even if those small
steps sometimes means additional work.

// David