On Thu, May 10, 2012 at 10:30:44PM +0530, Jassi Brar wrote:
On Thu, May 10, 2012 at 9:36 PM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
The question is - what would cause ALSA to hammer away at the buffer like that - checking it every 16 or 8 DMA bytes transferred? I'm also seeing around 75% system CPU time, which really isn't good.
The above was captured while aplay was running, with no apparant audio corruption.
Any ideas?
I believe it's because the pcm's write tries to keep the data in ring buffer filled upto brim and keeps polling the dma position till it keeps reporting some progress.
I think if you could avoid that behavior if your driver carefully keeps negligible progresses to itself and report only considerable ones. Basically, core would stop polling and wait on queue when two pointer calls return same value i.e no progress.
You _could_ but why should drivers work around silly behaviour in the ALSA core?