21 Dec
2005
21 Dec
'05
noon
Hello all,
I'm a bit over my head here, so please be gentle :)
I've been working with Ubuntu 5.10 and trying to use it as an audio
machine. I have been learning about different approaches to getting a
multimedia kernel (low latency, etc.). In reading around the web, I
see that there are three general approaches:
1. Build your own kernel from scratch - too complicated for me at this time
2. Use the realtime_lsm module on an existing kernel - I've tried
this, but I read it's no longer supported in the kernel because of
#3...
3. Use rtlimits, which is already a part of the default kernel.
Last night I downloaded the set_rtlimits program and was able to get
jackd running with real time capabilities. I haven't done any
real-world work yet, so I don't know if my efforts were truly
successful. Here are my questions:
1. Is rtlimits all that I need for audio work? It seems way too
simple. I remember that people using 2.4 kernels had at least two
patches that had to be applied before the kernel was suitable for
audio work. If I use rtlimits, do I still need to build a kernel
with, for instance, the ck patches for a preemptable kernel?
2. Is anyone using rtlimits instead of realtime_lsm? Is there any
benefit to using one over the other, in terms of real-world audio
work?
3. Should I just break down and install DeMudi? :)
I hope my questions make sense. Please feel free to correct any
errors in my logic here, that is exactly what I am looking for - to
learn how to do things myself the right way.
Thanks!
Josh
--
Josh Lawrence
http://www.hardbop200.com
21 Dec
21 Dec
2:12 p.m.
1. Build your own kernel from scratch - too
complicated for me at
this time
It's easy if you know what to do ;-) .
I made the experience that learning how to build a kernel still is
useful these days, especially for audio stuff. Or using a well
preconfigured audio distribution.
2. Use the realtime_lsm module on an existing kernel
-
I've tried this, but I read it's no longer supported in the kernel
because of #3...
It's still supported and I run it on top of a recent 2.6.14.2 kernel.
Advantage: it's realtively simple to build and use. Usually you do not
need to rebuild a complete kernel, you only need to build that module
and load it.
OTOH, the RT-LSM module "only" makes it possible that non-root users get
access to realtime priviledges - it doesn't improve the latency of the
system itself, so...
3. Use rtlimits, which is already a part of the
default kernel.
...this is the right thing to do, I guess.
Last night I downloaded the set_rtlimits program and
was able to get
jackd running with real time capabilities. I haven't done any
real-world work yet, so I don't know if my efforts were truly
successful. Here are my questions:
1. Is rtlimits all that I need for audio work? It seems way too
simple. I remember that people using 2.4 kernels had at least two
patches that had to be applied before the kernel was suitable for
audio work. If I use rtlimits, do I still need to build a kernel
with, for instance, the ck patches for a preemptable kernel?
The default 2.6.14 kernel is much better for audio work than any kernel
before. If it is good enough for your work, why bother yourself with
kernel patching?
2. Is anyone using rtlimits instead of realtime_lsm?
Is there any
benefit to using one over the other, in terms of real-world audio
work?
3. Should I just break down and install DeMudi? :)
DeMuDi and Planet CCRMA are known to work out of the box for audio work,
that's what they are for ;-) .
I hope my questions make sense. Please feel free to
correct any
errors in my logic here, that is exactly what I am looking for - to
learn how to do things myself the right way.
You're welcome.
Best regards
ce
3:49 p.m.
On Wed, 21 Dec 2005 19:13:57 +0100
Christoph Eckert <ce(a)christeck.de> wrote:
Well, rtlimits doesn't do this either.
The mechanism to gain realtime privs and the worst case scheduling
latencies of the kernel are two completely different issues.
For the former, there's the realtime-lsm and rtlimits which _only_
enable a non root user to do what a root user could do anyways.
For the latter, there's the -rt kernels, although the vanilla kernels
are quite usable these days, too.
Well, it would be if the distributions supported this mechanism via the
usual PAM mechanism. As long as that is not given, a hack is needed, be
it either the realtime lsm or set_rtlimits.
2. Use the
realtime_lsm module on an existing kernel -
I've tried this, but I read it's no longer supported in the kernel
because of #3...
It's still supported and I run it on top of a recent 2.6.14.2 kernel.
Advantage: it's realtively simple to build and use. Usually you do not
need to rebuild a complete kernel, you only need to build that module
and load it.
OTOH, the RT-LSM module "only" makes it possible that non-root users get
access to realtime priviledges - it doesn't improve the latency of the
system itself, so... 3. Use
rtlimits, which is already a part of the default kernel.
...this is the right thing to do, I guess. The default 2.6.14 kernel is much better for audio
work than any kernel
before. If it is good enough for your work, why bother yourself with
kernel patching?
It is quite ok for most uses, especially when not going for ultra low
latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible
Kernel (Low-Latency Desktop)" setting though when building a vanilla
kernel (or make sure your distro builds it this way if you use a distro
provided kernel; check i.e. /proc/config.gz and/or write a mail to the
appropriate ML/maintainer).
Also the -rt kernel, due to prioritizing the irq handler threads,
provides better RT "guarantees" if you want to call it that ;) I.e.
given that the scheduler works correct, and that you have setup the
priorities in your system correctly (and that jackd ant the clients are
well behaving RT programs), there's almost _no way_ that other system
activity might cause delays that produce xruns in turn, even with
ridiculously low latencies.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
5:06 p.m.
On 12/21/05, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Well, rtlimits doesn't do this either.
The mechanism to gain realtime privs and the worst case scheduling
latencies of the kernel are two completely different issues.
For the former, there's the realtime-lsm and rtlimits which _only_
enable a non root user to do what a root user could do anyways.
For the latter, there's the -rt kernels, although the vanilla kernels
are quite usable these days, too.
I see, this is exactly the kind of thing I was looking for, and now
that I think about it, it makes total sense. Let me see if I
understand it: rtlimits allows a normal user to preempt, but you must
enable the preemption option in the kernel config in the first place
for it to do any good. Is that it?
It is quite ok for most uses, especially when not
going for ultra low
latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible
Kernel (Low-Latency Desktop)" setting though when building a vanilla
kernel (or make sure your distro builds it this way if you use a distro
provided kernel; check i.e. /proc/config.gz and/or write a mail to the
appropriate ML/maintainer).
Again, this is apparently the part that must be "enabled" to see the
full benefits of using rtlimits, correct? Once I've enabled this
option (Preemptible Kernel), do I then have what you are referring to
as a -rt kernel?
Also the -rt kernel, due to prioritizing the irq
handler threads,
provides better RT "guarantees" if you want to call it that ;) I.e.
given that the scheduler works correct, and that you have setup the
priorities in your system correctly (and that jackd ant the clients are
well behaving RT programs), there's almost _no way_ that other system
activity might cause delays that produce xruns in turn, even with
ridiculously low latencies.
I don't think that I am the type of user that needs that kind of low
latency, I just need enough to do my basic home recordings.
I think, in light of this, I might install DeMudi on my seperate
partition; it might avoid all of this kernel business very easily. I
still hate that I don't know how to do things myself, so any further
comment is welcome.
Thank you very much for your comments,
Josh
--
Josh Lawrence
http://www.hardbop200.com
6:24 p.m.
On Wed, 21 Dec 2005 15:06:18 -0600
Josh Lawrence <hardbop200(a)gmail.com> wrote:
Not quite. In a vanilla 2.6.14 kernel you can select from the following
preemption models:
( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
(X) Preemptible Kernel (Low-Latency Desktop)
So, if you use a vanilla kernel make sure the last entry is activated
(i.e. via make menuconfig)
In a kernel patched with the realtime preemption patches (-rt) you get
an additional entry:
(X) Complete Preemption (Real-Time)
This also introduces the prioritization of irq handler threads i talked
about. But before even considering using a -rt kernel, first test a
normal 2.6.14 vanilla kernel with "Preemptible Kernel (Low-Latency
Desktop)" enabled and of course,
[*] Preempt The Big Kernel Lock
too.
I see, this is exactly the kind of thing I was looking
for, and now
that I think about it, it makes total sense. Let me see if I
understand it: rtlimits allows a normal user to preempt, but you must
enable the preemption option in the kernel config in the first place
for it to do any good. Is that it?
rtlimits/realtime_lsm allows a normal user to run tasks with SCHED_FIFO
scheduling. This is a scheduling class that gets the CPU before any
normal SCHED_OTHER task and is statically prioritized (as opposed to
SCHED_OTHER where you can set a "nice" value, but the real priority is
determined based on some heuristics depending on resource usage of the
task). See i.e.
http://ccrma.stanford.edu/planetccrma/man/man2/sched_setscheduler.2.html
for a more detailed description.
It is quite ok
for most uses, especially when not going for ultra low
latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible
Kernel (Low-Latency Desktop)" setting though when building a vanilla
kernel (or make sure your distro builds it this way if you use a distro
provided kernel; check i.e. /proc/config.gz and/or write a mail to the
appropriate ML/maintainer).
Again, this is apparently the part that must be "enabled" to see the
full benefits of using rtlimits, correct? Once I've enabled this
option (Preemptible Kernel), do I then have what you are referring to
as a -rt kernel? I don't think that I am the type of user that
needs that kind of low
latency, I just need enough to do my basic home recordings.
I think, in light of this, I might install DeMudi on my seperate
partition; it might avoid all of this kernel business very easily. I
still hate that I don't know how to do things myself, so any further
comment is welcome.
Yeah, just for some hd recording and no i.e. using your computer as live
effects rack, i.e. for guitar or for softsynths, large periodsizes are
usually fine (large = around 1024 frames). For softsynths i'd recommend
a periodsize smaller than or equal to 128 frames. Dunno how well that
works on vanilla kernels. Especially if you need _rock solid_
performance (i.e. no dropouts at all).
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
9:29 p.m.
On Wednesday 21 December 2005 23:24, Florian Schmidt wrote:
(X) Complete Preemption (Real-Time)
This also introduces the prioritization of irq handler threads i talked
about.
Florian,
Is that to say that (cf. your tutorial,
http://tapas.affenbande.org/?page_id=6) reprioritizing IRQ handlers with
things like
chrt -f -p 97 `pidof "IRQ sound_car_irq"`
which prove so simple and efficient with an -rt kernel, are just pointless
with a preemptible kernel (assuming it was compiled with threaded IRQ
handlers)?
That'd confirm my recent measurements, but still i can scarcely make out why
this is so.
And while we're at it, i get --amazingly enough-- far more xruns when
un-threading my PCI sound card IRQ handler (doing echo 0 > /proc/irq/...)
than when leaving it threaded...
In any case, thank you for having written this tutorial. Laid out in a
perfectly clear way (from my point of view), and a really useful counterpart
to a kernel building tutorial.
Regards,
Syd
10:04 p.m.
On Thu, 22 Dec 2005 02:38:28 +0100
Sylvain Reynal <reynal(a)ensea.fr> wrote:
Hi,
Florian,
Is that to say that (cf. your tutorial,
http://tapas.affenbande.org/?page_id=6) reprioritizing IRQ handlers with
things like
chrt -f -p 97 `pidof "IRQ sound_car_irq"`
which prove so simple and efficient with an -rt kernel, are just pointless
with a preemptible kernel (assuming it was compiled with threaded IRQ
handlers)?
Which (compiling with threaded irq handlers) is only an option in a -rt
patched kernel. Vanilla doesn't have threaded IRQ handlers even in
"Preemptible Kernel" mode. Or so i seem to remember.
That'd confirm my recent measurements, but still i
can scarcely make out why
this is so.
I have no idea. I mostly only run Complete Preemption, which, when it
works, works great :) But from my understanding, unthreading the
soundcard IRQ handler or setting it to a high priority should be pretty
much equivalent from an enduser's point of view (Means: i have no clue,
but i bluntly assume). And at the time i actually used preemption modes
different from Complete Preemption for audio stuff, they were
equivalent.
And while we're at it, i get --amazingly enough--
far more xruns when
un-threading my PCI sound card IRQ handler (doing echo 0 > /proc/irq/...)
than when leaving it threaded...
Hmm, this is weird. I'm not sure. It would be best to ask Ingo directly
about this. Might be a regression.
Regards, Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6:40 p.m.
I
still hate that I don't know how to do things myself, so any further
comment is welcome.
I once had the idea that a kernel building tutorial would be great; I
stopped writing it due to some real life issues and due to the fact
that it changes day by day :) .
But anyway, I made the experience that building a kernel isn't a secret
science in any way if you know what to do, isn't it?
Maybe some day I'll have the time to finish the tutorial.
Best regards
ce
8 p.m.
Christoph Eckert wrote:
But anyway, I made the experience that building a
kernel isn't a secret science in any way if you
know what to do, isn't it?
..and esp. on debian (or ubuntu or demudi or 64Studio), it is still more simple
because of the make-kpkg script, see
http://www.us.debian.org/doc/manuals/reference/ch-kernel.en.html#s-kernel-d…
22 Dec
22 Dec
2:29 a.m.
Josh Lawrence wrote:
Hello all,
I'm a bit over my head here, so please be gentle :)
I've been working with Ubuntu 5.10 and trying to use it as an audio
machine. I have been learning about different approaches to getting a
multimedia kernel (low latency, etc.). In reading around the web, I
see that there are three general approaches:
1. Build your own kernel from scratch - too complicated for me at this time
2. Use the realtime_lsm module on an existing kernel - I've tried
this, but I read it's no longer supported in the kernel because of
#3...
3. Use rtlimits, which is already a part of the default kernel.
Last night I downloaded the set_rtlimits program and was able to get
jackd running with real time capabilities. I haven't done any
real-world work yet, so I don't know if my efforts were truly
successful. Here are my questions:
1. Is rtlimits all that I need for audio work? It seems way too
simple. I remember that people using 2.4 kernels had at least two
patches that had to be applied before the kernel was suitable for
audio work. If I use rtlimits, do I still need to build a kernel
with, for instance, the ck patches for a preemptable kernel?
2. Is anyone using rtlimits instead of realtime_lsm? Is there any
benefit to using one over the other, in terms of real-world audio
work?
3. Should I just break down and install DeMudi? :)
I hope my questions make sense. Please feel free to correct any
errors in my logic here, that is exactly what I am looking for - to
learn how to do things myself the right way.
Thanks!
Josh
--
Josh Lawrence
http://www.hardbop200.com
Hello,
This thread comes really handy to me. These last days I've been
comparing the performance of Ubuntu Breezy and Agnula 1.3.0-RC1. I've
been trying to get the grate support and user friendliness of Ubuntu
with an audio performance as good as an audio specialized distro. I
just finished compiling a 2.6.14 kernel in Ubuntu with the rt patch and
lsm module (this last one was quite easy to install using the
module-assistant and the realtime-lsm package from the Ubuntu
repositories). For some reason I found that the kernel in agnula
performs better than the one I compiled in Ubuntu even though both are
the same version, have complete preemption and use jack in realtime. In
agnula I can get very stable 2ms but in Ubuntu trying the same latency
fails with clicks in the audio related to the video activity (i.e.
maximizing and minimizing windows, or very active GUIs). In both I'm
using the latest nvidia drivers.
Until now I've been using Ubuntu with the stock 2.6.12.10 and the lsm
module and I'm quite surprised with the performance compared with the
previous version of Ubuntu (named Warty Warthog), I can get latencies as
low as 5ms almost completely stable but for Csound I have to set it to
11ms if I don't want to risk getting a sporadic click while recording a
performance in realtime. For my needs until now this has been enough.
Have you compiled the realtime-lsm module in Ubuntu using the stock
kernel? One aspect that I haven't understood completely is the setting
of priorities both in Jack and the IRQs. I've tried following the
instructions at the tapas web site using | chrt -f -p 99 `pidof |but I
can't notice any difference in the performance (using a complete
preemtion kernel).
If you want to keep trying with Ubuntu in the forums and wiki you can
find excellent how-tos about building kernels. I can post some links if
you are interested.
Good luck!
Hector.
10:19 a.m.
On Thursday 22 December 2005 07:29, Hector Centeno-Garcia wrote:
One aspect that I haven't understood completely is
the setting
of priorities both in Jack and the IRQs. I've tried following the
instructions at the tapas web site using | chrt -f -p 99 `pidof |but I
can't notice any difference in the performance (using a complete
preemtion kernel).
I've been fiddling with Ingo's 2.6.14-rt patches (kernel config, e.g.,
PREEMPT_DESKTOP vs PREMPT_RT, RCU prempt, etc., and then at run-time:
priorities, PCI bus latencies, threading/unthreading IRQ's, etc.) for a week
or so, trying them out on a small collection of hardware (intel AC'97,
Emu-APS, USB UA-25, freebob+FA-66 and firebox) and i've gotten baffling
results now and then. For the AC'97, for instance, rt-patched and non-patched
(yet preempted) kernels perform neck and neck (jackd with 32 frames/period
perfectly stable), while for other (esp. freebob) cards, a completely
preempted kernel eventually won out in an undisputable way (after tough
tweaking of IRQ's though!)... I've just started writing things out neatly and
i'm planning to release my whole set of measurements on line by next week,
for that matter.
But my general feeling so far is probably that of Florian: whenever complete
(i.e., PREMPT_RT) preemption works, it works real great, and it's definitely
worth giving it a try. Now, in view of the large set of possible low-latency
kernel/system parametrization, it comes as no surprise that experimenting is
more mandatory than ever...
Syd
12:53 p.m.
On Wednesday 21 December 2005 16:00, Josh Lawrence was like:
3. Should I just break down and install DeMudi? :)
Mmm, mmph, mmmmmph! ;)))
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
1:15 p.m.
On 12/22/05, tim hall <tech(a)glastonburymusic.org.uk> wrote:
On Wednesday 21 December 2005 16:00, Josh Lawrence was
like:
lol :) c'mon, just say it!!!
--
Josh Lawrence
http://www.hardbop200.com
3. Should I just break down and install DeMudi?
:)
Mmm, mmph, mmmmmph! ;)))
--
cheers,
tim hall
http://glastonburymusic.org.uk/tim
6914
days inactive
6915
days old
linux-audio-user@lists.linuxaudio.org
12 comments
7 participants
participants (7)
-
Christoph Eckert -
Florian Schmidt -
Hector Centeno-Garcia -
Hermann Vosseler -
Josh Lawrence -
Sylvain Reynal -
tim hall