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.
