[Openal-devel] "PulseAudio returned minreq > tlength/2; expect break up" on ARM

Chris Robinson chris.kcat at gmail.com
Mon Jun 20 12:31:25 PDT 2011


On Monday, June 20, 2011 11:00:53 AM Sami Liedes wrote:
> Hi!
> 
> I'm trying to get OpenAL Soft (current git HEAD) to work on a Nokia
> N900 phone (ARM Linux). The problem seems to be some kind of
> incompatibility between N900's PulseAudio and OpenAL. This manifests
> as jumpy sound and a warning:
> 
>   AL lib: pulseaudio.c:372: PulseAudio returned minreq > tlength/2; expect
> break up

I've noticed that PuleAudio likes to regularly raise the minimum latency it 
will allow for a playback stream, and never lowers it under any circumstance. 
I've had instances where the minimum latency would be set to a full second or 
more, and not even PA_STREAM_ADJUST_LATENCY would bring it back down (not that 
it can be used with PA_STREAM_EARLY_REQUESTS). The only way to get it back 
down was to kill and restart PulseAudio.

> After experimenting, I could find values of minreq=48000,
> tlength=96000 that PulseAudio accepts and satisfy the above
> constraint, yet audio is still just as jumpy.

At 16-bit stereo 44100hz playback, that's a half-second tlength and a quarter-
second minreq. Way too high to be reasonable for general playback.

I'm not sure what can be done with OpenAL to help alleviate the problem. It 
currently relies on being able to do updates as soon as enough space becomes 
available to write in, which is why it uses PA_STREAM_EARLY_REQUESTS with 
appropriate buffer parameters. The default parameters I even thought were on 
the slightly-high side, but figured it'd be a good 'make sure it works' 
compromise.

If PulseAudio isn't able to honor those parameters, then I'm not sure there's 
anything OpenAL can do to get it working at respectable latencies. It's likely 
something that has to be worked out with PulseAudio.


More information about the Openal-devel mailing list