Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Paul Davis (pbd_AT_op.net)
Date: Thu Jul 11 2002 - 01:55:08 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.
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.
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.
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. even video isn't this demanding: if
you don't get to update the framebuffer in time, you just get the last
frame repeated, which probably doesn't look *so* bad. with audio, if
you miss the deadline, it sounds horrible.
--p
This archive was generated by hypermail 2b28 : Thu Jul 11 2002 - 02:00:53 EEST