Hi Edgar,
On Mon, Oct 17, 2011 at 4:39 AM, Edgar Berdahl eberdahl@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.
- 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 which should settle down after ~640 samples...