[pulseaudio-discuss] Pulseaudio per-user instance unusable

Colin Guthrie gmane at colin.guthr.ie
Fri Jul 8 02:51:38 PDT 2011


'Twas brillig, and Joel A Fernandes at 08/07/11 03:51 did gyre and gimble:
> 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).

As per Sean's comment, both the kernel and PA version are pretty old
now. I'd advice using newer versions if at all possible.

While I can offer general advice, I can't really give code-level support
for such an old version of PA.

> 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)
> - 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!
> 
> 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.

OK, so something is holding things up at startup. Can you work out what
that is? Perhaps running PA manually via "pulseaudio -vvvvv" will give
some clues?

> Further, -vv -log-level pulseaudio options don't seem to generate very
>  interesting debug information that helps.

Try more v's ;)

> 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.

As a general rule noone else *should* be opening the audio devices. But
I'm not sure what you mean by "calls pause()" here. There is no such
call in PA source code.

If you mean various select() calls to wait for fd devices then this is
intended, although I'd have thought that suspend-on-idle should also
kick in at some point....

It seems that if default.pa has suspend-on-idle specified but it's not
being loaded, then something more sinister is happening. I'd need to see
log output from pulseaudio -vvvvv to say more.


> 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.

Does your user have a ~/.pulse/default.pa? If so, this file overrides
the one on /etc/pulse/


> * 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.

By audio players, do you include paplay?

I'd need to see more details commands and logs here (both the
output/errors from the command itself and the PA logs when this is run).

>  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.

As well as the config files, Please also upload the output from running
PA (as a normal user with -vvvvv) from the terminal.


All I'd say is to follow some basic safety steps when running a per-user
daemon:
  1. Always run client apps as the same your you run PA daemon as.
  2. Always check that other client configurations are not changing
where you connect to (e.g. a client.conf, or PULSE_SERVER env var or
PULSE_SERVER X11 property on the root window).
  3. Debug connection problems with "PULSE_LOG=99 pactl stat"


Point 2 in particular is an issue if you are SSH'ing in to this box
remotely. If you have X11 forwarding enabled (which is typical) then the
X11 properties will be telling your login on the remote box to try and
connect back to the machine you SSH'ed in from.

("xprop -root | grep PULSE_" is your friend here)

Either disable X11 forwarding or run "pax11publish -r" before SSHing.

HTHs

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]



More information about the pulseaudio-discuss mailing list