[Top][All Lists]

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

Re: [fluid-dev] New voice overflow code committed

From: Elimar Green
Subject: Re: [fluid-dev] New voice overflow code committed
Date: Thu, 5 Aug 2010 22:16:16 -0700

On Wed, Aug 4, 2010 at 1:43 PM, David Henningsson
<address@hidden> 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


reply via email to

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