Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Jul 11 2002 - 14:46:39 EEST
> 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.
But why is this needed? The only valid argument I heard for this is
optimization of frequency domain algorithm latency. I suggested a
capability interface for JACK as in EASI where it is possible to ask
whether nframes is constant. The application must still handle the case
where it is not.
> Of course with no locking involved,
> there\'s no need for priority inheritance.
That\'s right.
> 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.
If the FIFO uses a mutex, it should use some priority inversion prevention
mechanism, unless both threads run at the same priority. Otherwise there
is a potential unbounded block on the mutex.
> 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.
If the threads run at the same priority, then 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).
This is not true. There is hardware that runs with variable sample rate. This
can be used for sync to tape. (The hardware I know that supports this does
generate interrupts on a constant number of samples though)
> Either the
> software continuously polls the audio hw buffers (not really an option) or
> is waken up periodically using interrupts.
There is hardware that just interrupts at a constant rate. With this hardware
the frames that or ready isn\'t exactly constant. You might assume some value,
but if it isn\'t exactly correct then you\'ll drift.
> And nframes should be equal to
> the period size.
This hardware doesn\'t have a period size in samples, but time based. And so I
think it is wrong to have the driver export an interface that is not used
by the hardware.
And besides that, I\'m pretty sure there is hardware that doesn\'t use power
of
2 sized periods. Should that be a requirment too?
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Thu Jul 11 2002 - 14:49:39 EEST