[alsa-devel] twl4030 latency update
l.gabrielli at univpm.it
Thu Mar 20 15:31:57 CET 2014
thanks, I'm not sure I understand all the details but after a fast find
in my beagleboard /sys I found
All of these are already set as 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:
for both tx and rx. Maybe that's the ALSA playback samples queue.
In fact I find:
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
>> 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.
More information about the Alsa-devel