Re: bsepcmdevice-jack.cc (Re: Beast Jack driver)

[Tim Janik <timj gtk org>]

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:

great!

> > 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:
>
>  http://permalink.gmane.org/gmane.linux.audio.devel/11725
>
> 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:
  http://lac.zkm.de/2006/papers/lac2006_lee_revell.pdf
  (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.

exactly! ;)
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.

[...]

>   Cu... Stefan

---
ciaoTJ