[pulseaudio-discuss] Pulseaudio per-user instance unusable

Thu Jul 7 21:54:16 PDT 2011

Hi,

On Thu, Jul 7, 2011 at 10:51 PM, Joel A Fernandes <agnel.joel at gmail.com> wrote:
> Hi!
>
> I will be as descriptive as possible about a certain issue pulseaudio
> I have had keeping audio devices "busy" and discuss what I have tried
> and what I see.
>
> I'm using a 2.6.32 kernel (have also used a 2.6.39 kernel) with
> PulseAudio 0.9.15 (Angstrom distribution) on a BeagleBoard (tried C5
> and -xM).

Version 0.9.15 is very old :-) A lot of bugs have been fixed since
then, and a lot of effort has been expended trying to better support
PulseAudio on embedded systems like this one. If in any way possible,
see about getting a more recent version (using the latest stable
release would be advisable). Of course this may be impractical if your
company has already performed some sort of rigorous QA using
pulseaudio 0.9.15 and determined that it's suitable for your platform;
but from the looks of the problems you're having, I don't think you've
come that far yet :-)

>
> The problems appear to be two-fold.
> - Firstly, the utilities: pactl, pacmd etc are unable to connect to
> the pulse server most of the times (so its kind of intermittent)

I'm assuming you are running pactl and pacmd as the same user that's
running pulseaudio (as a user), correct? In per-user mode, by default
only programs that are run as the user who ran the PA daemon can
connect.

I noticed you added auth_anonymous=1 to the
module-native-protocol-unix, but I don't know if that handles the
problem of permissions too. Does anyone know if just passing this
parameter is sufficient to make the UNIX protocol usable by any user
on the system? I thought that system-wide mode is necessary for that
functionality, due to limitations of the shared memory architecture or
something like that.

Of course, you can always run your daemon in per-user mode, but enable
module-native-protocol-tcp, and set an ACL to only allow localhost.
This would allow any user to establish a TCP/IP connection on the
loopback interface for pulseaudio, which is much more flexible (and
less prone to configuration errors) than the UNIX socket protocol.
Sockets are great for the user who started the daemon, but for other
users I personally use module-native-protocol-tcp. There may yet be a
way to get sockets working (for the performance and latency benefit
they offer), though! But it is noteworthy that the system-wide daemon
*never* supports shared memory I/O between the client and server, so
by comparison, at least with a per-user daemon you have the
opportunity to use shared memory if the permissions work out. If you
run the system-wide daemon, you completely give up that opportunity
(with no workaround AFAIK, other than to stop using system-wide mode).

> - Second, aplay cannot use pulseaudio as it throws errors as mentioned
> below, and, cannot not-use pulseaudio as it keeps the sound devices
> busy :) So we're stuck!

aplay should be able to use pulseaudio if you use the pulse PCM plugin
for libasound2. On my system, this plugin is in the file
/usr/lib/alsa-lib/libasound_module_pcm_pulse.so and links against
libpulse. It's a fairly unremarkable pulse client that adapts the
native pulseaudio API to ALSA clients that observe the Safe ALSA
Subset[1], and it obeys the rules in /etc/pulse/client.conf for
determining which daemon to connect to, whether to auto-start it, etc.
If you don't already have this PCM plugin, you can obtain it by
recompiling the alsa-plugins package on a system that has the
pulseaudio client development headers and libraries installed.

If all your ALSA clients observe the Safe ALSA Subset (which in
practical terms means that they can play audio through the pulse PCM
plugin for libasound without producing an error), then there is no
practical reason why you'd need pulseaudio to relinquish the
underlying ALSA hardware device. But I agree that
module-suspend-on-idle is useful, at least for power savings, if not
to allow ALSA applications to directly access an hw device.

