SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
i am once again puzzled as to patch and convert a mainline kernel to a real time one. The reason is that jackd will give me xruns:
nass@starbase:~$ set_rlimits jackd -R -d alsa -D -p256
**** alsa_pcm: xrun of at least 0.026 msecs
**** alsa_pcm: xrun of at least 0.022 msecs
**** alsa_pcm: xrun of at least 0.025 msecs
Well i hope I have convinced you I need to patch my kernel (to those of you I didn't convince, please please tell me if there is anything else to try - apart from increasing the jack frames/period :P (option -p above)
I should also mention that this very same hardware, could run in winXP with the asio drivers and a latency of no more than 12msec. Now if I start the jackd server with even 21msec latency, i'll still get frequent xruns...
Things like nvidia drivers do not work with real time kernel, as I read, but does the nv driver work? I am not interesting in fancy 3d graphics and composite stuff but I hope I can use the nv driver. Does anyone have experience with the RT kernel? does anyone know of other things that will be broken?
jackd has to run with realtime privileges. One way to do this on Slackware
would be to use set_rlimits. Since 12.2 there's another way - if you have
a filesystem that supports posix capabilities (reiserfs does not), you can
grant jackd the rights to run in realtime mode, even when started as a
normal user, with the following command:
I usually record on Ardour by using the official slackware-current kernel version, getting a jack latency < 10 ms.
(I'm actually using a firewire Presonus Firebox)
But, in order to do so, I always have to reduce my ati gpu power state in order to avoid xruns.
Before running jack, I have to change my power_profile (....altough I always receive an NMI warning message from the kernel!..but it's a different matter):
4strings, yes it is an nvidia and i don't see any problems of the sort.Thank you though.
So some findings:
using the professional audio card (a Hoontech DSP24 with DSP2000 outboard, based on ice1712) and the 18.104.22.168 kernel tweaked as explained earlier, I will still get scarce xruns of jackd with 512 frames/period. this results in a latency of 10.7ms @48kHz.
The pc is somewhat old (AMD Athlon(tm) XP 2600+, 1GB RAM) but as stated before I remember I could run in winXP with latencies less than 12ms stably.
Well here comes the magic though; with the 3.2.28-rt41 patched kernel (with a slight modilfied generic config),
I can go down to 128 frames /period and still run jackd solid. Thats a latency of 2.7ms @48kHz. It is a DAW at its best using linux and indeed slackware
just for reference the command I used to run jackd (after using setcap per Ponce's suggestion):
jackd -R -dalsa -dhw:2,0 -D -p128 -r48000 -H -M
where hw:2,0 is the pro-audio card.
AS for the system, it's only been running for a day but I haven't noticed any instability.
well i hadn't used it before , cause in other cases I was on reiserfs filesystems.
so set_rlimits came as the natural choice to mind once again.
But when you mentioned it again, i decided to give it a go on this system that's running on jfs
just out of interest, have you ever tried the BFS cpu scheduler, maybe in conjunction with scheduling class SCHED_RR for sound applications? I have no experience in the field of sound latency, but since latency is the whole point of BFS it might help.