>>> 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? _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
