[alsa-devel] Query on Audio DMA using DMAEngine

[Mike Looijmans]

On 07/02/2013 02:13 PM, Mark Brown wrote:
> On Tue, Jul 02, 2013 at 07:50:16AM +0200, Mike Looijmans wrote:
>> On 07/02/2013 05:33 AM, Joel Fernandes wrote:
>
>> But even with much lower loads, I got underruns when recording to SD
>> card that I couldn't really explain. I noticed that the SD transfers
>> took up a lot of DMA params (about 40), so maybe that was just
>> causing too much work for the IRQ or DMA handler routines.
>
> SD cards are generally just slow, it's possible it's just not able to
> keep up with the data you're throwing at it.  Things like batching the
> writes up into large chunks can help here but you may just be hitting a
> genuine limit if you need to record for too long and don't have enough
> fast storage (like RAM) to buffer.

What i meant by "couldn't really explain" is that I monitored CPU, 
memory and IO, and could clearly conclude that the card (or network, or 
even /dev/null on occasion) wasn't the bottleneck in itself. It's not so 
much the medium, but more the load it causes on the system that 
triggered the overruns.

>> This meant I had to use a DMA PARAM slot for every "period". The
>> OMAP L138 has 128 of those slots, so it's no problem to use a bunch
>> of them. Because the chain is cyclic, there is no need to update any
>> DMA parameter while running. All that ALSA needs to do is empty the
>> buffer before the cycle completes and the current position gets
>> overwritten.
>
> This sort of cyclic thing tends to be best, ideally you don't need
> interrupts at all (other than a timer).

Indeed. In this case, the DMA completion IRQ is still useful because the 
DMA controller issues it after the "period" data has been transferred 
completely. Just monitoring the DMA registers will tell which data is 
currently being transferred, but you can't be sure that it has actually 
been committed. So if the DMA pointer is now at 0x0100, you cannot be 
sure whether the data at 0x0100 is already valid, or even the data at 
0x0098, because that might still be in the controller's queue. The 
pointer increments when the request is sent to the queue, but there's no 
guarantee as to when the queue will actually be executed, because other 
transactions may have higher priority.

Mike.