[linux-audio-user] Which kernel for low latency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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.


[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux