From: Leonardo Gabrielli <l.gabrielli@univpm.it>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: Edgar Berdahl <eberdahl@ccrma.Stanford.EDU>, alsa-devel@alsa-project.org
Subject: Re: twl4030 latency update
Date: Thu, 20 Mar 2014 15:31:57 +0100 [thread overview]
Message-ID: <532AFBDD.8040407@univpm.it> (raw)
In-Reply-To: <532AEEA6.20704@ti.com>
Dear Peter,
thanks, I'm not sure I understand all the details but after a fast find
in my beagleboard /sys I found
./sys/devices/68000000.ocp/49026000.mcbsp/dma_op_mode
./sys/devices/68000000.ocp/49022000.mcbsp/dma_op_mode
./sys/devices/68000000.ocp/49024000.mcbsp/dma_op_mode
./sys/devices/68000000.ocp/48096000.mcbsp/dma_op_mode
./sys/devices/68000000.ocp/48074000.mcbsp/dma_op_mode
All of these are already set as threshold:
cat sys/devices/68000000.ocp/49022000.mcbsp/dma_op_mode
[element] threshold
Probably I found the FIFOs to be shortened in order to reduce latency:
all of the thresholds are 112 besides one of the devices which has:
cat sys/devices/68000000.ocp/49022000.mcbsp/max_rx_thres
1264
for both tx and rx. Maybe that's the ALSA playback samples queue.
In fact I find:
cat /proc/device-tree/ocp/mcbsp\@49022000/ti\,hwmods
mcbsp2mcbsp2_sidetone
So it's the McBSP2 which you mentioned.
Now, I'm not sure how to change the threshold, I guess I have to patch
some kernel module and rebuild?
On 20/03/2014 14:35, Peter Ujfalusi wrote:
> Hi Leonardo,
>
> On 03/20/2014 01:13 PM, Leonardo Gabrielli wrote:
>> Dear Peter,
>> I was investigating on TWL4030 high playback latency and stumbled in an old
>> thread started by Edgar
>> http://mailman.alsa-project.org/pipermail/alsa-devel/2011-October/045173.html
>> where I read this is related to McBSP2 buffer length
>> Recent kernels seems to have the same behavior (I have a debian beagleboardxM
>> with 3.13.3-armv7-x10)
>> Did you manage to get a fix to this problem? Would it be possible?
> The 'misusing/configuring the McBSP, and sDMA' did not worked :(
> However the mcbsp code went through quite a bit of change since than
> concerning the McBSP FIFO/sDMA configuration.
>
> If we have FIFO the sDMA is always in packet mode.
> The default is to transfer one sample with sDMA per DMA request.
> You can switch the McBSP to 'threshold' mode and set the maximum FIFO
> threshold you want to use. The code will figure out the optimal FIFO/burst
> size based on the period size and the max threshold you have set.
> This is done via a sysfs file under the mcbsp, the file is dma_op_mode if I
> recall correctly.
> Playing with the max tx/rx threshold you might be able to get better latency.
>
next prev parent reply other threads:[~2014-03-20 14:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-20 11:13 twl4030 latency update Leonardo Gabrielli
2014-03-20 13:35 ` Peter Ujfalusi
2014-03-20 14:31 ` Leonardo Gabrielli [this message]
2014-03-21 7:08 ` Peter Ujfalusi
2014-03-25 18:50 ` Leonardo Gabrielli
2014-03-26 8:26 ` Peter Ujfalusi
2014-03-26 8:41 ` Peter Ujfalusi
2014-03-26 9:35 ` Leonardo Gabrielli
2014-03-26 12:28 ` Peter Ujfalusi
2014-03-26 9:45 ` Leonardo Gabrielli
2014-03-26 12:51 ` Peter Ujfalusi
2014-03-26 15:40 ` Leonardo Gabrielli
[not found] ` <533A89D2.5050906@univpm.it>
2014-04-01 13:31 ` Peter Ujfalusi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=532AFBDD.8040407@univpm.it \
--to=l.gabrielli@univpm.it \
--cc=alsa-devel@alsa-project.org \
--cc=eberdahl@ccrma.Stanford.EDU \
--cc=peter.ujfalusi@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox