You are not logged in.
Pages: 1
Topic closed
I cannot seen to get jack and aurdor working with low latency. I get many xruns on these Kernels: kernel26, -archck, and -mm. I have a 2800 AMD with 512mb - it should be running pretty well. In root, no xruns. Does anybody have any success with a low latency kernel in arch? Thanks, E.
Offline
Offline
Thanks for the reply. I have followed all recommended values that the wiki suggested and still I get xruns (using the vanilla kernel26). Here is sample of the jack output (I have tried various settings for jack and I do not get xruns at around 50ms latency) . . .
cannot lock down memory for jackd (Cannot allocate memory)
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:0|hw:0|64|3|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 64 frames, buffer = 3 periods
nperiods = 3 for capture
nperiods = 3 for playback
cannot use real-time scheduling (FIFO at priority 95) [for thread 1101626288, from thread 1101626288] (1: Operation not permitted)
cannot use real-time scheduling (FIFO at priority 85) [for thread 1110018992, from thread 1110018992] (1: Operation not permitted)
delay of 1733.000 usecs exceeds estimated spare time of 1314.000; restart ...
delay of 1733.000 usecs exceeds estimated spare time of 1314.000; restart ...
18:14:25.823 Server configuration saved to "/home/charlietuna/.jackdrc".
18:14:25.824 Statistics reset.
18:14:25.827 Client activated.
18:14:25.836 Audio connection change.
18:14:25.839 Audio connection graph change.
18:14:25.839 XRUN callback (1).
**** alsa_pcm: xrun of at least 5.791 msecs
subgraph starting at qjackctl-4186 timed out (subgraph_wait_fd=9, status = 0, state = Triggered)
**** alsa_pcm: xrun of at least 6.321 msecs
cannot lock down memory for RT thread (Cannot allocate memory)
cannot use real-time scheduling (FIFO at priority 84) [for thread 1106652080, from thread 1106652080] (1: Operation not permitted)
**** alsa_pcm: xrun of at least 13.461 msecs
18:14:27.220 XRUN callback (4).
delay of 1667.000 usecs exceeds estimated spare time of 1304.000; restart ...
delay of 1667.000 usecs exceeds estimated spare time of 1304.000; restart ...
**** alsa_pcm: xrun of at least 1.605 msecs
. . . the xruns continue from there.
I have also followed the audio guide by Con Kolivas on his website here: http://ck.kolivas.org/audio_hints.txt.
I don't know where to search next for the problem - alsa?
Thanks.[/code]
Offline
you need realtime-lsm setup. Dont ask me how. It is included in the latest archck however. Not sure if its in the community package.
Offline
The wiki seems to state that the approach in the arch26 kernel is by using limits.conf. Are limits.conf and realtime-lsm two different low latency approaches? In any case - I still cannot get low latency. If anyone can help - thanks.
Offline
Are you using a kernel before 2.6.12?
Offline
2.6.14
Offline
Ahh... Testing. Maybe you should report this as a bug...
Offline
Just downgraded to stable 2.6.13 kernel and same problems.
Offline
That is truly bizarre. What's in your /etc/security/limits.conf?
Offline
Here are the contents of /etc/security/limits.conf:
* - rtprio 0
* - nice 0
@audio - rtprio 80
@audio - nice -10
@audio - memlock 250000
I have tried different values as well.
Offline
Heya, been a while since i've frequented these parts.
yeah, i'm getting exactly the same issue using rlimits, ahve teh same limits.conf as that one there.
I wonder if this needs turning on in the kernel and hasn't been? who knows
But anyways, at the moment i've resorted to a root fluxbox session for audio work so i can get realtime, but even then jack xruns on me too much. (up to 5 times a min)
Offline
I looked through the konfig26 file and found this part - I believe this is part of the low latency configuration:
CONFIG_SCHED_SMT=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
Are these the correct settings to get rlimits to work?
Offline
Does anybody use arch for audio? DOes this kernel work out of he box for anybody with adjustments to limits.conf?
Offline
2.6.13-ARCH does work for me out of the box.
Latency: 2.67 ms
limits.conf:
@audio - rtprio 80
@audio - nice -10
@audio - memlock 250000
Offline
I just tried a new arch 7.1 install on a second drive - changed limits.conf - no luck on getting rid of xruns. I am getting better latency on an old compaq work machine than on this one. Any suggestions on what to try next. I have a delta 1010lt sound card if that helps.
Offline
Still no luck with 2.6.15 for me.
I've reporte dthis as a bug: http://bugs.archlinux.org/task/3729
Hope it's seen to soon
Offline
Hi,
I know this is an old thread, but I wanted to post anyway since I've got some experience in this area that might be of interest to others who Google for Arch Linux and audio/lowlatency (lowlatency, low latency or low-latency) issues...(I put those tags in there for Google!)
It's VERY important to check out the output of /proc/interrupts to see your IRQ situation, using the output of /proc/interrupts to do your detective work:
~$ cat /proc/interrupts
Basically, I've found that even without low latency patches, etc. one can DRAMATICALLY improve the xruns situation by either finding a way to give your audio card a higher-priority IRQ (usually this means a lower number, except 3,4,5,6,7 which for some reason are the worst priorities to have, at least this is what I've read), or to disable hardware you don't really need while processing audio, i.e. the stuff that is getting in the way of your audio hardware by stealing a higher priority IRQ from it. I remember there used to be a kernel option for "IRQ balancing", your milage may vary, but sometimes this helps distribute IRQs at bootup in a way that may accidently benefit your audio situation...again---your milage may vary, so don't assume. It's worked for me in the past.
In my case, I just bought a Lexicon Lambda outboard USB audio interface, and my network card and onboard sound card were assigned better IRQs---so I disabled them with "modprobe -r name_of_annoying_module". I was getting an xrun several times a minute, and choppy, glitchy audio. After shutting these things down--no problem---smooth as silk.I concluded that it's ABSOLUTELY ESSENTIAL to at the very least disable the onboard sound when using an outboard USB interface. (and, BTW, load the snd-usb-audio module using the 'nrpacks=1' option)
from /etc/modprobe.conf:
options snd-usb-audio nrpacks=1
This will do good things to the throughput of the USB bus if you happen to use a USB interface for audio and MIDI!
Of course, one can check out the articles out there about PCI latency, too, but I didn't have to go that far. And, everything else that has been said really puts it all together---cutting down on other processes (use fluxbox for instance, stay off your network while recording and/or disable network cards, disable logging), using a 1000hz kernel and perhaps a patched Ingo Molnar kernel (I say perhaps b/c I've managed just fine without), and doing all the stuff like HD tuning and using the correct settings in /etc/security/limits.conf...all that has been covered elsewhere.
Good luck!
Offline
Hi,
I know this is an old thread, but I wanted to post anyway since I've got some experience in this area that might be of interest to others who Google for Arch Linux and audio/lowlatency (lowlatency, low latency or low-latency) issues...(I put those tags in there for Google!)
It's VERY important to check out the output of /proc/interrupts to see your IRQ situation, using the output of /proc/interrupts to do your detective work:
~$ cat /proc/interrupts
Basically, I've found that even without low latency patches, etc. one can DRAMATICALLY improve the xruns situation by either finding a way to give your audio card a higher-priority IRQ (usually this means a lower number, except 3,4,5,6,7 which for some reason are the worst priorities to have, at least this is what I've read), or to disable hardware you don't really need while processing audio, i.e. the stuff that is getting in the way of your audio hardware by stealing a higher priority IRQ from it. I remember there used to be a kernel option for "IRQ balancing", your milage may vary, but sometimes this helps distribute IRQs at bootup in a way that may accidently benefit your audio situation...again---your milage may vary, so don't assume. It's worked for me in the past.
In my case, I just bought a Lexicon Lambda outboard USB audio interface, and my network card and onboard sound card were assigned better IRQs---so I disabled them with "modprobe -r name_of_annoying_module". I was getting an xrun several times a minute, and choppy, glitchy audio. After shutting these things down--no problem---smooth as silk.I concluded that it's ABSOLUTELY ESSENTIAL to at the very least disable the onboard sound when using an outboard USB interface. (and, BTW, load the snd-usb-audio module using the 'nrpacks=1' option)
from /etc/modprobe.conf:
options snd-usb-audio nrpacks=1
This will do good things to the throughput of the USB bus if you happen to use a USB interface for audio and MIDI!
Of course, one can check out the articles out there about PCI latency, too, but I didn't have to go that far. And, everything else that has been said really puts it all together---cutting down on other processes (use fluxbox for instance, stay off your network while recording and/or disable network cards, disable logging), using a 1000hz kernel and perhaps a patched Ingo Molnar kernel (I say perhaps b/c I've managed just fine without), and doing all the stuff like HD tuning and using the correct settings in /etc/security/limits.conf...all that has been covered elsewhere.
Good luck!
You're doing audio work on Arch? I'm curious how it is going with the latency - and how low you can get it - and how you've measured it.
Thanks - it would be sweet to outperform OSX & Windows in audio latency.
Offline
Please do not necrobump.
Closing.
How to post. A sincere effort to use modest and proper language and grammar is a sign of respect toward the community.
Offline
Pages: 1
Topic closed