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

From: James Courtier-Dutton <James@email-addr-hidden>
Date: Sun Aug 20 2006 - 00:42:41 EEST

Paul Davis wrote:
> 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).
>

Paul has it right. I will explain how the audio transfer works on
Creative Sound cards, as I know about them, but I assume most sound
cards are the same.
During setup of the buffer, one configures a number of periods. On
Creative cards, one can have anything from 2 to 8 periods per buffer.
The sound card hardware has a pointer identifying where the DAC is
currently playing samples from. At each period boundary and interrupt is
 triggered. The stream of DMA transfers is simply started, then keeps
running automatically until commanded to stop. Each DMA transfer is 64
bytes, so there are normally multiple DMA transactions between each
interrupt.

James
Received on Sun Aug 20 04:15:02 2006

This archive was generated by hypermail 2.1.8 : Sun Aug 20 2006 - 04:15:02 EEST