[Top][All Lists]

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

[fluid-dev] Re: Revert program change return event stuff

From: josh
Subject: [fluid-dev] Re: Revert program change return event stuff
Date: Thu, 26 Nov 2009 12:37:42 -0800
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Quoting David Henningsson <address@hidden>:

address@hidden wrote:
I think I will just revert the changes in regards to processing program change events in the helper thread. The problems with program changes occurring in the synth thread (possible mutex contention and memory allocation) seem less of an issue in comparison and will only happen in the case of MIDI events being generated in the synthesis thread.



I did start thinking along the lines of making the program change lock/malloc free. Unfortunately the allocation of presets is left up to the SoundFont loader. But the internal SoundFont loaders could be modified to assign each preset a pre-allocated fluid_preset_t structure, so that it does not need to be allocated or freed during program change. In fact these structures could probably be shared for an entire SoundFont. This means that the get_preset method would be marked as a real-time sensitive method. Existing programs that use the SoundFont loader would likely need to update this method, to remain real-time safe.

I haven't looked much into that piece of code, but if it is doable, it
sounds like a good idea for the next version of FluidSynth.

You mean 1.1.1? ;)

Any ideas how to have a lock free method of accessing the SoundFont list, when searching for a preset?

Reallocations of the list array is not a problem now that we have a max
of 2048 soundfonts, we could just allocate a static list of 2048
fluid_sfont_info_t records (and perhaps an atomic max-variable for
optimization). Before searching a record we increase its refcount
(which will have to be atomic), and decrease it when we're finished.

True, or perhaps better would be a static array of fluid_sfont_t pointers. Could do atomic compare and exchange operations on them or other such tricks, with an atomic integer count.

A secondary shadow SoundFont list owned by the synth thread, which is synchronized via the queue, might work. Seems slightly messy though and I know how much you hate those shadow variables ;)

I had a second look at those shadow variables and decided not to
dislike them. ;-) I don't see them as shadow variables though, for me
they are the primary variables of the state machine, and the voice
renderer keeps a copy of them for its own purposes.

Your description is definitely more appropriate, but I couldn't think of another word to use other than shadow at the time. Glad you don't dislike them anymore!

Maybe its not worth trying to fix now.

Well, I'm sure you know my standpoint on *that* one... ;-)

Yes yes indeed. Will release 1.1.1 real soon now :) I'll just revert the program change stuff and we'll just have to live with some small holes in our real-time safety, but then only in certain cases. Big deal.

// David


reply via email to

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