[pulseaudio-discuss] Fwd: [Openal-devel] PulseAudio backend troubles

[Sean McNamara]

FYI group,

Chris (the active maintainer of OpenAL Soft) has some troubles with
the PA backend to OpenAL.

I'd love to see the PA developers on this list to work with Chris and
figure out where the problem is and resolve it, so that we don't have
to resort to alsa-pulse, which I dislike for many reasons, not the
least of which is the level of abstraction taking away some of the
(ease of) configurability of native pulse.

Aside from actually addressing Chris's technical issues with the pulse
backend, I'd just like to chime in and say I have never experienced
anything like this before, and I've used openal-soft's pulse backend
on a pulse server with an uptime in excess of a month. So it clearly
isn't the case that this behavior manifests in all situations.
Depending on the version of alsoft and PA that I'm using vs. Chris's,
it's either a regression he's experiencing (if his version(s) are
newer), or I'm using a newer version of pulse that fixes the problem.
I'm not sure. Or it could just be an alsa-driver-specific issue, as we
have often discovered is at the root of many PA troubles.

Thanks,

Sean


---------- Forwarded message ----------
From: Chris Robinson <chris.kcat at gmail.com>
Date: Mon, Feb 20, 2012 at 3:41 PM
Subject: [Openal-devel] PulseAudio backend troubles
To: openal-devel at opensource.creative.com


Hi guys, I have a bit of a query.

Currently, OpenAL Soft will prefer the PulseAudio backend when it's available.
However, lately I've noticed that I end up getting a lot of breakup in
playback when the PA server has been running for a while. Traces I've done
have shown that Pulse is not running out of audio -- initial startup has it
filling the whole buffer, and each update after correctly shows an approximate
period-sized writable chunk which is only a fraction of the whole buffer.

I've also notced that the ALSA->Pulse bridge seems to be working much better.
I no longer have to explicitly disable mmap as it appears ALSA's mmap
emulation is now off by default (it would break the pulse plugin when used),
and audio playback doesn't break up.

I've been considering dropping, or at least lowering the priority of, the
PulseAudio backend in favor of the ALSA backend. However, I'm not sure if the
mmap emulation bug is truly gone or if it's just my system and/or newer setups
that work now. Also, the ALSA backend doesn't do as good of a job
autodetecting the default output mode (eg, quad or 5.1 surround) like the
PulseAudio backend does, especially with the pulse plugin (even without
'plug', it'll accept any output mode).


So, I have a quandry. Do I leave the PulseAudio backend as it is, where it
breaks when PulseAudio's minimum latency starts growing high (as it often
likes to do)? Or do I lower its priority to prefer the ALSA backend and the
pulse plugin, which doesn't do as good of a job in detecting the default audio
config and may still have mmap issues for some people?

Unless someone can take a look at OpenAL Soft's PulseAudio backend, I can't
see anything that should be causing the breakup in playback as it's not
underrunning. Of course when PulseAudio's minimum latency grows you'll start
having a lot of audio lag anyway, which is bad either way I take it, and
there's nothing OpenAL Soft can do for that (requires killing and restarting
the pulse server to fix).

Any ideas or suggestions?
_______________________________________________
Openal-devel mailing list
Openal-devel at opensource.creative.com
http://opensource.creative.com/mailman/listinfo/openal-devel