Louis: Thanks for the idea. I will check it out. That may well be a viable solution.
I did some further testing (booting with the earlier xubuntu kernal), and got the same results, so it wasn't from an update added to the kernal. The problem is with the new kernal, and it affects multiple distributions of Linux using it. On a brighter note, I have come up with a way to benchmark this, and produce a list of how much processor power is required to do what. I will perform these benchmarks, and report back. One important thing to be aware of that I have observed so far, is that when running Unity desktop, the DSP-load (reported by qjackctl as RT percentage) is about 20% higher than when running the 'cripple-ware' version of the Ubuntu Classic desktop (which you can still download), on the same machine. My benchmark tests should show what polyphony can be used with what processor speed. If it can work with just limiting the polyphony, then there is a way to work around the problem. When you reach the polyphony limit, you simply record your MIDI tracks into an audio track, and start the process over, adding new MIDI tracks with the audio track. This process can be repeated. It is true that latency is introduced, but the new MIDI tracks are done against the audio track, and there is no need to keep the original MIDI tracks (which would show up the latency problem), except for historical reasons (or to re-create the audio track). Thanks to all of you for being patient with my ranting. Sincerely, Aere On Sat, 2011-11-26 at 09:06 +0000, Louis B. wrote: > > Perhaps Canonical has decided to abandon support of people having > older, slower machines. > > > > Try halving the sample rate with the flag '-r22050' (this halves the > CPU workload for some part of fluidsynth code) > > See: > http://sourceforge.net/apps/trac/fluidsynth/wiki/ExampleCommandLines > fluidsynth on NetBooks and low performance computers > > The only way I have found to sort out performance problems is to add > special debug code that measures how long it takes to execute all the > time critical functions/methods in mSec. > > Equally well someone at Ubuntu or elsewhere could have fiddled with > some time optimised code that now eats up much CPU. > > > > _______________________________________________ > fluid-dev mailing list > fluid-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/fluid-dev -- Sincerely, Aere
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
