On Wed, May 12, 2010 at 11:16 PM, Mark Brown broonie@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.