[alsa-devel] TWL4030 low-latency

[Edgar Berdahl]

Dear Peter,

Sorry for the delay in getting back to you. I just wanted to follow up now that I got the Angstrom SDHC card and booted it to check the kernel version.

> Edgar, are you guys running a vanilla kernel or an -rt kernel?

We are running vanilla kernels:
In Ubuntu:
ccrma at satellite:~$ uname -a
Linux omap 2.6.38.4-x3 #1 SMP Wed Apr 27 00:42:20 UTC 2011 armv7l GNU/Linux

In Angstrom:
root at beagleboard:~# uname -a                                                    
Linux beagleboard 2.6.32 #3 PREEMPT Wed Aug 18 15:53:03 UTC 2010 armv7l unknown 

>>> I think I can explain this:
>>> McBSP2 has 1280 word long buffer.
>> Wow, that is a long buffer! There is no way to reduce the buffer size?
> I have some ideas, but it is a long shot.
> Basically by design it is not possible, but I might can get around of it by
> misusing/configuring the McBSP, and sDMA.
I would imagine that you could, in order to decrease the latency, initialize the buffer with all zeros and then only change part of the buffer with each interrupt. Or is there some hardware restriction?

> I try to hack something up for kernel 3.3.
I'm looking forward to testing it!

Best regards,
Edgar

Ujfalusi, Peter wrote:
> I think I can explain this:
> McBSP2 has 1280 word long buffer.
> We place constraint that the ALSA buffer must not be smaller than this, because
> if it is smaller we can end up spinning on the buffer at stream start:
> sDMA will fill up the FIFO, and if the buffer is smaller than the
> FIFO, it will copy
> the buffer several times, or partially. Depending on the size you
> would have chosen.
> 
> You are requesting 128 frames long period size, which occupy 256 words (I assume
> stereo samples)
> With that period size you will need at least 5 periods to cover the McBSP2 FIFO:
> 1280 / 256 = 5
> It is another question, why jack selects 8 periods, while it could use
> 6, if it likes to
> have even number of periods...