3 Oct
2007
3 Oct
'07
8:46 p.m.
Florian Schmidt:
You don't need a lowlatency kernel to be able to set CONFIG_HZ to 1000.
Its just the default value in vanilla which is 250Hz, but you can set it
to 1000 if you want to.
Generally we
have two kinds of kernels: The "vanilla" kernel as
downloadable on kernel.org and the same kernel, but patched with Ingo
Molnars RT-patches. The vanilla kernel, if configured properly with
CONFIG_PREEMPT etc., already gives very good performance in the low
latency department, enough for many users, even audio users. I run one
of these.
Well, the vanilla kernel also has a CONFIG_HZ setting of i think 200hz per
default. This is too little timing resolution for processes that rely on the
system timer frequency being higher [some sequencers come to mind]..
The "lowlatency" kernel in ubuntu thus has CONFIG_HZ set to 1000 and
CONFIG_PREEMPT enabled.
This might be good enough for some people..
For a truly reliable system (where you can count on no audio period being
missed because you forgot to disable the damn updatedb cronjob) you need a
system patched with ingo's realtime preemption patches and have it properly
configured.
Hasn't this been fixed a long time ago? Its true that you were required to
have a realtime kernel when using linux 2.4 to avoid dropouts for cronjobs
etc., and in practice you probably also couldn't get reliable realtime
performance with old versions of 2.6. But I thought it shouldn't be like
that anymore? At least I haven't had any dropouts with my vanilla 2.6
kernel as long as I've used it.
3 Oct
3 Oct
10:14 p.m.
New subject: difference between realtime-kernel and low-latency-kernel?
On Thursday 04 October 2007, Kjetil S. Matheussen wrote:
Well, with a vanilla kernel you simply don't get the fine grained control over
what code gets the cpu at what times as with a realtime-preemption kernel..
It is true that for many people a vanilla kernel with CONFIG_PREEMPT and
CONFIG_HZ=1000 delivers great performance, probably even better than
a "lowlatency" 2.4.x kernel. But basically one badly behaving kernel driver
might cause delay, so for differing people the results differ. With a -rt
kernel you would just give this device a nice and low prio, so it doesn't
even get a chance to disturb the soundcard/jack..
This goes as far that if one sees an xrun while running a properly
setup -rt-kernel one knows it's an application bug or a soundcard driver
bug ;) The kernel itself or any userland processes (X, cronjobs, whatever) as
a source of timing problems are pretty much eliminated.
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
For a truly
reliable system (where you can count on no audio period being
missed because you forgot to disable the damn updatedb cronjob) you need
a system patched with ingo's realtime preemption patches and have it
properly configured.
Hasn't this been fixed a long time ago? Its true that you were required to
have a realtime kernel when using linux 2.4 to avoid dropouts for cronjobs
etc., and in practice you probably also couldn't get reliable realtime
performance with old versions of 2.6. But I thought it shouldn't be like
that anymore? At least I haven't had any dropouts with my vanilla 2.6
kernel as long as I've used it. 
4 Oct
4 Oct
4:41 a.m.
New subject: difference between realtime-kernel and low-latency-kernel?
On 10/4/07, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
Well, with a vanilla kernel you simply don't get the fine grained control
over
what code gets the cpu at what times as with a realtime-preemption
kernel..
It is true that for many people a vanilla kernel with CONFIG_PREEMPT and
CONFIG_HZ=1000 delivers great performance, probably even better than
a "lowlatency" 2.4.x kernel. But basically one badly behaving kernel
driver
might cause delay, so for differing people the results differ. With a -rt
kernel you would just give this device a nice and low prio, so it doesn't
even get a chance to disturb the soundcard/jack..
I'm a big fan of my rt-patched kernel; I'm also a big fan of taking out most
of the distro's default stuff from the kernel. One of these days I will
compile an rt kernel with no network support even - my soundcard shares an
IRQ with eth1, I don't know if this will help or not.
But isn't it a nice and high prio? As in, the chrt prio? I understood this
as different from the nice prio, no? I may not be doing it correctly. I
set my soundcard IRQ to something like 70, jackd to something like 65, and
Pd to something like 60. The Pd GUI I set a little lower yet. Do I also
have to renice these apps?
This goes as far that if one sees an xrun while running a properly
setup -rt-kernel one knows it's an application bug
or a soundcard driver
bug ;) The kernel itself or any userland processes (X, cronjobs, whatever)
as
a source of timing problems are pretty much eliminated.
I get visible xruns but not audible so far. I am guessing I have the wrong
buffer sizes between Pd, Csound, and jackd...
-Chuckk
--
http://www.badmuthahubbard.com
6:30 a.m.
New subject: difference between realtime-kernel and low-latency-kernel?
On Thursday 04 October 2007, Chuckk Hubbard wrote:
Well forget the word "nice" in that sentence. It has nothing to do with nice
levels :) Nice levels are only relevant for SCHED_OTHER processes. Anyways,
if your e.g. hd controller device disturbs your audio device make sure you
give the audio device a high prio and the controller device a low prio. That
was what i meant..
And yes, i consider it a bug that top and other software report the SCHED_FIFO
prio as negative values. Where does that come from? Does the prio already get
listed as negative in /proc? Or do they simply do it to separate the
SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX speaks of positive
SCHED_FIFO prios in the range 1..99 afaik..
Well, with a
vanilla kernel you simply don't get the fine grained control
over
what code gets the cpu at what times as with a realtime-preemption
kernel..
It is true that for many people a vanilla kernel with CONFIG_PREEMPT and
CONFIG_HZ=1000 delivers great performance, probably even better than
a "lowlatency" 2.4.x kernel. But basically one badly behaving kernel
driver
might cause delay, so for differing people the results differ. With a -rt
kernel you would just give this device a nice and low prio, so it doesn't
even get a chance to disturb the soundcard/jack..
I'm a big fan of my rt-patched kernel; I'm also a big fan of taking out
most of the distro's default stuff from the kernel. One of these days I
will compile an rt kernel with no network support even - my soundcard
shares an IRQ with eth1, I don't know if this will help or not.
But isn't it a nice and high prio? As in, the chrt prio? I understood
this as different from the nice prio, no? I may not be doing it correctly.
I set my soundcard IRQ to something like 70, jackd to something like 65,
and Pd to something like 60. The Pd GUI I set a little lower yet. Do I
also have to renice these apps? I get visible xruns but not audible so far. I am
guessing I have the wrong
buffer sizes between Pd, Csound, and jackd...
No, i don't think so. If you use Pd and CSound as jack apps, then jack tells
them what buffer size to use. If one of these used the wrong size you would
definitely hear it..
Start jack and run this script and tell us the output please:
http://tapas.affenbande.org/rt-setup-report.sh
Thanks,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
8:27 a.m.
New subject: difference between realtime-kernel and low-latency-kernel?
Hi,
On Thu, Oct 04, 2007 at 10:29:56AM +0200, Florian Schmidt wrote:
[...]
And yes, i consider it a bug that top and other software report the SCHED_FIFO
prio as negative values. Where does that come from? Does the prio already get
listed as negative in /proc? Or do they simply do it to separate the
SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX speaks of positive
SCHED_FIFO prios in the range 1..99 afaik..
Hmmm, POSIX talks about priorities in the range of
min .. max,
where
min = sched_get_priority_min(alg)
max = sched_get_priority_max(alg)
max - min >= 32, if alg == SCHED_FIFO or alg == SCHED_RR
and alg being the the scheduling algorithm (like SCHED_FIFO, ...)
Under Linux (according to 'man sched_get_priority_min') the follwoing
ranges apply:
SCHED_FIFO : min = 1, max = 99
SCHED_RR : min = 1, max = 99
SCHED_OTHER : min = 0, max = 0
jm5c,
Yours,
Jacob
I get visible xruns but not audible so far. I am
guessing I have the wrong
buffer sizes between Pd, Csound, and jackd...
No, i don't think so. If you use Pd and CSound as jack apps, then jack tells
them what buffer size to use. If one of these used the wrong size you would
definitely hear it..
Start jack and run this script and tell us the output please:
http://tapas.affenbande.org/rt-setup-report.sh
Thanks,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-user
10:33 a.m.
New subject: difference between realtime-kernel and low-latency-kernel?
On Thursday 04 October 2007, Jacob wrote:
Hi,
On Thu, Oct 04, 2007 at 10:29:56AM +0200, Florian Schmidt wrote:
Ok thanks for clearing this up :) So in principle there actually even might be
partially (or only) negative prios for SCHED_FIFO processes.
Thanks,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
[...]
And yes, i consider it a bug that top and other software report the
SCHED_FIFO prio as negative values. Where does that come from? Does the
prio already get listed as negative in /proc? Or do they simply do it to
separate the SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX
speaks of positive SCHED_FIFO prios in the range 1..99 afaik..
Hmmm, POSIX talks about priorities in the range of
min .. max,
where
min = sched_get_priority_min(alg)
max = sched_get_priority_max(alg)
max - min >= 32, if alg == SCHED_FIFO or alg == SCHED_RR
and alg being the the scheduling algorithm (like SCHED_FIFO, ...)
Under Linux (according to 'man sched_get_priority_min') the follwoing
ranges apply:
SCHED_FIFO : min = 1, max = 99
SCHED_RR : min = 1, max = 99
SCHED_OTHER : min = 0, max = 0
11 a.m.
New subject: difference between realtime-kernel and low-latency-kernel?
On Thu, Oct 04, 2007 at 02:33:29PM +0200, Florian Schmidt wrote:
On Thursday 04 October 2007, Jacob wrote:
I've wondered about this too. I haven't found anything in the Web and in
my (rather old) copy of O'Reillys "POSIX.4" book
explicitely requiering a positive value (ok, I only searched for 15 minutes),
and I do not have a copy of the current spec. But since
sched_get_priority_min/max(alg) return -1 if alg is invalid, I wouldn't
expect it.
Maybe someone with access to the current spec could clarify this? ;-)
Jacob
Hi,
On Thu, Oct 04, 2007 at 10:29:56AM +0200, Florian Schmidt wrote:
Ok thanks for clearing this up :) So in principle there actually even might be
partially (or only) negative prios for SCHED_FIFO processes. [...]
And yes, i consider it a bug that top and other software report the
SCHED_FIFO prio as negative values. Where does that come from? Does the
prio already get listed as negative in /proc? Or do they simply do it to
separate the SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX
speaks of positive SCHED_FIFO prios in the range 1..99 afaik..
Hmmm, POSIX talks about priorities in the range of
min .. max,
where
min = sched_get_priority_min(alg)
max = sched_get_priority_max(alg)
max - min >= 32, if alg == SCHED_FIFO or alg == SCHED_RR
and alg being the the scheduling algorithm (like SCHED_FIFO, ...)
Under Linux (according to 'man sched_get_priority_min') the follwoing
ranges apply:
SCHED_FIFO : min = 1, max = 99
SCHED_RR : min = 1, max = 99
SCHED_OTHER : min = 0, max = 0
6 Oct
6 Oct
10:15 a.m.
New subject: difference between realtime-kernel and low-latency-kernel?
Hi Florian.
I understood nice to be an adjective, but I was questioning the word "low";
I see now you were referring to non-audio, so I understand.
I have two jackd scripts I use, one for Playback-only, and one for duplex
using my Zoom H4 mic. I have attached the scripts and their outputs from
your script. See anything I could improve?
Thanks.
-Chuckk
On 10/4/07, Florian Schmidt <mista.tapas(a)gmx.net> wrote:
On Thursday 04 October 2007, Chuckk Hubbard wrote:
correctly.
--
http://www.badmuthahubbard.com
> Well, with a vanilla kernel you simply
don't get the fine grained
control
> over
> what code gets the cpu at what times as with a realtime-preemption
> kernel..
>
> It is true that for many people a vanilla kernel with CONFIG_PREEMPT
and
> CONFIG_HZ=1000 delivers great performance,
probably even better than
> a "lowlatency" 2.4.x kernel. But basically one badly behaving kernel
> driver
> might cause delay, so for differing people the results differ. With a
-rt
> kernel you would just give this device a
nice and low prio, so it
doesn't
even get
a chance to disturb the soundcard/jack..
I'm a big fan of my rt-patched kernel; I'm also a big fan of taking out
most of the distro's default stuff from the kernel. One of these days I
will compile an rt kernel with no network support even - my soundcard
shares an IRQ with eth1, I don't know if this will help or not.
But isn't it a nice and high prio? As in, the chrt prio? I understood
this as different from the nice prio, no? I may not be doing it I set my soundcard IRQ to something like 70,
jackd to something like
65,
and Pd to something like 60. The Pd GUI I set a
little lower yet. Do I
also have to renice these apps?
Well forget the word "nice" in that sentence. It has nothing to do with
nice
levels :) Nice levels are only relevant for SCHED_OTHER processes.
Anyways,
if your e.g. hd controller device disturbs your audio device make sure you
give the audio device a high prio and the controller device a low prio.
That
was what i meant..
And yes, i consider it a bug that top and other software report the
SCHED_FIFO
prio as negative values. Where does that come from? Does the prio already
get
listed as negative in /proc? Or do they simply do it to separate the
SCHED_FIFO threads from SCHED_OTHER threads? Anyways POSIX speaks of
positive
SCHED_FIFO prios in the range 1..99 afaik..
I get visible xruns but not audible so far. I am
guessing I have the
wrong
buffer sizes between Pd, Csound, and jackd...
No, i don't think so. If you use Pd and CSound as jack apps, then jack
tells
them what buffer size to use. If one of these used the wrong size you
would
definitely hear it..
Start jack and run this script and tell us the output please:
http://tapas.affenbande.org/rt-setup-report.sh
Thanks,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
6286
days inactive
6289
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Chuckk Hubbard -
Florian Schmidt -
Jacob -
Kjetil S. Matheussen