[linux-audio-user] Re: [Jackit-devel] 2.6.10

[Russell Hanaghan]

Rui Nuno Capela wrote:

>Jack O'Quin wrote:
>  
>
>>Here are my results running vanilla 2.6.10.  They support your
>>conclusion, but also the idea that the vanilla kernel is really quite
>>usable.
>>
>>Not sure what system statistics we should collect for this.  My system
>>is Debian woody with 2.6.10 and realtime-lsm on an Athlon 1800+ XP
>>with 256MB main memory and M-Audio Delta-66 sound card.
>>
>>    
>>
>
>Something worth telling, in deed: my laptop's Mandrake 10.1 
>
A question here about Mdk 10.1 {a tad OT}...
I'm under the impression that there are issues preventing the use of 
newer 2.6 kernels with 10.1 because they break stuff. It seems not as 
you are using this kernel.

I don't have the time or really the skillset to build kernels 
efficiently and I rely heavily on Thac's RPM's for my production box. 
But I'm faced with a bit of a mild dilemna; Thac is not supporting the 
10.0 RPMs and there have been many upgrades. But I cannot seem to get 
the 2.6.7 mm.7 kernels to boot on my test box running 10.1 official. And 
If I cant have a RT kernel to use, my production box is gathering 
cobwebs. I don't need zero Xruns at 32x2. I just need reliable RT 
performance with modest latency...I mean damn...I can go mess with my 
Winblows machine to remember what latency blessings we have in Linux 
audio! :) And I can always just hide the Qjackctl window; I'm convinced 
that sometimes just seeing the "Xrun monitor" numbers turn red causes 
some folks to tip the box over and start again with a fresh reinstall! 
If I'm prepared to wear my sox 2 days in a row then I can live with some 
red numbers. :)   Dropouts are unacceptable not Xruns.

R~

>and all my
>tests were taken while on a perfectly usual X desktop session (KDE 3.2),
>bringing more merit to the RT patch performance. Another note goes to my
>custom jackit-0.99.41.10cvs installation: it includes an additional
>max_delayed_usecs-histogram patch (also derived from the Lee's original).
>Without this modification the result lines that read "Delay Count (>1000
>usecs)" are pretty a no-op. Just ignore those, anyway.
>
>Oh, and another important thingie: being it a laptop, it has ACPI support
>set on by default. If ACPI is switched off, I'll surely read fewer XRUNs
>under vanilla 2.6.10, quite as fewer as yours, but then I will miss some
>system monitor goodies (e.g battery status, temperature, etc.).
>Incidentally, Ingo has also solved this ACPI latency issue, and that just
>makes yet another chalkmark for the RT patch ;)
>
>
>  
>
>>I imagine that long 10 msec xrun delay probably occurred during the
>>graph sort after one of the clients disconnected.  If so, that's more
>>of a JACK implementation artifact than a kernel or system problem.
>>
>>************* SUMMARY RESULT ****************
>>Total seconds ran . . . . . . :   300
>>Number of clients . . . . . . :    20
>>Ports per client  . . . . . . :     4
>>Frames per buffer . . . . . . :    64
>>*********************************************
>>Timeout Count . . . . . . . . :(    1)
>>XRUN Count  . . . . . . . . . :     2
>>Delay Count (>spare time) . . :     0
>>Delay Count (>1000 usecs) . . :     0
>>Delay Maximum . . . . . . . . : 10258   usecs
>>Cycle Maximum . . . . . . . . :   825   usecs
>>Average DSP Load. . . . . . . :    32.4 %
>>Average CPU System Load . . . :     7.3 %
>>Average CPU User Load . . . . :    24.1 %
>>Average CPU Nice Load . . . . :     0.0 %
>>Average CPU I/O Wait Load . . :     1.4 %
>>Average CPU IRQ Load  . . . . :     0.7 %
>>Average CPU Soft-IRQ Load . . :     0.0 %
>>Average Interrupt Rate  . . . :  1689.4 /sec
>>Average Context-Switch Rate . : 11771.0 /sec
>>*********************************************
>>
>>    
>>
>
>Hmmm... Now I notice that there was at least one Timeout occurrence. Check
>the output log/chart. In my own experience, when this happens the results
>are pretty skewed right after that timeout moment. Something about clients
>being kicked out from the chain, maybe? Anyway, I believe the only trusty
>results are the ones with 0 (zero) timeouts.
>
>
>  
>
>>Very nice test, BTW.
>>
>>I had to hack it a bit to work on my system (mainly due to an old GCC
>>2.95.4 compiler).  I would love to include some version of this as a
>>`make test' option with the JACK distribution.
>>    
>>
>
>Glad you find it useful. Feel free to it. But take a note that the
>included jack_test_nmeter.c is a minor change from nmeter.c, handed to me
>by Denis Vlasenko on the LKML.
>
>Bye now, and thanks.
>  
>