[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [fluid-dev] Time to release?

From: josh
Subject: Re: [fluid-dev] Time to release?
Date: Sat, 14 Nov 2009 20:47:20 -0800
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting David Henningsson <address@hidden>:
I've just committed a small patch which updates the synthesis thread
variable at every call to fluid_synth_one_block, which should fix
Ebrahim's thread-jumping problem. Assuming Ebrahim confirms that it is
fixed, perhaps it is time to release a bugfixed version? Josh, do you

I think I may have beat you too it! I also committed this same patch and didn't see any other changes at the time I committed it. I hope the call to get the thread ID isn't much overhead. The reason I only checked it once before, was for that reason.

Its not ready yet.  I've still got 3 items to resolve:

1. Querying a preset or its info, should provide the most recently assigned preset. Queuing breaks this currently.

2. Allocating a preset (fluid_synth_get_preset, fluid_synth_get_preset_by_sfont_name and fluid_synth_find_preset) require mutex locks. This means they should not be called from synthesis context, but currently are!

3. Provide API to get information about a preset on a given channel, as discussed with Rui.

#3 should be fairly trivial, once #1 is solved. If you have any ideas for #1 and #2, that would probably be helpful.

Ideas for #1 and #3, allocating and freeing a preset is done under mutex lock (well freeing currently isn't, but it could be made to be so). Each channel could then have a shadow_preset field, which gets assigned the most recent preset also under mutex lock. Preset assignments are still queued to the synthesis thread and return queued for freeing. Getting info on a channel preset could then just hold the mutex also, while copying the info. The fluid_synth_get_channel_preset() would then just be for within synthesis context and/or deprecated.

I'm not yet sure how to solve #2. If a bank/program change occurs in a high priority MIDI thread (which could be even the audio thread in the case of Jack), holding a mutex to find a preset is a bad idea. I'm also not sure how to signal a lower priority worker thread, without a mutex. Any ideas? If the return queue could be signaled and woken up, without a mutex, that would probably be the right way to handle it. g_cond is supposed to use g_mutexes though, to protect the condition (event count for example).

Many of the recent changes I made, have to do with making synth query functions return the most recent value, regardless if it has actually been assigned in the synthesis thread or not. I did my best to think through any sort of out of order processing that could occur in regards to queuing and non-queuing and didn't see any obvious issues. But I'm not completely confident on this.

Or are there any volonteers planning to test the new FluidSynth version
before we release it? In Ubuntu, there is at least fluidsynth-dssi and
tuxguitar, which would be nice if someone volonteered to test.

// David

Do you want to do an RC release this time? 1.1.1-RC1? It would be good to get something out soon, before people start using the semi-busted 1.1.0, at least in regards to QSynth compatibility.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]