Dave Serls skrev: > On Sun, 17 May 2009 10:20:18 +0200 > David Henningsson <launchpad....@epost.diwic.se> wrote: >> Given that priority list, we should make the fluid_synth_t class >> single-threaded and avoid mutexes altogether. One reason for this is >> that one of Fluidsynth's most important usages are as a virtual >> instrument in MusE/Rosegarden/etc, and there I assume it is used >> single-threaded anyway. And given the current behavior (some amount of >> synchronization but not fully functional), I think we could say that >> getting rid of the synchronization would be backwards compatible. > Just a dumb abuser here. > I just want to make sure that this serialization does not effect the > performance and responsiveness of libfuidsynth clients like qsynth. > It's multi-engine capability for simultaneous rendering of soundfonts is so > wonderfully useful. >
Here's an answer for you, jimmy, and anyone else whose questions can be shortened to "you won't break anything, will you?" :-) First, to me it seems like the current synchronization handling is very broken, and I see ticket #43 as evidence of this. So something really needs to be done. As for the latency/performance issues, I haven't noticed any difference in responsiveness when I've tried it here. There is a theoretical possibility though, that 1) midi events in some cases will be delayed up to 64 samples, i e 1.5 ms with the normal sample rate, but on the other hand, in some other cases the current handling will delay the midi events instead. 2) since the audio thread has to do more work, this might increase the possibility for an underrun. That would be if you trigger very many midi events at the same time. (Note: If you use MIDI physically, i e the 5-wire DIN connection, this won't be an issue. That protocol is so slow that it can only insert approximately one midi event per millisecond anyway.) Last, I will test my patch here before I commit it. But I won't test all platforms and applications, so I count on you to do that when my patch has reached the repository. If it turns out that it breaks responsiveness or anything else, we can either improve the patch, or in worst case, throw it away. // David _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
