On Wed, Aug 4, 2010 at 1:43 PM, David Henningsson <launchpad....@epost.diwic.se> wrote: > 2010-08-02 03:17, Elimar Green skrev: >> Cool. Seems like a user would at least know when a voice gets killed. >> A nice addition would be the various scores that the killed voice >> had, to know why it got killed and aid in adjusting the various >> overflow weights. > > Sure, feel free to commit a patch :-) >
Is that a threat? ;-) I just might do that. >> Yes, which I think is a settings parameter. So assigning the relevant >> settings value prior to instantiating the synth would set the system >> maximum. > > No, there was no setting for that, synth->nvoice was set to > synth->polyphony. > Yes there WAS a setting.. If you look in new_fluid_synth() (at least with 1.1.1) you'll notice: fluid_settings_getint(settings, "synth.polyphony", &synth->polyphony); Which assigns the initial settings value of synth.polyphony to synth->polyphony, which later gets assigned to synth->nvoice (max allowed voices per FluidSynth session). So whatever initial settings value would set the maximum allowed for a given FluidSynth instance, though you could dynamically set it to a smaller value. Kind of messy, so I like the idea of having it completely dynamic, so long as it is indeed thread safe. >>>> With this new change, does that mean that the memory allocation is >>>> always for 64k voices? That is probably a significant amount of >>>> memory if so (64k * sizeof (FluidVoice) at least). >>> >>> The array will be reallocated, and new voices created, when the >>> polyphony is updated. >> >> Great! This was avoided previously, since it couldn't be done in a >> thread safe manner. If you happened to resolve that, then cool! :) > > It is not hard real-time safe due to memory reallocation, but the > "synth" side is (optionally) protected by mutex and the "rvoice" side is > (optionally) handled by pushing through the queue. > So it sounds like it should work perfectly, right?! ;-) > // David > Elimar _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
