Re: bsepcmdevice-jack.cc (Re: Beast Jack driver)
- From: Tim Janik <timj gtk org>
- To: Stefan Westerfeld <stefan space twc de>
- Cc: beast gnome org
- Subject: Re: bsepcmdevice-jack.cc (Re: Beast Jack driver)
- Date: Wed, 7 Jun 2006 01:34:13 +0200 (CEST)
On Tue, 6 Jun 2006, Stefan Westerfeld wrote:
On Mon, Jun 05, 2006 at 04:31:23AM +0200, Tim Janik wrote:
ok. note that beast doesn't 100% perfectly prevent priority inversion in
other scenarios either. this issue is slowly being worked on (the idea
is to move all communication to atomic ops guarded by BirnetGuard, but
that's an entire new thread ;)
However, these are two kinds of separate issues:
(1) priority inversion occuring within the jack realtime thread
(2) priority inversion occuring elsewhere in beast
When (1) is being triggered, the jackd server can get dropouts while
writing audio, and might decide that we are the client that is badly
implemented. So it might shutdown the connection we have, leaving the
other clients running.
When (2) is being triggered, we miss the opportunity to refill the
ringbuffer in time, so there will be a click in the output, but at least
the audio processing still continues; but we also may have still enough
data buffered in the rinbuffer, and nothing will happen; that will also
depend on how the user configured the beast latency.
So I am trying harder to avoid (1) than (2).
these consideraitons shouldn't be made without taking into account the
probability for priority inversion scenrios which is very close to 0
in practice. so this is an academic concern for the most part.
If beast would not be
likely to produce more underruns in (2) than in (1), we might as well
run the beast processing within the jack RT thread. But we don't and
thats good as it is.
I still agree with your concluding remarks, though, which are:
until then, the jack RT thread should use a pipe write() to notify the
engine and sequencer threads, which both create their own pipe fds that
they also poll() on.
After thinking some more about it, and also reading Paul's oppinion:
I think that pipe write() is probably ok for a solution running under
linux. Its simply that linux is no realtime operating system, and so
whatever we do in our case, we can get no guarantee that it will work in
100% of the cases.
with the recent low latency in linux kernels, it's starting to become a
very good pseudo realtime operating system:
(Realtime Audio vs. Linux 2.6 paper by Lee Revell)
So if this was an realtime airplane control software,
we should probably use some other operating systen.
i'm so glad you recognize we're _not_ coding realtime airplane control
software here which runs redundantly in 4 self monitoring processors ;)
However, for an audio software its probably enough if it works reliable
enough for daily music production, and it pipe writes should deliver
this degree of reliability.
yes, i'd hope so. if not it's time for filing a kernel bug.
] [Thread Prev