Pandora Open Pandora Super Low Latency Audio (mini howto)

[bsp]

Just want to swing by for a second to tell you how happy I am with my Pandora right now


I spent the whole day figuring out how to configure it for realtime MIDI and audio.

This morning it was a crackle / glitch-fest..

..now I have a stable, zero underrun, 1.4ms (!) low latency audio stream running, along with 9 MIDI device threads and a very CPU/GPU intensive OpenGL ES 2 GUI (runs with least priority).

To make this happen, I had to patch the OMAP MCBSP audio driver since it always reported the maximum buffer size as the minimum (wtf!).

With the original kernel, you always end up with at least a 256 frame ALSA period size.

With the patches/hacks, you can use e.g. 64 frame period sizes.

This kind of low latency is needed since the latencies add up if you process audio. 2*5.8=11.6ms was just too high and felt sluggish.

The drawback with the patches is that it breaks the sound of some emulators (e.g. EmuExAlpha), that's why I now keep two kernels around, one for gaming, and the other one for audio.


Last but not least I had to use a utility called "set_rlimits" to allow my user process to use the SCHED_FIFO scheduling policy and rather high (40) realtime priorities in its threads.

I've attached the updated kernel sources and the set_rlimits ARM binary (+example config file), in case anyone is interested.

alsa_async_super_lowlatency-23Aug2014.tar.gz

 

[sepulep]

is this something for the firmware kernel?

btw which audio software are you using??

 

[bsp]

is this something for the firmware kernel?  ==> yes

btw which audio software are you using?? ==> my own (work in progress)

 

[notaz]

To make this happen, I had to patch the OMAP MCBSP audio driver since it always reported the maximum buffer size as the minimum (wtf!).

I think the idea here was to set the minimum size to internal FIFO size to avoid underruns.

This kind of low latency is needed since the latencies add up if you process audio. 2*5.8=11.6ms was just too high and felt sluggish.

Can you really feel the difference between 11.6ms and 1.4ms latency? I'm quite sure I can't.

The drawback with the patches is that it breaks the sound of some emulators (e.g. EmuExAlpha), that's why I now keep two kernels around, one for gaming, and the other one for audio.

Yeah if you look at default ~/.asoundrc, it enforces even higher minimum buffer size, otherwise some games get stuck in repeating underflows forever..
Looking at your changes, I guess omap_pcm_hardware.period_bytes_min is the change that solved your glitch problems and the other changes are for latency? That chunk might be useful to merge to default kernel as having tiny 32 byte periods doesn't really make sense.

 

[bsp]

The change in omap-pcm.c does not seem necessary. Actually it seems to break sth -- I upgraded to the latest kernel (3.2.61) today, applied the patch, and then noticed 'spurious IRQ' messages in the klog when trying to record audio in Audacity. Reverting that file to the original made those messages go away.

The essential change is this (in omap-mcbsp.c):
 


#if 0
   /* Original code (==> min period=256 frames, latency=~5.8ms) */
   frames.min = size / channels->min;
#else
   /* Low latency hack (==> min period=64 frames, latency=~1.4ms) */
   frames.min = 256;
   /* // Note: comment out the following line to fix EmuExAlpha audio */
   frames.max = 512;//size / channels->min;
#endif

I have to admit that I don't exactly understand ALSA.. why does the original code not set frames.max and why does setting frames.max to any higher values (e.g. max. FIFO size) make ALSA report higher "min periods" (?!) I would expect frames.min to be responsible for that !?

And yea, some games / emus apparently need really large buffers and maybe don't query which buffer size / period size settings are actually used.

Apps / games that behave well with the low latency hack (out of the few I've tested) are Final Burn Alpha, F1 Spirit Remake, ProtoType, Audacious, SunVox, MilkyTracker.

Maybe someone has a good idea how to properly add this low latency option so that it works w/o booting another kernel ?

It'd probably be best to fix the actual issue, which seems ALSA-related, but the second best option would be to add some kind of /proc hack that lets you configure this at runtime (just thinking out loud here). Something like echo "1">/proc/asound/pandora_low_latency_hack to enable it ?


Regarding latency in general: You will only notice the difference when you play / record an instrument.

The ear is much more sensible to "frame rates" than the eye. 11.6ms (2*5.8) are certainly not terrible, but still noticeable.
At 2.9ms latency (2*1.45), only few people will be able to hear the difference to anything less than that.

Usually, anything around / below 5ms is considered acceptable (by musicians).

..and you wouldn't believe the kind of "religious" wars some of the electronic music crowd fight over such things

For example, when it comes to MIDI, some people argue that only hardware MIDI sequencers (with a realtime (or "no") OS) are acceptable, and anything else is just not "tight" (..one has to keep in mind that it takes 0.96ms to send a simple "note on" message over the 31250 bits/second MIDI line (8 data bits + start+stop bits)..).

But considering that MIDI on desktop PCs can really be a nightmare in terms of "tight" timing, there's some truth to this debate.

From what I've seen / measured so far, the Pandora can serve as a good platform for music applications. Actually I'm quite amazed how good the Linux scheduler(s) have become. Very capable of (soft-) realtime audio / MIDI applications! I moved to Windows ASIO/WinMM for audio / MIDI apps after some bad Linux experiences ten+ years ago but Linux has really changed a lot since then (for the better!)..

..and in case anyone wonders why I'm even concerned about these things: I'm currently writing a new Pandora-specific MIDI sequencer (with some audio features -- not the app's main focus, though). I've been on a coding spree the past three weeks (holiday..) and things are looking (and working) very nicely so far!

Originally I bought the Pandora with the intention of using it as the "brain" for controlling my synthesizer park. After doing a quick-port of my PC sequencer (and looking at other "ported" apps), I quickly realized that its UI and keyboard-focused controls simply do not work well on the Pandora. That's why I'm currently writing a new one. Luckily I could recycle a lot of code from the old one but the UI and also the actual sequencer design will be completely different (the old one was a tracker, at least on the surface..). I'll release it as soon as certain key features are done (probably in a few months).