[linux-audio-dev] Linux kernel HZ,
audio latency and how to measure?
paul at linuxaudiosystems.com
Sat Aug 19 08:26:56 EDT 2006
On Sat, 2006-08-19 at 05:16 -0700, Stephen Cameron wrote:
> 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.)
> I'm not familiar with audio drivers, but is that strictly correct?
well, not precisely, but lee was trying to make a point.
> I am familiar with storage drivers (e.g. cciss) and there, interrupts
> happen when DMA transfers complete. At that time, the driver _may_
audio h/w interrupts not when a transfer is complete, but when more data
is required/available to keep the buffer used by the h/w full/empty
(depending on whether we are talking about playback or capture).
> say, "as long as I'm down here in the driver, let me check if there's
> more work to do and set up some additional dma transfer(s) before the
> interrupt handler returns," but it doesn't _have_ to do that, excepting
> unplugging the stream of requests from the OS in case the board was too
> busy on last submission and i/o got plugged.)
well of course, but storage drivers have no real time streaming
characteristics, so whether the driver does that or something else is
largely irrelevant - there is plenty of *time*. with audio, there are RT
deadlines for reading/writing the data.
> The only data gotten from the board in the interrupt handler is
> typically a tag (or tags) that tells _which_ of many previously
> initiated DMA transfers have completed.
audio is not so different, except that the RT deadlines mean that the
work that must follow an interrupt must follow it before the next
interrupt arrives. this means that after the interrupt comes in and a
small amount of housekeeping is done by the interrupt handler, the
application must be running ASAP.
> the OS code that they have completed, so that layer can, among other things,
> wake up processes waiting for that i/o... the data isn't copied
> to userspace by the driver (usually), but by some upper layer of
> the OS (assuming O_DIRECT isn't used. If it is, the DMA goes right
> to/from userspace directly.)
applications that use JACK or a JACK-like approach mmap the buffer used
by the hardware, and therefore data transfer is similarly direct between
h/w and userspace. older applications that use read/write models require
extra data copying and are generally (not always, but generally) not
structured appropriately for low latency.
More information about the linux-audio-dev