On 10/11/2012 08:33 AM, Kevin Cosgrove wrote:
More information on tweaking your setup:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
I've been trying to reduce my xrun troubles. I'm down from > 10
xruns per second to something more like 10 xruns per minute. Still
not good, but better.
I used the realTimeConfigQuickScan.pl script to diagnose things.
https://code.google.com/p/realtimeconfigquickscan/
I'm down to three things reported as "not good" now.
1. Checking checking sysctl inotify max_user_watches... < 524288 - not good
increase max_user_watches by adding 'fs.inotify.max_user_watches = 524288'
to /etc/sysctl.conf and rebooting
For more information, see
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#sysctl.conf
Looking at the link there's a comment, "...it remains very
unclear ... if adjusting this value actually does anything at
all." So, I haven't altered this. Does anyone have
experience saying that this helped them?
Hello Kevin,
I've added this comment after having asked the exact same question at my
LAC2011 workshop. Nobody in the audience could acknowledge that changing
the inotify setting helped anything.
2. chrt: failed to set pid 0's policy: Operation not permitted
Checking the ability to prioritize processes with chrt... no - not good
Could not assign a 80 rtprio value. Set up limits.conf.
For more information, see
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#limits.conf
I did make the changes outlined at the above link. I still
get the above report. I'm going to guess that I need some
real-time support from the kernel to make this work. Which
brings me to
3. Kernel with Real-Time Preemption... not found - not good
Kernel without real-time capabilities found
For more information, see
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#installing_a_real-time_kernel
First I looked at this link:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#the_kernel
Specifically, I looked at the threadirqs kernel option.
grep -e CONFIG_IRQ_FORCED_THREADING=y -e CONFIG_PREEMPT=y /boot/config-`uname -r`
produces "CONFIG_IRQ_FORCED_THREADING=y" and I think that's good.
No it's not, unless it also outputs CONFIG_PREEMPT=y. if it doesn't than
your kernel isn't preemtible and in that case I doubt if threadirqs or
even chrt works (no expert on this).
I altered my /boot/grub2/grub.cfg file to include
"threadirqs" on the stanza for my kernel, like so, but
without all the line breaks.
linux /boot/vmlinuz-3.5.5-2.fc17.x86_64
root=UUID=77edf07a-a49b-48dd-82c8-2f9e5c8691b7 ro nomodeset
rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True KEYTABLE=us rd.luks=0
LANG=en_US.UTF-8 rhgb quiet threadirqs nouveau.modeset=0
rd.driver.blacklist=nouveau
Slightly OT, but wow, that's a whole lot of kernel options ;) I only use
two or three.
"uname -r" reports "3.5.5-2.fc17.x86_64" but I don't have
threaded IRQs.
Any ideas on how to improve my IRQs? They are not alterable in the BIOS.
Thanks....
Check if your kernel is preemtible (at least, I think that might be a
probable cause) or install a kernel that is preemtible (there's no
real-time kernel available for FC17?). But like I said, I'm no expert on
the different preemption models so I could be completely wrong.
Hopefully someone with more knowledge on this matter chimes in.
Best,
Jeremy
--
Kevin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
http://lists.linuxaudio.org/listinfo/linux-audio-user
