Re: [fluid-dev] Major degradation in sound quality & cpu usage going from Ubuntu 11.04 to 11.10

[Aere Greenway]

All:

Your suggestion of cutting the sample rate did not seem to have any affect that was visible to me.  

It may be that I would need to run without Jack, but I need Jack because I use audio files.  

In the past, I have run without Jack, and the performance of Qsynth was better, but not much better.  I could test this further, but it is a moot point, since I need to be able to use audio files in my sequences.  

I performed some benchmark testing on the problems I have been reporting.  

I did all of the following on a 933 megahertz unit-processor (one CPU) machine, which has been my minimum system in my test-bed.  

I tried it on Ubuntu 11.04, and on Xubuntu 11.10.  

My methodology was to reduce the Qsynth polyphony parameter to the point where my test sequence (MIDI) file yielded no underruns.  I did a binary search for the polyphony value that worked.  I did not use Reverb, or Chorus (the check-boxes were clear) in any of the tests.  

With polyphony values above 16, changes of  1 (up or down) made an observable difference.  

I also noted (while the piece was playing) the Digital Signal Processing load (shown in the Qjackctl window as Real Time Percentage (RT %).  

When I got down to the minimum Qsynth polyphony value of 16, I started muting tracks, to where the maximum # of single-note-playing-at-a-time tracks played with no under-runs.  

UBUNTU 11.04
>     
>     Polyphony parameter value without under-runs:    26
>     
>     DSP Load while playing:     Usually in 20% range, sometimes in 30% range, max 38.9%

XUBUNTU 11.10

>     Polyphony paramater value without under-runs:    3 (16, with only 3 tracks playing)
>     
>     DSP Load while playing:    In the 50% range, often getting up into the 60% range.
>     
>     *Note: It will not play a single-track piano part without generating under-runs.  
>     
>From past experience, I observed that UBUNTU 11.10 has a poorer performance than XUBUNTU.  Also, the Unity desktop appears to have DSP Load values 20% higher than the cripple-ware Ubuntu Classic desktop on the same machine.  

As you can see, the performance of the two systems is radically different - an order of magnitude.  It is not just a minor difference.  

The performance hit seems to be associated with the new kernal - not so much the desktop.  Though KUBUNTU had the poorest performance of the three I tried.  

A 2.5 gigahertz unit-processor system (using the Ubuntu Classic desktop) will run the test piece without underruns.  

I have a 1.5 gigahertz machine which I have not yet tried, but based on the above, it will perform poorly, or perhaps marginally.  

On 11.04, all of these machines would perform the test piece on Qsynth without under-runs (though on the 933 megahertz machine, the Qsynth polyphony had to be set down to 26).  

I will do further testing with my 1.5 gigahertz machine, since this is one of the target machines I originally planned to use.  


Sincerely,
Aere
>     
On Sat, 2011-11-26 at 11:31 -0700, Aere Greenway wrote:

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev

-- 

Sincerely,
Aere