Re: [fluid-dev] Changes on CVS, needles and threads

[Josh Green]

On Fri, 2003-05-30 at 01:39, M. Nentwig wrote:
> Hello,
> 
> committed yesterday, please test and comment.

I'll check it out.

> I hope this doesn't interfere with the ongoing macOS work...

It shouldn't, since most of what I was suggesting were just mindless
hacks to get things working :) I'll put together a list of what kind of
things had to be changed so that the source can be properly corrected.
Still don't have it running yet for Joe :(  I think we are close though.

> Josh, the 3rd "*" could be done in Swami as well (but doesn't have to):
> 

Perhaps I'll implement that later. When would I call
fluid_voice_optimize_sample? At preset selection time or?


> 
>  The mutex thing is a design issue that should be thought through. If
> it's bad, let's take it out again.
> 
> Here's my view, correct me if I'm wrong (admittedly not exactly a thread
> expert speaking here)
> When the MIDI or shell or cmd thread modifies voices in the synth, there
> is a chance that the audio thread is just running. For example, a voice
> could be killed and reallocated just while it's being played.
> So far there hasn't been any evidence, probably the code is robust
> enough to cope with that. Anyway, more and more threads are being added
> (take LADCCA and shell), maybe this could be cleaned out.
> Anyway, my solution will wait with a noteon, noteoff, cc etc until the
> audio thread is through. There is no guarantee that the audio thread
> doesn't start in the middle of a noteon 'event', though.
> 
> Now the 'jack' documentation says that pthread_lock_mutex is not allowed
> in the process thread because it can delay for an indefinite time.
> Any good ideas how to do this right?
> 
> Cheers
> 
> Markus
> 

I've noticed a few occasional crashes at noteon time while tweaking
effects, etc. Of course not having a backtrace doesn't help, but I
wouldn't be surprised if there are occasional thread interactions of the
bad kind. I think thats the worst part about threaded programming, is
that if there is a problem, it may only bite once in a blue moon. And
then when it does, its a pain to figure out what went wrong.

I guess I don't really have a good enough picture of the operations of
FluidSynth to have any informed ideas on how to solve this issue.
Probably need to analyze what values and structures can get modified by
the non-audio threads, and then determine which ones are critical (as in
could cause a crash), semi critical (perhaps a synthesis glitch), and
not a problem. Queueing up critical changes and having the audio thread
perform them might be the answer, like someone else mentioned. Cheers.
        Josh Green