[linux-audio-dev] Linux kernel HZ, audio latency and how to measure?

Stephen Cameron smcameron at yahoo.com
Sat Aug 19 12:16:07 UTC 2006

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?

I am familiar with storage drivers (e.g. cciss) and there, interrupts
happen when DMA transfers complete.  At that time, the driver _may_
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.)

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.  The tag may or may not
be gotten via DMA, often it's a memory mapped register on the board,
and it's retrieved via readl(), etc, though if the board is coalescing
completions and delivering a pile of tags with one interrupt, _that_ would
have been done by a DMA, typically. The primary purpose of the
interrupt handler in the storage world is to figure out which previously
initiated DMA transfers have completed, and notify the upper levels of 
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.)

Probably audio drivers are different in some ways, due to the more 
sequential nature of typical i/o, and the need for low latency and 
keeping buffers from getting empty, general differences in how 
audio data vs. generic block i/o is used, etc?  Probably depends 
on the hardware too.  Still, I would expect an interrupt on DMA

Just wondering, (and I probably managed to get at least some of the
above wrong as well.)

-- steve

Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the Linux-audio-dev mailing list