Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Jul 11 2002 - 11:51:50 EEST
> >An examples situation for using priority inheritance
> >might be porting a read/write audio i/o application to a
> >callback based interface without too much effort. This can\\\\\\\'t in the
> >general case be done without adding latency, if there is no blocking
> >allowed in the callback function. But why not block? It takes time
>
> because the main reason for doing this is that the r/w app expects to
> be able to generate N1 samples at a time, whereas the callback wants
> only N2, and N1>N2. so when you block-to-get-r/w-thread-to-run, you
> run the r/w-thread for long enough to generate N1 samples. this
> instantly violates real-time constraints based on N2.
That\'s true. This hasn\'t got to do with using a mutex in the process()
callback though.
> if the code was willing to generate any number of samples at a time,
> and write them in any sized chunk, then there would be no need for
> such a hack.
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).
> it therefore doesn\'t solve the underlying problem:
>
> * a device driver API that was written to hide the real-time
> nature of the device behind the Unix open/read/write/close model
> * an application that used the API.
> * a desire to run the application in a low latency environment.
The latency of these applications can never be lower as the N1 (from above)
anyway. But on some of these applications N1 might be set very small at
compile time. N1 < N2 isn\'t really a problem.
It\'s best to just rewrite these applications to support a callback based
audio i/o api natively though. There will always be other uses of
priority inheritance :)
> its the API that is central here. you\'ve got a device that absolutely
> wants a certain amount of data read and/or written every N
> msecs. creating an API that allows the app to pretend this is not true
> is the root of the problem, IMHO.
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.
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Thu Jul 11 2002 - 11:38:04 EEST