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 <pe...@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project, Red Hat, Inc.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
