[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.
Elimar
Message not available
- Re: [fluid-dev] New voice overflow code committed, David Henningsson, 2010/08/04
- Re: Re: [fluid-dev] New voice overflow code committed, Bernd Casper, 2010/08/05
- Re: [fluid-dev] New voice overflow code committed,
Elimar Green <=
- Re: [fluid-dev] New voice overflow code committed, David Henningsson, 2010/08/06
- Re: [fluid-dev] New voice overflow code committed, Elimar Green, 2010/08/06
- Re: Re: [fluid-dev] New voice overflow code committed, Bernd Casper, 2010/08/08