[alsa-devel] TWL4030 low-latency
peter.ujfalusi at ti.com
Mon Oct 17 07:12:11 CEST 2011
On Mon, Oct 17, 2011 at 4:39 AM, Edgar Berdahl
<eberdahl at ccrma.stanford.edu> wrote:
> I'm just starting to get experience with embedded linux systems. I assume that since they have less computational power, interrupt processing could use up a larger percentage of that CPU power on average.
It is not just processing power.
We have peripherals attached through slow buses.
Some drivers just disables interrupts while they are communicating
(when they should not).
Embedded environment is quite different from normal desktops, and some
tweaking might be
needed to get optimal results on a given configuration.
>>> 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.
> Yes, as far as I know these programs work great! Audio latency is probably less of a concern for them.
BTW: PA also have 'real time' mode which basically means that it is
using the kernel scheduling
for audio timing. It does not uses the audio interrupts (this should
work fine now).
>> 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 try to hack something up for kernel 3.3.
> I bet this is where a lot of the latency comes from!
I think you can see rapid period elapsed at the start of the playback
settle down after ~640 samples...
More information about the Alsa-devel