On Thu, Aug 5, 2010 at 10:44 PM, David Henningsson <launchpad....@epost.diwic.se> 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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org http://lists.nongnu.org/mailman/listinfo/fluid-dev
