[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