[Linuxsampler-devel] LS/QS CPU Activity - looking at note counts vs. bpm

[Mark K. <mk...@co...>]

Mark Knecht wrote:
  > Problem Report - CPU usage - I'm apparently able to overrun my 3GHz
> machine with just a single note on the mouse. If I continually play a 
> single note so that QS says I'm up to 43 voices, then gkrellm is showing 
> CPU usage jumps up to 100%. Top shows about 90% of the CPU going to LS 
> and 10% to QS. This only takes about 2-3 clicks per second and happens 
> in about 15 seconds. I think something is really not right about this. 
> There is no disk activity. The note is a cymbal crash which is probably 
> 100% in RAM.
> 
> Why should CPU usage be so high at this point?
> 
> The note I'm hitting has about a 7-8 second tail. If I hit a single note 
> and watch LS then the S/V count goes to 1 and stays for 7-8 seconds 
> before it drops back to 0.
> 
> In my mind, when I start hitting lots of the same note the ones I hit at 
> t=0 should not be playing after t=9 but it appears to me that they are 
> not being released by LS. At 2-3 notes/second I should never be able to 
> make the S/V count go higher than 27 on this sample.
> 
> I bet when we figure this out LS will work better. (Assuming I'm not 
> totally messed up and wrong about how it should operate!)
> 
> There was something else I was going to report or ask for but I cannot 
> remember it right now.
> 
> Thanks,
> Mark
> 

Hi,
    I set up Rosegarden as a test platform to look at LS/QS more 
carefully. This allows me to more accurately control the number of MIDI 
events being sent.

    I think that QS's stream/voice counts are working correctly until we 
hit some problem. Once we hit the problem the readouts all start acting 
strange. Also CPU usage is just way too high for what I'm doing here. 
GSt on a 500MHz P3 wouldn't even break a sweat with this voice count. LS 
is having a very hard time on a 3GHz machine...

1) Made a single measure with 4 quarter notes triggering the ride cymbal 
in this Wizzo drum set gig file. The cymbal has (roughly) a 7 second 
tail. I then set up RG to just loop on this one measure.

2) Set the tempo to different values and logged S/V counts in QS.

NOTE 1:QS/LS is having some problems with the 'least filled stream 
buffer' numbers. The numbers are there and then they go to 0% for a 
while, then come back, and go back to 0% for a while. When they go to 0% 
the S/V count does not update. This happens (for me) before there is 
audio drop out.

NOTE 2: The 'least filled stream buffer' numbers below are visual 
readings only. The real values jump around a bit. These are just my best 
guess.

NOTE 3: With LS/QS not running RG by itself uses about 15% CPU at all 
bpm's shown below. I presume we subtract 15% from each of the readings 
to get the QS/LS CPU usage.

60bpm  - 81% - 7/7   - 25% CPU (10%)
120bpm - 81% - 13/13 - 40% CPU (25%)
180bpm - 79% - 20/20 - 55% CPU (40%)
240bpm - 82% - 27/27 - 72% CPU (57%)
300bpm - 77% - 33/33 - 87% CPU (72%)
320bpm - 76% - 35/35 - 91% CPU (76%)
340bpm - 74% - 38/37 - 96% CPU (81%)

At this point I start getting audio drop outs and afer a few seconds I 
get a message from Rosegarden telling me:

"JACK audio subsystem is losing sample frames"

If I stop RG then, with some luck, LS/QS will go back to 0/0 and work 
correctly, but it I let the audio dropouts happen for a longer time then 
they will not and LS stays messed up until I kill everything and start over.

My system may very well be a bit crippled. I'm on a 2.6.6 Gentoo 
development kernel with no patches. I'm running everything (qjackctl, 
RG, LS and QS) as a normal user, not root. Maybe some changes to that 
would help. I would expect so...

None the less I get superior results today from Win ME on a slower 
computer. Not totally unexpected due to its maturity, but I'd certainly 
hope for better numbers from LS one day soon.

Thanks,
Mark