Re: [alsa-devel] Query on Audio DMA using DMAEngine

Re: [alsa-devel] Query on Audio DMA using DMAEngine

[Joel Fernandes]

Copying some more lists are we're also discussing the DMA controller in the
SoCs. Thanks.

On 07/03/2013 04: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.

Hi Mark,

When would it not be possible to cope with a large period size? Are there any
guidelines on what to consider when fixing a period size?

I see tegra and aux1x go upto .period_bytes_min = 1024

About slots, following are no.of slots on some SoCs with EDMA:

am1808 - 96 slots available + 32 taken up for channel but can be reused with
some changes.
am335x - 172 slots available + 64 taken up for channels

On a slightly different note, about buffer_bytes_max, is there any drawback to
setting it to a smaller value? Currently 128K is about what is used on davinci-pcm.
My idea is to map to do the direct mapping to IRAM if the IRAM transfers are
really what are preventing the under runs, but 128K will be too much for the
buffer as we don't have that much IRAM infact it is just the boundary on am33xx
(128K)


Thanks,

-Joel

Re: [alsa-devel] Query on Audio DMA using DMAEngine

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 373 bytes --]

On Wed, Jul 03, 2013 at 12:55:36PM -0500, Joel Fernandes wrote:

> When would it not be possible to cope with a large period size? Are there any
> guidelines on what to consider when fixing a period size?

This is an application issue not a driver issue.  An application that
wants low latency may need high resolution information about what
exactly the hardware is doing.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [alsa-devel] Query on Audio DMA using DMAEngine

[Joel Fernandes]

On 07/03/2013 01:12 PM, Mark Brown wrote:> On Wed, Jul 03, 2013 at 12:55:36PM
-0500, Joel Fernandes wrote:
>
>> When would it not be possible to cope with a large period size? Are there any
>> guidelines on what to consider when fixing a period size?
>
> This is an application issue not a driver issue.  An application that
> wants low latency may need high resolution information about what
> exactly the hardware is doing.
>

Hi Darren,

  Can anyone in your team share some insight about min/max buffer size and
min/max period size in the davinci-pcm driver. This will help make better
decisions about the Cyclic DMA. Below was my original email on the mailing list.

Also could you copy Peter? I couldn't find his email address.

Thanks,
Joel


Quoting my original email to the mailing list:


Copying some more lists are we're also discussing the DMA controller in the
SoCs. Thanks.

On 07/03/2013 04: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.

Hi Mark,

When would it not be possible to cope with a large period size? Are there any
guidelines on what to consider when fixing a period size?

I see tegra and aux1x go upto .period_bytes_min = 1024

About slots, following are no.of slots on some SoCs with EDMA:

am1808 - 96 slots available + 32 taken up for channel but can be reused with
some changes.
am335x - 172 slots available + 64 taken up for channels

On a slightly different note, about buffer_bytes_max, is there any drawback to
setting it to a smaller value? Currently 128K is about what is used on davinci-pcm.
My idea is to map to do the direct mapping to IRAM if the IRAM transfers are
really what are preventing the under runs, but 128K will be too much for the
buffer as we don't have that much IRAM infact it is just the boundary on am33xx
(128K)


Thanks,

-Joel

Re: 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

Re: Query on Audio DMA using DMAEngine

[Mike Looijmans]

On 07/03/2013 08:12 PM, Mark Brown wrote:
> On Wed, Jul 03, 2013 at 12:55:36PM -0500, Joel Fernandes wrote:
>
>> When would it not be possible to cope with a large period size? Are there any
>> guidelines on what to consider when fixing a period size?
>
> This is an application issue not a driver issue.  An application that
> wants low latency may need high resolution information about what
> exactly the hardware is doing.

To get low-latency, the best thing from userspace is to mmap the audio 
buffer, and monitor the position of the DMA transfers. If the driver 
reports the DMA position accurately, you can get latencies of only a few 
samples. I must admit that I know next to nothing about how ALSA works 
in userspace, but that's how DirectSound works, for example. And from 
what I've seen, this is also possible with ALSA.

Even without that - I tried with small periods of only 40 samples, this 
invariably fails on the current driver, with or without the ping-ping. 
Using the cyclic DMA I had no problem using such small periods.

Mike.

Re: [alsa-devel] Query on Audio DMA using DMAEngine

[Mike Looijmans]

On 07/03/2013 07:55 PM, Joel Fernandes wrote:
> Copying some more lists are we're also discussing the DMA controller in the
> SoCs. Thanks.
>
> On 07/03/2013 04: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.
>
> Hi Mark,
>
> When would it not be possible to cope with a large period size? Are there any
> guidelines on what to consider when fixing a period size?
>
> I see tegra and aux1x go upto .period_bytes_min = 1024
>
> About slots, following are no.of slots on some SoCs with EDMA:
>
> am1808 - 96 slots available + 32 taken up for channel but can be reused with
> some changes.
> am335x - 172 slots available + 64 taken up for channels
>
> On a slightly different note, about buffer_bytes_max, is there any drawback to
> setting it to a smaller value? Currently 128K is about what is used on davinci-pcm.
> My idea is to map to do the direct mapping to IRAM if the IRAM transfers are
> really what are preventing the under runs, but 128K will be too much for the
> buffer as we don't have that much IRAM infact it is just the boundary on am33xx
> (128K)

