[alsa-devel] Query on Audio DMA using DMAEngine

[Joel Fernandes]

Hi Mike,

On 07/03/2013 08:17 AM, Mike Looijmans wrote:
> On 07/03/2013 11:43 AM, Mark Brown wrote:
>> On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote:
>>> On 07/02/2013 02:13 PM, Mark Brown wrote:
>>
>>>> This sort of cyclic thing tends to be best, ideally you don't need
>>>> interrupts at all (other than a timer).
>>
>>> Yes, this is usually how it is done. But I'm wondering maybe the EDMA
>>> controller only has a small total amount of slots available.
>>
>> Well, you don't need particularly many slots so long as you can cope
>> with a large period size.
> 
> On the OMAP L138, there are 128 PARAM slots. 32 of those are tied to hardware
> events (though you can use them if you aren't using the related hardware, for
> example the UART drivers don't use DMA so you can freely use those slots if you
> want), leaving (at least) 96 PARAM slots free. Both audio events are on the same
> controller, so you can't use the 128 of the other one (the OMAP has 2 EDMA
> controllers). Only a few dozen of those are being used by various drivers, the
> SD card driver being the most hungry.
> For the system to work, you can even get away with only using one slot, and
> hence one period, but then you'll have to use a mmap and a timer to fill it.
> 
> I experimented with various memory layouts. For large transfers, using 2 big
> periods was quite enough. I also tested with very small period sizes. Using the

Wouldn't very small periods take up too many interrupts, and also occupy lots of
slots?

> original code, I was unable to reliably capture (to /dev/null) at period sizes
> below 80 samples. With the cyclic DMA, I could set a period size of only 40
> samples and still be able to record audio reliably, when using only 8 periods.
> The same for playback, basically. So that's how I arrived at the MAX_PERIODS
> define of "8". It will only claim channels when you use them, so setting it to
> say "100" will not crash the system.

Thanks for your post Mike. It makes more sense to me now.
Correct me if I'm wrong but:
- more the periods, more the granularity- but the drawback is you'd need more
slots and too many interrupts; so we want fewer periods as many as we need. I
still don't know though, how do we arrive at an acceptable number that userspace
expects?
- periods also will determine buffer size. Considering in future if we'd want to
use IRAM as the buffer which is limited on some users of the davinci-pcm, there
might not be enough buffer space.

So too many periods is certainly not a good thing. I wonder how we can arrive at
what would constitute an acceptable number? As Linus said, "we never break
userspace :P" so I'd rather not change anything that breaks someone's audio
application.

I will post some RFC notes soon capture our discussion and other ideas I had put
together for EDMA as some notes to summarize and get everyone's opinion. I will
copy you on that as well. Thanks.

-Joel