[Top][All Lists]

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

Re: [fluid-dev] More commits on the way to 1.1.1

From: josh
Subject: Re: [fluid-dev] More commits on the way to 1.1.1
Date: Tue, 17 Nov 2009 00:43:46 -0800
User-agent: Internet Messaging Program (IMP) H3 (4.1.6)

Just committed some more changes.

I think I resolved the return event queue issue. Its now just a fluid_thread_t which uses a condition to get signaled when events are available. fluid_synth_one_block() will signal the condition if there are any pending events in the return queue. It does this without holding the mutex. This means that there is the slight possibility that the return queue process could miss a signal, but it would just get signaled again in another call to fluid_synth_one_block().

Program change messages are queued in the return queue, if fluid_synth_program_change() is called in synthesis context. This means that program changes cause an event to be sent to the return queue thread, which locates a matching preset, then an event gets sent back to the synthesis thread activating the preset. Not exactly the most efficient, but I'm not sure how else to do it at the moment and program changes aren't really a common occurrence.

fluid_synth_cc() now always queues events for non-synthesis context (no more exceptions for certain events like bank selects).

fluid_synth_bank_select() and fluid_synth_sfont_select() also queue in non-synthesis context.

I made those additional changes to try and ensure that the queuing policy is identical across all events. I realized there was another rather embarrassing bug related to event re-ordering of program change and other messages like MIDI system reset. In the case of one MIDI file I tested, this resulted in all the presets getting reset after being assigned. Hopefully there are no more such issues.

One thing I don't like about the program change return queue queuing, is that this will also occur when doing render to disk. This could very well be an issue, since a significant amount of render time could pass before the return queue thread runs, which could lead to excessive stalls in processing program changes. I'm not sure how to resolve this at the moment. Perhaps we should review adding a runtime mechanism for turning off multi-threading, as we discussed previously.

The more I run into these types of issues, the more I'm beginning to agree, that this whole process of making FluidSynth more thread safe has been a bit rough. I'm not sure how I would have done it differently though. It seems like significant changes like these are bound to create some issues, especially since a lot of this last phase was getting used to the existing code base. I think doing RC releases is a must though and will hopefully get more testing done prior to official releases.

I'm confident I can whip this thing into shape though, its just a matter of identifying any additional problem areas. I think we are getting very close. Its been a rather humbling experience indeed.


reply via email to

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