Subject: Re: [linux-audio-user] Which kernel for low latency
From: Glenn McCord (clari_player_AT_paradise.net.nz)
Date: Wed Jan 21 2004 - 05:05:42 EET
martijn wrote:
>Once upon a Tue, Jan 20 2004, Glenn McCord hit keys in the following order:
>
>
>>I adjusted some things. For me the realtime patch didn't work so I
>>reverted back to modifying capabilities.h by hand.
>>
>>
>
>Realtime patch? i assume you mean the realtime LSM from www.joq.us. You build
>it separately, although you do need to set KERNEL_DIR to your kernel-2.6.x
>sources because it uses the kernel's build system. Where does it fail? Also,
>make shure you add 'options realtime allcaps=1' to your /etc/modprobe.conf,
>otherwise it will not work with jackstart.
>
It fails when I try and run jackstart and i gives this error:
glenn_AT_upstairs glenn $ jackstart -R -v -d alsa -d hw:0
jackstart: cannot get realtime capabilities, current capabilities are:
=ep cap_setpcap-ep
probably running under a kernel with capabilities disabled,
a suitable kernel would have printed something like "=eip"
I modified modprobe.conf but it's ignored. When I restart the machine
the line I added disappears anyway when it does an update-modules.
modprobe.conf has a comment saying I should modify modules.conf instead
but that doesn't do any good either.
Here's the error that comes up:
>
>Just interested, how did you modify capability.h? i couldn't get it to compile
>when i tried that.
>
>
replace
#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
with
#define CAP_INIT_EFF_SET to_cap_t(~0)
Below this line, there should be another line that should looks like:
#define CAP_INIT_INH_SET to_cap_t(0)
so replace it with
#define CAP_INIT_INH_SET to_cap_t(~0)
>
>
>>So I'm thinking somethings missing in the kernel somewhere. Or perhaps
>>the system settings are disagreeing with the way the kernel is setup.
>>
>>
>
>I had problems too and discovered that i was compiling my IDE chipset support
>as a module that never got loaded. No UDMA is a bad thing for performance. You
>can check it with something like 'hdparm -d /dev/hda'.
>
>
>mrtn.
>
>
>
# hdparm -d /dev/hda
/dev/hda:
using_dma = 1 (on)
I'm assuming this is what I'm supposed to get.
xruns happen when I open ardour, create a track, remove tracks and
whenever I record for anything longer than a couple of seconds. I was
able to record for 20 seconds just before, but that's because I was lucky.
I noticed that the cpu load indicator in ardour fluctuates all over the
show. After an xrun it jumps from below 10% to about 30-50%. With the
2.4 it never rises above 3%. I may just have to nag the ardour mailing
list instead.
rezound gives the same strife. xruns occur when dialogue boxes open and
after recording for a few seconds.
I feel like I'm going in circles now so I may just have to revisit it in
6 months or something.
Thanks for all the help though.
This archive was generated by hypermail 2b28 : Wed Jan 21 2004 - 05:08:50 EET