On Wed, May 12, 2010 at 11:16 PM, Mark Brown <broo...@opensource.wolfsonmicro.com> 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. _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
