[alsa-devel] [PATCH V1 11/11] ASoC: DaVinci: pcm, fix underruns by using sram
troy.kisky at boundarydevices.com
Tue Jul 7 21:07:10 CEST 2009
Mark Brown wrote:
>>> battery life by setting up very big DMAs. On a similar vein is it worth
>>> considering making this feature entirely optional and/or falling back to
>>> non-SRAM if SRAM allocation fails?
>> Yes Chris Ring also asked for that, and it is fairly easy to allocate another
>> SDRAM buffer to use for the SRAM. But I'd rather another patch after this
> Incremental patches sounds fine to me.
>> if I need to use plaform data. Maybe audio_sram_buffer_size = 0 in platform
>> data to mean use SDRAM?
> The only potential problem I see there is that that'd make disabling the
> SDRAM the default. I guess if people have been living without it so far
> that's not a big problem, though, and it'll stop people getting surprised
> by audio grabbing SDRAM when they weren't expecting it.
> I guess if you're using SDRAM there's no need for the double buffering
> (though that could be a third patch)?
Even when using SDRAM, there is still another advantage to double buffering.
That is tolerating very long interrupt latency on dma completion. The current
code sets up the next periods dma transfer on dma completion. This could easily
lead to underruns. So, even in this case, I think double buffering is worth
the extra dma engine copy.
More information about the Alsa-devel