29 May
2003
29 May
'03
5:24 p.m.
Has anyone done any low-latency audio testing with the new native pthread
implementation (comes with rh9.0 at least)...?
I was just reading through [1] and noticed the following (in section 8):
""Realtime support is mostly missing from the library implementation. The
system calls to select scheduling parameters are available but they have
no effects. The reason for this is that large parts of the kernel do not
follow the rules for realtime scheduling. Waking one of the threads
waiting for a futex is not done by looking at the priorities of the
waiters.""
If I've understood right, SCHED_FIFO semantics do not have any meaning
between threads of one process if NPTL is used! Hopefully this is right,
as it would cause quite a lot of problems (GUIs and disk i/o threads can
freely block audio processing even though using SCHED_FIFO). :(
[1] http://people.redhat.com/drepper/nptl-design.pdf
--
http://www.eca.cx
Audio software for Linux!
29 May
29 May
8:27 p.m.
Has anyone done any low-latency audio testing with the
new native pthread
implementation (comes with rh9.0 at least)...?
I was just reading through [1] and noticed the following (in section 8):
""Realtime support is mostly missing from the library implementation. The
system calls to select scheduling parameters are available but they have
no effects. The reason for this is that large parts of the kernel do not
follow the rules for realtime scheduling. Waking one of the threads
waiting for a futex is not done by looking at the priorities of the
waiters.""
If I've understood right, SCHED_FIFO semantics do not have any meaning
between threads of one process if NPTL is used! Hopefully this is right,
as it would cause quite a lot of problems (GUIs and disk i/o threads can
freely block audio processing even though using SCHED_FIFO). :(
[1] http://people.redhat.com/drepper/nptl-design.pdf
i just told penguin computing that i could not buy a machine from them
if it came with RH9. ulrich (drepper) is wrong to say "large parts of
the kernel", he is right to say "significant parts of the kernel". i
hope that linus will not release 2.6 until this is fixed. we need to
find the right place to speak loudly about this issue.
otoh, look on the bright side. i suspect that ulrich is saying that
SCHED_FIFO is not *necessarily* obeyed, in that if more than 1 thread
is waiting on a futex, the futex code will not ensure that its the
SCHED_FIFO one (or the highest priority one in general) that is
woken. however, if you're using futexes for 1:1 communication
(typical), then this shouldn't matter. in the case of JACK, for
example, its always 1:1, and i think this would be true for
audio<->disk i/o thread communication too.
what would be *really* bad is if they actually changed the code so
that attempts to set SCHED_FIFO are not honored because they believe
they are useless. i don't know which of these is true.
--p
30 May
30 May
6:40 a.m.
On Thu, May 29, 2003 at 06:20:34 -0400, Paul Davis wrote:
what would be *really* bad is if they actually changed
the code so
that attempts to set SCHED_FIFO are not honored because they believe
they are useless. i don't know which of these is true.
My main dev machien is RH9 and I haven't noticed any problems, OTOH it has
a lousy soundcard (block size of 1024 min), so it might he harder to spot.
There are plenty of peopel running RH9 here, and people like to complain
abut thier latency performance ;) I guess it could be subtle though.
- Steve
7839
days inactive
7840
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
3 participants
participants (3)
-
Kai Vehmanen -
Paul Davis -
Steve Harris