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

[David Henningsson]

2010-08-02 03:17, Elimar Green skrev:
>>> Is there any way, besides listening to the results, to indicate when a
>>> voice overflow occurs and what was replaced?  It seems like that would
>>> be really useful in tuning those parameters.  This is why I thought
>>> having a voice overflow log would be nice, though more work of course
>>> ;)  I suppose a semi quick and dirty method would be to printf
>>> debugging statements when enabled or something.
>>
>> Actually, there is one already, when compiled with enable-debug:
>>
>>  FLUID_LOG(FLUID_DBG, "Killing voice %d, index %d, chan %d, key %d ",
>>            voice->id, best_voice_index, voice->chan, voice->key);
>>
>> I added it for my own debugging (hmm, perhaps "index" is not anything a
>> casual user would have use for...).
> 
> 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 :-)

>>> I think the way it worked before (or at least should have worked) is
>>> that the initial value for the polyphony set the maximum allowed value
>>> (and the memory requirements), you could then adjust it to be less
>>> than the system maximum.
>>
>> Actually synth->nvoices was set to synth->polyphony and not 4095 (the
>> previous maximum).
>>
> 
> 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.

>>> 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.

// David