[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:11:36 -0700

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

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.
Maybe I'm not understanding your suggestion though.


reply via email to

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