Re: [linux-audio-dev] priority inversion & inheritance

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Kai Vehmanen (kai.vehmanen_AT_wakkanet.fi)
Date: Thu Jul 11 2002 - 13:14:19 EEST


On Thu, 11 Jul 2002, Martijn Sipkema wrote:

> I agree with you that the only real solution is to rewrite the application.
> Still, as others said that was not going to happen, the mentioned solution
> will work as long as the hardware period size isn\'t too different from the
> number of samples the application processes per read/write. I mentioned
> this before because I did not think these (read/write) applications are
> a good reason to have the process() callback use a constant nframes (during
> jackd lifetime).

There're two separate problems here. Constant nframes might be required
even if the application supports engine iteration from outside sources
(ie. all audio processing happens inside the process() callback).
Ecasound is one example of this. Of course with no locking involved,
there's no need for priority inheritance.

A different problem is apps that have their own loop based on blocking
read/write ops or driven by select/poll. In this case the easiest way to
add JACK support is to put a FIFO between the engine and the process()
callbacks. Although priority inheritance could be used here, it's doesn't
buy as much.

First of all, due to the extra context switch involved, this approach just
is not efficient. Secondly, the application loop must still be
deterministic (to avoid missing deadlines caused by blocking on paging or
disk i/o) and there's thus no reason to run it without SCHED_FIFO. In
other words priority inheritance is not needed.

> Again, I agree with you. That\'s also why I am against a constant nframes,
> because there is hardware that really doesn\'t want nframes constant.

What hardware? You've mentioned this quite a few times on jackit-devel,
but so far without examples. D/A or D/A hardware always runs at a constant
speed (at least I haven't heard about variable rate sampling). Either the
software continuously polls the audio hw buffers (not really an option) or
is waken up periodically using interrupts. And nframes should be equal to
the period size.

--
 http://www.eca.cx
 Audio software for Linux!


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Thu Jul 11 2002 - 13:55:11 EEST