In any case, using the IRAM directly might have some use, because you 
don't have to compete for the DDRRAM with other devices. But I never 
understood what the ping-ping via IRAM was supposed to accomplish, I 
don't see why McASP -> IRAM -> DDRRAM (or the other way around) would be 
better than just McASP -> DDRRAM. Especially since the McASP has a 
built-in 256 byte FIFO buffer on both channels. In all my measurements, 
using the IRAM ping-pong only made things worse in terms of overruns and 
underruns, not better.

Anyone who know why the ping-pong was implemented and what kind of usage 
it was intended for?

Mike.

Re: Query on Audio DMA using DMAEngine

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1473 bytes --]

On Thu, Jul 04, 2013 at 07:56:25AM +0200, Mike Looijmans wrote:
> On 07/03/2013 08:12 PM, Mark Brown wrote:

> >This is an application issue not a driver issue.  An application that
> >wants low latency may need high resolution information about what
> >exactly the hardware is doing.

> To get low-latency, the best thing from userspace is to mmap the
> audio buffer, and monitor the position of the DMA transfers. If the
> driver reports the DMA position accurately, you can get latencies of
> only a few samples. I must admit that I know next to nothing about
> how ALSA works in userspace, but that's how DirectSound works, for
> example. And from what I've seen, this is also possible with ALSA.

There are often hardware limitations that mean that it is not possible
to know the actual position of the DMA with anything less than period
accuracy - either the hardware just doesn't report the current status
during a transfer or it reports something that's not quite what's needed
to usefully interact with it.  The former is depressingly common.  The
APIs can support peering at the current position but it's not something
that a portable application should be relying on.

> Even without that - I tried with small periods of only 40 samples,
> this invariably fails on the current driver, with or without the
> ping-ping. Using the cyclic DMA I had no problem using such small
> periods.

The period size is generally orthogonal to decisions about using cyclic
DMA.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: Query on Audio DMA using DMAEngine

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1073 bytes --]

On Thu, Jul 04, 2013 at 08:06:34AM +0200, Mike Looijmans wrote:

> In any case, using the IRAM directly might have some use, because
> you don't have to compete for the DDRRAM with other devices. But I
> never understood what the ping-ping via IRAM was supposed to
> accomplish, I don't see why McASP -> IRAM -> DDRRAM (or the other
> way around) would be better than just McASP -> DDRRAM. Especially
> since the McASP has a built-in 256 byte FIFO buffer on both
> channels. In all my measurements, using the IRAM ping-pong only made
> things worse in terms of overruns and underruns, not better.

> Anyone who know why the ping-pong was implemented and what kind of
> usage it was intended for?

Pushing the audio through some static RAM is normally implemented in
order to save power - when doing this you can put the dynamic RAM into a
lower power state for more of the time, only waking it up to burst data
to or from the static RAM (assuming an otherwise idle system).  This is
more normally used for playback than for capture but the same idea
applies in both cases.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: [alsa-devel] Query on Audio DMA using DMAEngine

[Sekhar Nori]

On 7/4/2013 11:36 AM, Mike Looijmans wrote:
> On 07/03/2013 07:55 PM, Joel Fernandes wrote:
>> Copying some more lists are we're also discussing the DMA controller
>> in the
>> SoCs. Thanks.
>>
>> On 07/03/2013 04: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.
>>
>> Hi Mark,
>>
>> When would it not be possible to cope with a large period size? Are
>> there any
>> guidelines on what to consider when fixing a period size?
>>
>> I see tegra and aux1x go upto .period_bytes_min = 1024
>>
>> About slots, following are no.of slots on some SoCs with EDMA:
>>
>> am1808 - 96 slots available + 32 taken up for channel but can be
>> reused with
>> some changes.
>> am335x - 172 slots available + 64 taken up for channels
>>
>> On a slightly different note, about buffer_bytes_max, is there any
>> drawback to
>> setting it to a smaller value? Currently 128K is about what is used on
>> davinci-pcm.
>> My idea is to map to do the direct mapping to IRAM if the IRAM
>> transfers are
>> really what are preventing the under runs, but 128K will be too much
>> for the
>> buffer as we don't have that much IRAM infact it is just the boundary
>> on am33xx
>> (128K)
> 
> In any case, using the IRAM directly might have some use, because you
> don't have to compete for the DDRRAM with other devices. But I never
> understood what the ping-ping via IRAM was supposed to accomplish, I
> don't see why McASP -> IRAM -> DDRRAM (or the other way around) would be
> better than just McASP -> DDRRAM. Especially since the McASP has a
> built-in 256 byte FIFO buffer on both channels. In all my measurements,
> using the IRAM ping-pong only made things worse in terms of overruns and
> underruns, not better.
> 
> Anyone who know why the ping-pong was implemented and what kind of usage
> it was intended for?

McBSP peripheral that was included in the DaVinci devices like DM644x
dis not come with FIFO. Due to latency of DDR accesses, there were
channel swaps observed due to lost samples on these devices and IRAM
implementation helped there.

Thanks,
Sekhar