The problem you're having with module-suspend-on-idle not loading is
most strange. Can you post to the list (preferably in an attachment if
it's very large) with the output of `pulseaudio -vvvv
--daemonize=false` ? We should at least make sure that:

1. The line "load-module module-suspend-on-idle" is in default.pa (if
in per-user mode) or system.pa (if in system-wide mode).
2. That PulseAudio is actually using the default.pa file that you
think it is, and not some different one. For example, if you compile
pulseaudio with ./configure --prefix=/usr, by default it will look for
default.pa in /usr/etc/pulse instead of /etc/pulse :-) To get
pulseaudio to look in /etc/pulse by default, you have to compile it
with "./configure --sysconfdir=/etc" (the other directories and the
prefix are not relevant to this particular issue, because specifying
an absolute path in sysconfdir overrides the prefix).
3. That PulseAudio can find the module-suspend-on-idle shared library;
that PulseAudio process has permission to read the file; that the
dynamic linker is able to load it into the address space and dlsym()
the plugin interface.
4. If all that succeeds, then maybe there is a bug in
module-suspend-on-idle itself, or maybe the module is working 100%
fine but you have a pulseaudio client that is writing or reading audio
just enough to keep the sink (resp. source) busy? Since you can't run
pactl or pacmd (yet :)) I guess you can't tell if there are any active
PA clients that might be keeping it busy.

The output of your pulseaudio -vvvv should provide us sufficient
information to determine where, in this process, the loading of
module-suspend-on-idle fails. Hopefully, after you take my advice
about the pulse PCM plugin, you won't need to rely on
m-suspend-on-idle to relinquish the hardware device for other ALSA
apps, but you will still be able to benefit from the power savings
that can be gained by allowing the audio ASIC to go into powersaving
mode.

Oh, one more tip -- you might like to poke /dev/snd/pcm* with the
`fuser` program, to see which process(es) have the ALSA hardware
device nodes open. If you get "device or resource busy" on a new
ALSA-using process, and an existing process has the pcm* device open
for your sound chip, that's proof-positive of *why* you're getting
that error (namely, that your ASIC doesn't support hardware mixing (or
it's out of available channels) and a process is already using the
device). You might be able to get the same info from /proc or lsof
though, so this may be redundant. It's just the way I do it :-)

You said you ran the process with strace, so are you seeing evidence
that it's actually trying to open the default.pa file that you think
it is?

Try:

strace -Ff -eopen pulseaudio <args> | grep default.pa

Make sure it's opening /etc/pulse/default.pa (if that's the one where
you load module-suspend-on-idle) and not some other one :-)

If we stick with this, I'm sure we can use system tools and smart
diagnosis and troubleshooting to resolve your difficulties with
0.9.15. But because such tremendous work has been ongoing for better
supporting pulseaudio on embedded devices, I would recommend that you
at least evaluate pulseaudio 0.9.23 (or git master) to see how well it
runs for you.

HTH,

Sean

[1]: http://0pointer.de/blog/projects/guide-to-sound-apis.html

>
> I have tried running pulseaudio in both system and user modes.
>
> * When started up as a per-user instance ,which is started up by
> start-pulseaudio-x11 like so:
>  /usr/bin/pulseaudio --start "$@"
>
> The pulseaudio server daemonizes but not always. Sometimes I have to
> delete the .pulse-cookie file and .pulse/ directory to have it
> daemonize. Only once it does daemonize, pactl is able to connect to it
> and list modules but again audio players can't have it play anything.
> Further, -vv -log-level pulseaudio options don't seem to generate very
>  interesting debug information that helps.
>
> strace shows that it opens the sound device and then calls pause()
> waiting for events to occur. This causes no one else to be able to
> open the sound devices! pulseaudio just keeps it busy though its not
> using the devices! suspend-on-idle module doesn't get loaded, though
> the default.pa has it set.
>
> I can confirm that the shared library "suspend-on-idle module" is
> _not_ being loaded by looking at its process memory map
> (/proc/../maps) though the /etc/default.pa file does have the option
> enabled! I cannot use pactl to check if the module is loaded because
> it doesn't connect to the pulse server (as mentioned above), but
> atleast the memory map tells me it isn't.
>
> * In system mode (passing --system)
> clients such as pactl are able to connect and list modules etc and the
> sound devices are not kept busy.
>
> However audio players that use pulseaudio (by settings in
> /etc/asound.conf), report an error such as "Unable to create stream:
> No such entity, Unable to set hw params". The distribution doesn't
> have an asound.conf preconfigured so this isn't a problem as such but
> I thought I'd mention it anyway.
>
>  So pulseaudio --system doesn't work but atleast it _does not_ keep
> sound devices open. So other applications can still use alsa to open
> sound devices without going through pulseaudio.
>
> For reference, I have uploaded my /etc/default.pa and /etc/system.pa
> config files to:
> http://utdallas.edu/~jaf090020/system.pa
> http://utdallas.edu/~jaf090020/default.pa
>
> I would appreciate any suggestions on what could be a possible cause,
> and a viable solution to the problem.
>
> Thanks,
> Joel
> _______________________________________________
> pulseaudio-discuss mailing list
> pulseaudio-discuss at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
>