On Mon, 17 May 2010, pl bossart wrote:
- 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@perex.cz Linux Kernel Sound Maintainer ALSA Project, Red Hat, Inc.