9 Aug
2006
9 Aug
'06
7:35 p.m.
I just upgraded my LFS 6.1 system from 2.6.12 (with preempt, but not the
-rt patch) to 2.6.15-rt (enabling high resolution timers and PREEMPT_RT
along the way), and now my audio driver is dropping interrupts every few
seconds, something it wasn't doing before.
I haven't configured rtlimits since the program runs as root anyway, and
I'd like it to be free to hog quite a lot if need be.
In my application (which runs in SCHED_FIFO), the audio thread runs at
-10, while the video thread runs at -19. I don't know if that is best,
I just wanted them to be higher than the other threads.
Also, outside forces, like a ssh connection, or a USB dongle connection
cause the program to drop audio madly. Is there some code I need to be
adding to force such system tasks down rather than just elevating my own
application?
--
Joshua D. Boyd
jdboyd(a)jdboyd.net
http://www.jdboyd.net/
http://www.joshuaboyd.org/
13 Aug
13 Aug
6:46 a.m.
Le Wed, 9 Aug 2006 19:20:54 -0400,
Joshua Boyd <jdboyd(a)jdboyd.net> a écrit :
I just upgraded my LFS 6.1 system from 2.6.12 (with
preempt, but not the
-rt patch) to 2.6.15-rt (enabling high resolution timers and PREEMPT_RT
along the way), and now my audio driver is dropping interrupts every few
seconds, something it wasn't doing before.
I haven't configured rtlimits since the program runs as root anyway, and
I'd like it to be free to hog quite a lot if need be.
In my application (which runs in SCHED_FIFO), the audio thread runs at
-10, while the video thread runs at -19. I don't know if that is best,
I just wanted them to be higher than the other threads.
Also, outside forces, like a ssh connection, or a USB dongle connection
cause the program to drop audio madly. Is there some code I need to be
adding to force such system tasks down rather than just elevating my own
application?
A rt kernel will be of almost no use if you don't fix the priorities.
You can use PAM-rlimits or the realtime-lsm module for that, and you
have to be in the audio group.
The audio group will have a higher priority and this is the right way
to do that.
You can take a lock at
http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimeschedu…
PAM-rlimits is the new way of doing that, but if you want an very
low latency for intensive audio work as synthesis or filter, the
realtime.lsm will be better.
A very important issue with a rt kernel is at you must not have shared
IRQ with a such kernel. You can check it with
# cat /proc/interrupts
It is specially important for the sound and the video card.
http://ardour.org/system_requirements
If you are new with rt-kernel, I would recommend you to install an
audio distribution as Demudi, planet CCRMA, jacklab, musix, or the
gentoo audio pro overlay. They all have that rt stuff trimmed for you.
With usb audio card, the IRQ period of the USB bus is 1 msec. That
mean at you must use something as 48KHz 3 periods with jack (That will
be a multiple of that irq period) in order to get a low
latency with such sound cards.
And you MUST NOT be root in all cases with a rt-kernel.
7:52 a.m.
On Sun, 13 Aug 2006 12:46:35 +0200
Dominique Michel <dominique.michel(a)citycable.ch> wrote:
A rt kernel will be of almost no use if you don't
fix the priorities.
You can use PAM-rlimits or the realtime-lsm module for that, and you
have to be in the audio group.
The audio group will have a higher priority and this is the right way
to do that.
You can take a lock at
http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimeschedu…
PAM-rlimits is the new way of doing that, but if you want an very
low latency for intensive audio work as synthesis or filter, the
realtime.lsm will be better.
There's no difference wrt to achievable latencies regarding lsm and pam.
Both are just ways to grant non root users SCHED_FIFO priorities for
their tasks.
A very important issue with a rt kernel is at you must
not have shared
IRQ with a such kernel. You can check it with
# cat /proc/interrupts
It is specially important for the sound and the video card.
http://ardour.org/system_requirements
This is also not true stated like that. It is very well possible to have
shared IRQ's in a -rt system. Usually one doesn't want to have one's
soundcard IRQ shared though, because then the other device driver [and
irq handler] runs at the same prio potentially causing delays for out
soundcard.
If you are new with rt-kernel, I would recommend you to install an
audio distribution as Demudi, planet CCRMA, jacklab, musix, or the
gentoo audio pro overlay. They all have that rt stuff trimmed for you.
With usb audio card, the IRQ period of the USB bus is 1 msec. That
mean at you must use something as 48KHz 3 periods with jack (That will
be a multiple of that irq period) in order to get a low
latency with such sound cards.
And you MUST NOT be root in all cases with a
rt-kernel.
This is also not true. Of course it is possible to run your stuff as
root with a -rt kernel. This also saves you the hassle of setting up
either the realtime lsm or pam. But it is not recommended as running
user stuff as root is often a security risk.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
9:07 a.m.
Le Sun, 13 Aug 2006 13:51:50 +0200,
Florian Paul Schmidt <mista.tapas(a)gmx.net> a écrit :
If I share the same hardware IRQ with my soud card and another
hardware, my whole system just hang from time to time, and that both
with the PIC and with the APIC irq interface. The same append with the
video card. And that with Demudi, gentoo with my own rt-kernel or
with the audio pro rt-kernel, and before with Suse and a rt-kernel.
I have to go in the Bios to reassign the IRQ and/or move the cards from
slot to slot in order to solve this.
It is why I recommend the use of an audio
distribution for a new user
of a rt kernel.
On Sun, 13 Aug 2006 12:46:35 +0200
Dominique Michel <dominique.michel(a)citycable.ch> wrote:
From http://www.jacklab.net/phpBB2/viewtopic.php?t=103 :
"Model 1: " Want to start a synth from time to time"
SUSE Standard kernel with PAM from Rui (also available in the jacklab
repository)
Model 2 "Want to work with MusE or Rosegarden from time to time"
JAD kernel and PAM (Because the SUSE Standard Kernel have no midi RT
tick for sequencers)
Model 3 " I want make some fat production / live performing with many
native FX and soundgenerators with less then 10ms audiolatency" JAD
Kernel and RT-LSM (WARNING: RT-LSM can maybe crash your system)"
It is other websites that say exactly the same.
I have done some test too. The result was a better (lower) latency with
the rt-lsm. The difference was not big, but it was a difference, and it
was a few xruns with PAM-rlimits already with 20% processor use when
it was no xrun with the rt-lsm, the same jackd setting and the same
running programs and processor use.
Another issue is at I was a few times in trouble with the PAM-rlimits
feature that kill any application that is doing a very high processor
use. So, I definitely prefer the realtime-lsm.
A rt kernel will be of almost no use if you
don't fix the priorities.
You can use PAM-rlimits or the realtime-lsm module for that, and you
have to be in the audio group.
The audio group will have a higher priority and this is the right way
to do that.
You can take a lock at
http://demudi.agnula.org/wiki/Low-latencyKernelBuildingHowto#Realtimeschedu…
PAM-rlimits is the new way of doing that, but if you want an very
low latency for intensive audio work as synthesis or filter, the
realtime.lsm will be better.
There's no difference wrt to achievable latencies regarding lsm and pam.
Both are just ways to grant non root users SCHED_FIFO priorities for
their tasks.
A very
important issue with a rt kernel is at you must not have shared
IRQ with a such kernel. You can check it with
# cat /proc/interrupts
It is specially important for the sound and the video card.
http://ardour.org/system_requirements
This is also not true stated like that. It is very well possible to have
shared IRQ's in a -rt system. Usually one doesn't want to have one's
soundcard IRQ shared though, because then the other device driver [and
irq handler] runs at the same prio potentially causing delays for out
soundcard.
If you are new with rt-kernel, I would recommend you to install an
audio distribution as Demudi, planet CCRMA, jacklab, musix, or the
gentoo audio pro overlay. They all have that rt stuff trimmed for you.
With usb audio card, the IRQ period of the USB bus is 1 msec. That
mean at you must use something as 48KHz 3 periods with jack (That will
be a multiple of that irq period) in order to get a low
latency with such sound cards.
And you MUST NOT be root in all cases with a
rt-kernel.
This is also not true. Of course it is possible to run your stuff as
root with a -rt kernel. This also saves you the hassle of setting up
either the realtime lsm or pam. But it is not recommended as running
user stuff as root is often a security risk.
And programs as bristol will just hang the whole system when running
as root or suid root with a rt-kernel. It is one of the advantage of a
rt-kernel: you can run jack with rt priority as normal user (in the
audio group), and it is the right way to use such a kernel.
Cheers,
Dominique
Flo
15 Aug
15 Aug
4:02 a.m.
On Sun, 13 Aug 2006 15:07:04 +0200
Dominique Michel <dominique.michel(a)citycable.ch> wrote:
From http://www.jacklab.net/phpBB2/viewtopic.php?t=103
:
"Model 1: " Want to start a synth from time to time"
SUSE Standard kernel with PAM from Rui (also available in the jacklab
repository)
Model 2 "Want to work with MusE or Rosegarden from time to time"
JAD kernel and PAM (Because the SUSE Standard Kernel have no midi RT
tick for sequencers)
Model 3 " I want make some fat production / live performing with many
native FX and soundgenerators with less then 10ms audiolatency" JAD
Kernel and RT-LSM (WARNING: RT-LSM can maybe crash your system)"
It is other websites that say exactly the same.
Many websites saying the same thing doesn't nessecarily make this true.
Of course there are some subtle differences between rlimits and the
realtime lsm:
- rlimits allow specifying a maximum priority which uers processes are
allowed to aquire
- rt lsm otoh gives the user the ability to use any rt priority [or none
at all]
- rlimits allow specifying a maximum memory size for mlocking.
- rt lsm otoh again gives the user the ability to use any amount [or
none at all]
- rlimits allow specifying a maximum niceness which user processes are
allowes to aquire
- rt lsm otoh ... [well you get the picture]
The point being that rlimits allow for finer control of what a user
process is allowed to do. So depending on how you have rlimits
configured, you might get differing results from a rt lsm installation.
So let me rephrase my statement:
Given that you have setup rlimtis and rt lsm in equivalent ways, there
must be no measurable difference in achievable latencies. If you do
measure differences, some other factor of your setup differs, too.
Like i said: To my knowledge rt lsm and rlimits are just two different
ways to achieve the same thing: Giving user processes rt scheduling,
mlocking and negative niceness.
As my experience with rlimtis is limited, i still have one more question
regarding the funcitonality of rlimits. It once was discussed on the
mailing lists to include cpu usage throtteling for user processes (i.e.
max. 90% cpu usage, so that runaway processes cannot fully lock the
box). Has this been implemented?
Another issue is at I was a few times in trouble with
the PAM-rlimits
feature that kill any application that is doing a very high processor
use. So, I definitely prefer the realtime-lsm.
I don't know that rlimits kill processes on high cpu load. Never heard
of this feature.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
4:32 a.m.
On Tue, 15 Aug 2006 10:02:25 +0200
Florian Paul Schmidt <mista.tapas(a)gmx.net> wrote:
Given that you have setup rlimtis and rt lsm in
equivalent ways, there
must be no measurable difference in achievable latencies. If you do
measure differences, some other factor of your setup differs, too.
Let me add: If you actually have setup rt lsm and rlimits in an
equivalent way and the rest of the system is the same, too, and you
still measure a difference, then you have found a bug in the kernel.
Please report it to lkml.
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6831
days inactive
6837
days old
linux-audio-dev@lists.linuxaudio.org
5 comments
3 participants
participants (3)
-
Dominique Michel -
Florian Paul Schmidt -
Joshua Boyd