12 Oct
2012
12 Oct
'12
6:07 p.m.
On 12 October 2012 at 14:33, Brendan Jones <brendan.jones.it(a)gmail.com> wrote:
On 10/11/2012 06:17 PM, Kevin Cosgrove wrote:
I think it's working, because 'rtirq status' produces results, and
those results show my audio stuff as the highest priority. Earlier I
was confused about threadirqs, thinking that it didn't work because
the RT kernel test reported that no RT kernel was found.
As for "Fedora's rtirq package", I had to get mine from CCRMA, not
Fedora 17 repositories. Were you implying that rtirq would be
available from something other than CCRMA? If so, what's the right
F17 repository for this?
Thanks...
--
Kevin
On 11 October 2012 at 6:55, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
OK. That's a pleasant answer. :-)
I added this:
::::::::::::::
/etc/security/limits.d/93-audio_limits.conf
::::::::::::::
# Increase priority of audio applications
# maximum realtime priority
@audio - rtprio 90
# maximum locked-in-memory address space (KB)
@audio - memlock 2000000
Fedora's jack-audio-connection-kit-1.9.8-9.fc17.x86_64 package added this:
::::::::::::::
/etc/security/limits.d/95-jack.conf
::::::::::::::
# Default limits for users of jack-audio-connection-kit
@jackuser - rtprio 70
@jackuser - memlock 4194304
@pulse-rt - rtprio 20
@pulse-rt - nice -20
I'm having IRQ crowding issues, and I was headed at trying to
get rtirq going in order to help this. I believe rtirq *does*
require an RT kernel.
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#rtirq
the default values provided by jack in limits.d have been chosen to work
with the defaults in Fedora's rtirq package. You should only need to add
threadirqs to the kernel command line you *must* get these permissions correct ...
By permissions, are you meaning
crw-rw---- 1 root audio 10, 228 Oct 10 22:47 /dev/hpet
crw-rw---- 1 root audio 254, 0 Oct 10 22:47 /dev/rtc0
[kevinc #28] groups
kevinc root adm disk wheel cdrom man floppy games audio users jackuser
3.
Kernel with Real-Time Preemption... not found - not good
not necessarily relevant. required in cases where the kernel and h/w are
cooperating (badly) to prevent low latency operation, but many people have
systems where this is not required.