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

[Elimar Green]

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
>

Elimar