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

[Fernando Lopez-Lezcano]

On Thu, 2004-12-30 at 03:19, Rui Nuno Capela wrote:
> The jackd command line is therefore:
> 
>   jackd -v -R -P60 -dalsa -dhw:0 -r44100 -p64 -n2 -S -P
> 
> The results speak for themselves :)
>                                   2.6.10-cko1  RT-V0.7.33-04
>                                   ------------- -------------
>   Timeout Rate  . . . . . . . . :    (    0.0)    (    0.0)   /hour
>   XRUN Rate . . . . . . . . . . :       216.8          2.2    /hour
>   Delay Rate (>spare time)  . . :       395.2          0.0    /hour
>   Delay Rate (>1000 usecs)  . . :       375.8          0.0    /hour
>   Delay Maximum . . . . . . . . :      4320          308      usecs
>   Cycle Maximum . . . . . . . . :       845         1051      usecs
>   Average DSP Load. . . . . . . :        44.0         50.2    %
>   Average CPU System Load . . . :        14.4         31.7    %
>   Average CPU User Load . . . . :        19.8         21.4    %
>   Average CPU Nice Load . . . . :         0.0          0.0    %
>   Average CPU I/O Wait Load . . :         0.1          0.1    %
>   Average CPU IRQ Load  . . . . :         0.0          0.0    %
>   Average CPU Soft-IRQ Load . . :         0.0          0.0    %
>   Average Interrupt Rate  . . . :      1691.7       1692.6    /sec
>   Average Context-Switch Rate . :     13368.8      18213.9    /sec
> 
> 
> So, bottom-line goes like this: even though vanilla is getting a little
> more tasty, Ingo's RT patch performance beats it up by orders of
> magnitune. Nuff said. ;)

Yes, when it works it is fantastic. Regretfully it does not always work.
Several Planet CCRMA users have had problems with a very recent release
featuring 0.7.33-04 (ie: machines not making it to the end of the boot
process[*]). I've had lockups on my smp test machine, no clue left
behind (and when compiled with full debugging it would not even boot). 

Anyway, it _is_ amazing work!
Kudos to all the gurus involved!

Now we have both alternatives, a "bleeding edge" kernel and a fairly
decent one, almost stock (2.6.10).

-- Fernando

[*] "Bug: Scheduling while atomic: IRQ14/0x00000001/297" (IRQ14 is the
hard disk :-), another one dying with: "gdb_hook_interrupt: Could not
clear IER, not a UART!", this one solved through doing: "Hmm, I thought,
interrupt handling?  Low and behold my BIOS was set with PIC rather than
APIC.  It now boots fine."

Of course these could be just kernel bugs unrelated to, or uncovered by,
the realtime preempt patch, maybe fixed in 2.6.10... We'll see today how
2.6.10 fares when I release packages.