On Wed, May 12, 2010 at 11:16 PM, Mark Brown <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Wed, May 12, 2010 at 08:50:42AM -0500, pl bossart wrote: > >> This might be almost equivalent to the timer approach in terms of # of >> wakeups, however the timer can be reprogrammed on-the-fly whereas >> periods can only be changed by closing and reopening the device. You >> can also adjust the timer shall underflows occur. And the timer slack >> lets the kernel group events. Not to mention that you will need > > The timer is also useful for allowing PulseAudio to dynamically adjust > the period size as the runtime situation changes - if you're running > high latency streams and have a low latency application start up then > PulseAudio can just change the timer to get more frequent events. AFAIU, the only issue is lack of ability to fine-tune period size of DMA runtime. Otherwise, for the requirement, having period-size almost equal to ring-buffer serves better than disabling interrupts and using timer based updating, more so for VMs with inaccurate timer source. Then I think, rather then providing a way to disable hw-intr, we'd better provide a way to modify runtime period-size at DMA Driver level, and snd_pcm_period_elapsed seems already capable to handle that. That way, disabled interrupts would just be a special case with period-size := ULONG_MAX. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
