On Fri, 2006-08-18 at 20:39 -0400, Stephen Sinclair wrote:
> > Audio doesn't use setitimer()-driven sleeping. It's interrupt-driven,
> > not timer-driven.
>
> Yes, the driver is interrupt driven, but the driver interrupt handler
> is only responsible for getting the data off the card's FIFO and
> storing it in memory. (i.e., initialing a DMA transfer.) It doesn't
> do anything with the audio data itself, except pass it on to user
> space. Won't HZ make a difference to the user application code which
> must wake up to do something with this audio data? Hence the need for
> SCHED_FIFO and the like..
The user application code is woken up by the interrupt from the audio
interface, not from a timer firing - in addition to getting data from
the card and storing it in memory, the interrupt handler wakes up any
processes that are waiting on the audio data. So HZ is irrelevant.
SCHED_FIFO is needed because otherwise, if there are multiple runnable
processes when the audio interrupt fires, the kernel could decide to run
a different process. With SCHED_FIFO it must run the audio process.
Lee
Received on Sat Aug 19 04:15:17 2006
This archive was generated by hypermail 2.1.8 : Sat Aug 19 2006 - 04:15:18 EEST