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

[Elimar Green]

On Thu, Aug 5, 2010 at 10:44 PM, David Henningsson
<address@hidden> wrote:
> 2010-08-06 07:11, Elimar Green skrev:
>>
>> The idea behind having a fixed polyphony is to prevent CPU max out.
>> Ideally FluidSynth would be able to dynamically monitor CPU usage and
>> start killing voices once it reaches a set CPU percentage (default
>> would be close to 100% CPU).  Having FluidSynth automatically double
>> polyphony when it is reached, defeats the purpose it is intended for.
>
> ...because if the computer could handle it, it should have set the
> polyphony higher in the first place. I follow the reasoning, but...
>

True, which would require some pre-calculation of just how many voices
it can handle, which isn't all that straight forward.

>> Maybe I'm not understanding your suggestion though.
>
> There are still some "for (i=0; i < synth->polyphony; i++)" loops in
> there, although not as many as in 1.1.1. Which means that I higher
> polyphony setting takes a little more CPU and memory, even if they're
> not used.
>

Good point.

> Your idea of monitoring CPU usage might work in some cases, but not in
> others. One obvious case is fast-render, but there are less obvious
> cases such as running in real-time, but with more than one FS instance
> (which one of them should then start sacrificing voices?), or perhaps
> when running FS in combination with other synthesizers which has a
> similar function.
>


Yeah, my suggestion was more from a theoretical standpoint, rather
than thinking through the actual implementation.  While the max
polyphony policy that is currently implemented isn't necessarily
ideal, its simple and should work in most cases.  It seems like in the
non-realtime render to file case, you'd normally not want a maximum
voice overflow, except perhaps if you are trying to replicate
identically how it would sound if you were to play it back in
realtime.  I suppose some sort of cap on the number of voices should
occur in fast render mode though, to prevent excessive memory usage?
But I think voice overflow should be turned off in the fast render
case perhaps.

One thought concerning a dynamic voice overflow algorithm is to
utilize the cpu_load calculation.  At least in regards to timing the
synthesis loop and comparing it to realtime.  A running average could
be performed and if the value starts to approach realtime, then voices
should be killed.  I think that might work regardless of how many
instances of FluidSynth are running or what other applications are
using CPU, since its based on how much CPU is being given to
FluidSynth by the OS.


> // David
>

Elimar