[alsa-devel] TWL4030 low-latency

[Ujfalusi, Peter]

Hello Edgar,

Please find my comments embedded.

On Fri, Oct 14, 2011 at 9:24 PM, Edgar Berdahl
<eberdahl at ccrma.stanford.edu> wrote:
> Dear Alsa Devel List,
>
> I would like to send some feedback on the TWL4030 driver when used on the Beagle Board. We have tested it under Ubuntu and Angstrom, and we find it does not work well at low latencies (e.g. input-to-output in 5ms, 10ms, or 20ms). Perhaps it was never tested extensively at these latencies. I thought I would send you this information in case you would look into it, or at least pass it on to the relevant contact. I can also run further tests if someone informs me what I should try.

As the first question: what is the kernel versions in these distros?
Just one clarification: the twl4030 driver itself is passive during
audio activity - we set it up,
and let it run. It needs no interaction.
omap-pcm, and omap-mcbsp is "running" during audio.
McBSP feeds the audio via I2S bus to twl4030, sDMA takes care of the samples
coming/going to SDRAM.

> 1) To get the drivers to run at particularly low latencies (e.g. 20ms), it is necessary to operate the drivers in NON-realtime mode. It would interest me to know whether this means that the realtime functionality of the Beagle Board xM hardware or OS is hampered, or whether the TWL4030 driver is not operating up to specification. (If instead the TWL4030 driver is operating in realtime mode, then Jack stops running when an unrelated low-latency USB-serial device is opened.)

I'm not sure what you mean under realtime/non-realtime. Is it
something to do with jack?
It is possible that jack does not like if the pcm period interrupt has
been delayed.
This can hapen due to some driver disables the interrupts for a long
time, thus delaying the
DMA interrupt handler, etc.
Not easy to figure out what is happening.

> 2) Some audio software (e.g. Pure Data, ChucK, etc.) will not connect to the TWL4030 ALSA drivers directly, instead they will only start when jack intermediates between the audio software and the TWL4030 ALSA drivers.

No comment.
I have used mplayer, pulseaudio, ecasound on Beagle without issues.

> 3) In some situations, the TWL4030 drivers appear not to start using the requested settings. For example, when we start jack requesting two periods per buffer, it is apparently getting initialized at eight periods per buffer, see the final lines below:
> Calling
> $ jackd -r -dalsa -dhw:0 -p128 -n2 -i2 -o2 -s -S -r
> on the Beagle under Ubuntu 10.10 and Angstrom demo image results in the following
>
> jackd 0.118.0
> Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and ot.
> jackd comes with ABSOLUTELY NO WARRANTY
> This is free software, and you are welcome to redistribute it
> under certain conditions; see the file COPYING for details
>
> JACK compiled with System V SHM support.
> loading driver ..
> apparent rate = 44100
> creating alsa driver ... hw:0|hw:0|128|2|44100|2|2|nomon|swmeter|soft-mode|16bit
> control device hw:0
> configuring for 44100Hz, period = 128 frames (2.9 ms), buffer = 2 periods
> ALSA: final selected sample format for capture: 16bit little-endian
> ALSA: use **8** periods for capture
> ALSA: final selected sample format for playback: 16bit little-endian
> ALSA: use **8** periods for playback

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...

-- 
Péter