7 May
2012
7 May
'12
2:06 p.m.
I understand that the rtirq script is designed to raise rtprio for audio
devices, which is made possible on the vanilla kernel since 2.6.39(?),
if passing the threadirqs option to the kernel at boot, and having built
it with the CONFIG_FORCE_THREADIRQ.
From my experience, I have not had any performance boost using the
rtirq script, but I have read about it helping those who are getting
xruns due to irq sharing.
So, I'm wondering. What picture do others have of the benefit of the
rtirq script?
..and are there other ways to measure improvement for audio operation
other than spotting xruns at different latency settings, and reading the
rtprio for various devices using the 'ps' command?
7 May
7 May
2:08 p.m.
On 05/07/2012 02:06 PM, Kaj Ailomaa wrote:
I understand that the rtirq script is designed to
raise rtprio for audio
devices, which is made possible on the vanilla kernel since 2.6.39(?),
if passing the threadirqs option to the kernel at boot, and having built
it with the CONFIG_FORCE_THREADIRQ.
I meant CONFIG_IRQ_FORCED_THREADING=y, of course..
From my experience, I have not had any performance boost using the
rtirq script, but I have read about it helping those who are getting
xruns due to irq sharing.
So, I'm wondering. What picture do others have of the benefit of the
rtirq script?
..and are there other ways to measure improvement for audio operation
other than spotting xruns at different latency settings, and reading the
rtprio for various devices using the 'ps' command?
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:24 p.m.
On 05/07/12 14:06, Kaj Ailomaa wrote:
I understand that the rtirq script is designed to
raise rtprio for audio
devices, which is made possible on the vanilla kernel since 2.6.39(?),
if passing the threadirqs option to the kernel at boot, and having built
it with the CONFIG_FORCE_THREADIRQ.
From my experience, I have not had any performance boost using the
rtirq script, but I have read about it helping those who are getting
xruns due to irq sharing.
Hello Kaj,
rtirq allows you to elevate the prios of softirq's which could enhance
the performance of those prioritized softirq's. So it doesn't really
boost the overall performance of a system.
So, I'm wondering. What picture do others have of
the benefit of the
rtirq script?
Without rtirq I simply can't use my FireWire card on my notebook for
example. The FireWire controller shares its IRQ with a plethora of other
devices (GPU, WiFi, cardreader) and if I don't use rtirq jackd simply
won't start.
..and are there other ways to measure improvement for
audio operation
other than spotting xruns at different latency settings, and reading the
rtprio for various devices using the 'ps' command?
Yes, htop and latencytop for example.
Best,
Jeremy
2:52 p.m.
On 05/07/2012 02:24 PM, Jeremy Jongepier wrote:
On 05/07/12 14:06, Kaj Ailomaa wrote:
Does anyone ever find themselves not being able to solve their problem
with the rtirq script?
And what about software processes? The network-manager, cron, and other
things we have heard about, when you get periodic xruns no matter which
latency you use. Can we make all of those problems go away by changing
rtprio for devices?
I understand that the rtirq script is designed to
raise rtprio for audio
devices, which is made possible on the vanilla kernel since 2.6.39(?),
if passing the threadirqs option to the kernel at boot, and having built
it with the CONFIG_FORCE_THREADIRQ.
From my experience, I have not had any performance boost using the
rtirq script, but I have read about it helping those who are getting
xruns due to irq sharing.
Hello Kaj,
rtirq allows you to elevate the prios of softirq's which could enhance
the performance of those prioritized softirq's. So it doesn't really
boost the overall performance of a system.
So, I'm wondering. What picture do others
have of the benefit of the
rtirq script?
Without rtirq I simply can't use my FireWire card on my notebook for
example. The FireWire controller shares its IRQ with a plethora of other
devices (GPU, WiFi, cardreader) and if I don't use rtirq jackd simply
won't start. ..and are there other ways to measure improvement
for audio operation
other than spotting xruns at different latency settings, and reading the
rtprio for various devices using the 'ps' command?
Yes, htop and latencytop for example.
Best,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user 
2:33 p.m.
On Mon, 2012-05-07 at 14:06 +0200, Kaj Ailomaa wrote:
..and are there other ways to measure improvement for
audio operation
other than spotting xruns at different latency settings, and reading the
rtprio for various devices using the 'ps' command?
For MIDI there e.g. is JACK2's jack_midi_latency_test especially
interesting when using -Xalsarawmidi.
Most important, for audio and MIDI there's your trained hearing.
If you e.g. are working for an audio studio and your engineering does
sound as it should sound and you've got similar equipment at home, but
it doesn't sound as it should sound, than you'll like tools for
troubleshooting. Assumed Jack1 does disconnect clients, than you'll have
tools for troubleshooting. Assumed your MIDI sequencer has an audible
bad timing, or simply it won't groove, than you'll use tools for
troubleshooting. Assumed a digital copy internal Linux has an audible
quality loss, than you might compare spectrograms using Audacity.
Assumed ... [snip]
If everything sounds good for you, no app will crash etc., than it's
irrelevant what the output of rtirq status and other control methods is.
If you know that your machine has weak points, than you'll get stuff
like rtirq already working, before you try to fix other issues or yu
even d a test recording.
rtirq - what does it improve, and how can I measure it?
It improves the priority. What would you like to measure? Perhaps you
like to monitor using top, atop, htop?
Why will you measure or monitor? If everything is ok, than it's ok, than
it's ok. If not, you'll find out what's going wrong. IMO the first thing
to do, is to run top, to e.g. ensure that there isn't an instance of
Firefox using 70% RAM and 85% CPU resources.
Regards,
Ralf
3:16 p.m.
On 05/07/2012 02:32 PM, Ralf Mardorf wrote:
On Mon, 2012-05-07 at 14:06 +0200, Kaj Ailomaa wrote:
This is something I always put first when making music, using any
equipment, or any method to make it.
..and are there other ways to measure improvement
for audio operation
other than spotting xruns at different latency settings, and reading the
rtprio for various devices using the 'ps' command?
For MIDI there e.g. is JACK2's jack_midi_latency_test especially
interesting when using -Xalsarawmidi.
Most important, for audio and MIDI there's your trained hearing.
If you e.g. are working for an audio studio and your
engineering does
sound as it should sound and you've got similar equipment at home, but
it doesn't sound as it should sound, than you'll like tools for
troubleshooting. Assumed Jack1 does disconnect clients, than you'll have
tools for troubleshooting. Assumed your MIDI sequencer has an audible
bad timing, or simply it won't groove, than you'll use tools for
troubleshooting. Assumed a digital copy internal Linux has an audible
quality loss, than you might compare spectrograms using Audacity.
Assumed ... [snip]
If everything sounds good for you, no app will crash etc., than it's
irrelevant what the output of rtirq status and other control methods is.
If you know that your machine has weak points, than you'll get stuff
like rtirq already working, before you try to fix other issues or yu
even d a test recording.
rtirq - what does it improve, and how can I measure it?
It improves the priority. What would you like to measure? Perhaps you
like to monitor using top, atop, htop?
I'm merely being interested in finding out more about what problems
exist tuning your machine for "pro" audio, since I'd like to participate
in making this easier for linux users in general.
Right now, I've been looking at this particular area, and I'm trying to
find out what the problems are, which problems are solved, and if there
are any problems that are not solved.
Why will you measure or monitor? If everything is ok,
than it's ok, than
it's ok. If not, you'll find out what's going wrong. IMO the first thing
to do, is to run top, to e.g. ensure that there isn't an instance of
Firefox using 70% RAM and 85% CPU resources.
Regards,
Ralf
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3:29 p.m.
On 05/07/12 15:16, Kaj Ailomaa wrote:
I'm merely being interested in finding out more
about what problems
exist tuning your machine for "pro" audio, since I'd like to participate
in making this easier for linux users in general.
Right now, I've been looking at this particular area, and I'm trying to
find out what the problems are, which problems are solved, and if there
are any problems that are not solved.
Maybe this Wiki article could be helpful:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Best,
Jeremy
9:39 p.m.
On 05/07/2012 03:29 PM, Jeremy Jongepier wrote:
On 05/07/12 15:16, Kaj Ailomaa wrote:
It's a nice page with a lot of good info.
For myself, I only need to add a couple of config options to a vanilla
kernel, and add myself to the appropriate group to get what I need for
live audio processing.
Which indicates that any other needed config to achieve the same
functionality on another machine is somehow hardware dependent.
I'm still unclear about things like the networkmanager, which only
causes problems on certain machines. Disabling it does not seem like a
good "standard" way to configure your desktop for audio use. Rather the
last resort, when you are having problems.
Perhaps it is impossible to get any kind of acceptable operation on some
machines because of hardware design, and no reasonable coding would fix
that on any level.
Fixing things can be done on many levels. Some are better down lower
down, and some higher up.
I prefer to have as little done high up, if possible.
I'm merely being interested in finding out
more about what problems
exist tuning your machine for "pro" audio, since I'd like to participate
in making this easier for linux users in general.
Right now, I've been looking at this particular area, and I'm trying to
find out what the problems are, which problems are solved, and if there
are any problems that are not solved.
Maybe this Wiki article could be helpful:
http://wiki.linuxmusicians.com/doku.php?id=system_configuration
Best,
Jeremy
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
2:55 p.m.
Hi Kaj,
On 05/07/2012 02:06 PM, Kaj Ailomaa wrote:
I understand that the rtirq script is designed to
raise rtprio for audio
devices,
It is designed to prioritize tasklet threads (here: the bottom half of
any IRQ handler). By default rtirq increases the priority of timer and
audio-device irq-handlers, but it can be configured to do favor any device.
which is made possible on the vanilla kernel since
2.6.39(?),
yes. 2.6.39.
if passing the threadirqs option to the kernel at
boot, and having built
it with the CONFIG_FORCE_THREADIRQ.
Correct for vanilla Linux.
With linux >= 3.0 and the preemt-RT patch, you don't need the
'threadirq' option with CONFIG_FORCE_THREADIRQ=y:
http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux-2.6/debian/patche…
From my experience, I have not had any performance
boost using the rtirq
script, but I have read about it helping those who are getting xruns due
to irq sharing.
There won't be any performance boost. In general performance decreases
(minimum and average latency increases) but reliability increases (max
latency decreases).
So, I'm wondering. What picture do others have of
the benefit of the
rtirq script?
Rui's rtirq script is great: a simple tool to tune your system for
reliable audio work.
..and are there other ways to measure improvement for
audio operation
other than spotting xruns at different latency settings,
Not really. The overall complexity of the system is vast. unit-testing
is not really an option for sound.
Put some load your system and do some usual [audio] work, keep the
system running for a few hours/days and see if there are still no x-runs..
and reading the
rtprio for various devices using the 'ps' command?
That's only helpful to debug the rtirq script or its config. It does not
measure anything.
There's kernel tracers but most of these will interfere with the
measurement. There's also the rt-test-suite:
https://github.com/clrkwllms/rt-tests
cyclictest -t1 -p 80 -n -i 1000 -l 10000 -m
will benchmark min, max and avg latency of your system, although you
should probably run it longer than 10000 iterations (here 10sec: 10000
iterations * 1000 us). It that does not directly relate to IRQ priority.
HTH,
robin
8 May
8 May
12:14 p.m.
On Mon, 2012-05-07 at 14:54 +0200, Robin Gareus wrote:
With linux >= 3.0 and the preemt-RT patch, you
don't need the
'threadirq' option with CONFIG_FORCE_THREADIRQ=y:
http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux-2.6/debian/patche…
So when I build a kernel-rt ex 3.0 from kernel.org source I need to use
boot option threadirqs, if it isn't patched?
On AV Linux I run the 3.0.23-avl-7-pae with and the self-build
3.0.23-rt40 without threadirqs. This way there's no difference between
those kernels. I can't make music using JACK1 (didn't test JACK2 until
now with AV Linux).
But at least kernel-rt < 2.6.39 are ok without threadirqs ;)?
But CONFIG_IRQ_FORCED_THREADING has to be set for a kernel-rt too?
spinymouse@precise:~$ grep FORCE /media/avlinux/boot/config-3.0.23-rt40
CONFIG_IRQ_FORCED_THREADING=y
Regards,
Ralf
3:11 p.m.
Hi Ralf,
On 05/08/2012 12:14 PM, Ralf Mardorf wrote:
On Mon, 2012-05-07 at 14:54 +0200, Robin Gareus
wrote:
> With linux >= 3.0 and the preemt-RT patch, you don't need the
> 'threadirq' option with CONFIG_FORCE_THREADIRQ=y:
OOPS. Sorry about the typos above. That should have been 'PREEMPT_RT',
'threadirqs' and 'CONFIG_IRQ_FORCED_THREADING'.
So when I build a kernel-rt ex 3.0 from kernel.org source I need to use
boot option threadirqs, if it isn't patched?
What is "kernel-rt ex 3.0" ??
https://www.kernel.org/pub/linux/kernel/projects/rt/3.[024] includes
that patch. It's not debian specific but part of Thomas Gleixner's
PREEMPT_RT patch. (It's just that debian's SCM viewer is the only one I
know that allows to read the [PREEMT_RT split quilt queue] patches in a
browser.)
On AV Linux I run the 3.0.23-avl-7-pae with and the
self-build
3.0.23-rt40 without threadirqs. This way there's no difference between
those kernels. I can't make music using JACK1 (didn't test JACK2 until
now with AV Linux).
But at least kernel-rt < 2.6.39 are ok without threadirqs ;)?
Correct. IIRC the 'threadirq' option was introduced in vanilla 2.6.39
when a large part of the tasklet-threading code was merged into Linus'
tree. This option was not present for linux-kernels (incl PREEMPT_RT
patched kernels) before 2.6.39.
But CONFIG_IRQ_FORCED_THREADING has to be set for a
kernel-rt too?
You don't really have no choice:
When you configure your kernel with the PREEMPT_RT patch,
PREEMPT_RT_FULL depends on CONFIG_IRQ_FORCED_THREADING and forces it
anyway (PREEMPT_RT_BASE does not).
spinymouse@precise:~$ grep FORCE
/media/avlinux/boot/config-3.0.23-rt40
CONFIG_IRQ_FORCED_THREADING=y
If you compile a recent kernel (>=3.0) with the PREEMPT_RT patch and set
"CONFIG_IRQ_FORCED_THREADING=y", the boot-option 'threadirqs' is
implied
and using it makes no difference.
ciao,
robin
3:57 p.m.
Hi Robin :)
On Tue, 2012-05-08 at 15:11 +0200, Robin Gareus wrote:
What is "kernel-rt ex 3.0" ??
"ex" (in German "ab") is for ">=", sorry if I'm wrong
with this
translation ;).
If you compile a recent kernel (>=3.0) with the
PREEMPT_RT patch and set
"CONFIG_IRQ_FORCED_THREADING=y", the boot-option 'threadirqs' is
implied
and using it makes no difference.
So patch-3.0.23-rt40 already includes it? I don't need to patch the
patch?
Regards,
Ralf
4:04 p.m.
On 05/08/2012 03:56 PM, Ralf Mardorf wrote:
I don't know, but I expect so. UTSL. patch-3.0.30-rt50 does include it.
Cheers!
robin
Hi Robin :)
On Tue, 2012-05-08 at 15:11 +0200, Robin Gareus wrote:
right, until you start thinking about your *ex*-girlfriend :)
I think "ex" means ">" not ">=". (in German /ex/:
"von" - not "ab").
What is "kernel-rt ex 3.0" ??
"ex" (in German "ab") is for ">=", sorry if I'm
wrong with this
translation ;). If you compile
a recent kernel (>=3.0) with the PREEMPT_RT patch and set
"CONFIG_IRQ_FORCED_THREADING=y", the boot-option 'threadirqs' is
implied
and using it makes no difference.
So patch-3.0.23-rt40 already includes it? I don't need to patch the
patch?
4584
days inactive
4585
days old
linux-audio-user@lists.linuxaudio.org
13 comments
4 participants
participants (4)
-
Jeremy Jongepier -
Kaj Ailomaa -
Ralf Mardorf -
Robin Gareus