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

[David Henningsson]

2010-08-06 07:11, Elimar Green skrev:
> On Wed, Aug 4, 2010 at 1:21 PM, David Henningsson
> <address@hidden> wrote:
>> 2010-08-04 11:59, Bernd Casper skrev:
>>> Hi David,
>>> thinking about this polyphony stuff, I wonder if FS could provide the 
>>> following addition to the current polyphony solution.
>>> In the past two years I worked with FS, I always did run more than one 
>>> instance of FS to ensure low latency and avoid polyphony cutouts. In my 
>>> experience, the systems run a soundfonts divided into two to four (with 2-4 
>>> FS instances) parts much better than only one big soundfonts in one 
>>> instance of FS. Synchronization already is nearly perfect, so far. Right 
>>> now I've an organ here running 20 instances of FS at the same time, without 
>>> problems, on an AMD DualCore system.
>>> In olden days, there were polyphony solutions which could raise the 
>>> polyphony that way, that the overflow messages were led to the hardware 
>>> MIDI-out, and a second hardware synth could be fed and run with the 
>>> overflow messages.
>>> Would it be senseful and possible, to adapt this idea on software level, as 
>>> kinda "multi-instance usage"? In case FS recognizes overflow, automatically 
>>> and dynamically to start a new instance and to re-route the overflow 
>>> messages to that new instance, instead of cutting them out? The user would 
>>> need a switch, to decide how many FS instances he would allow. A default of 
>>> 4 would be great.
>>> Regards
>>> Bernd.
>>
>> Hi Bernd,
>>
>> Copied in the list on your post, hope you don't mind.
>>
>> The idea is interesting but I think it would be better to, before every
>> note-on, to check if there are enough voices available, and if not, to
>> dynamically increase (e g double) the polyphony.
>>
>> I'm also wondering if you have tried the latest changes with -o
>> synth.cpu-cores=2 (or more) and seen if that gives better performance
>> for you? It should.
> 
> 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...

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

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.

// David