[alsa-devel] [PATCH 1/3] add API to allow disabling period interrupts

[Jaroslav Kysela]

On Mon, 17 May 2010, pl bossart wrote:

>>>> 2) The avail_min parameter in sw_params was overlooked. The lowlevel
>>>>   drivers can use this value to compute the wake-up point and set hw
>>>>   appropriately, to do wake-up at requested time. We can add a support
>>>>   functions like "return how many samples are expected to be transferred
>>>>   for next wake-up point" to linux/sound/pcm.h. In case when this value
>>>>   is high, no interrupts (wake ups) will be processed in the driver. If
>>>>   hardware cannot do the precise transfers, we can program a system
>>>>   timer as the wake-up source.
>>>
>>> Isn't the interrupt-related behavior defined when you setup the DMA
>>> linked list. i.e when hw_params are frozen? The problem with sw_params
>>> is that they can change at any time, and the hardware may not support
>>> this. I have no idea how you would modify the HDAudio controller
>>> behavior dynamically for example.
>>
>> Look my last sentence - we should use another timing source like system
>> timer in this case.
>
> Sorry, I misunderstood what you meant by 'precise transfers'. If we
> use a system timer, we would need to keep track of the drift between
> audio clock and system time as PulseAudio does it. Would your proposal
> entail moving this interpolation code into the kernel and let
> PulseAudio only program avail_min?

I think that this is not job for the driver. The driver should just
obtain the current DMA position at the wake-up time and eventually store 
the monotonic clock for a drift handling in the user space. Note that 
even with IRQs, the actual DMA position can be delayed a bit (irq 
processing).

 						Jaroslav

-----
Jaroslav Kysela <perex at perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.