No or only random connections to PulseAudio server after `pulseaudio -k`.

[PaulePanter]

Dear PulseAudio folks,

I want to debug PulseAudio problems as described in [1].

Therefore I added autospawn = no to ~/.pulse/client.conf and issued pulseaudio -k and pulseaudio -vvvvv.

But after doing so all my programs are not able to connect to the PulseAudio server(?) anymore.

Putting autospawn = yes to ~/.pulse/client.conf produces the same behavior besides with MPlayer, where it is sometimes able to connect to the server but fails in over 90 % of the attempts doing so.

1. For example running gstreamer-properties which has PulseAudio selected as output device gives an error message.

$ LANG=C gstreamer-properties
gstreamer-properties-Message: Error running pipeline 'PulseAudio Sound Server': Failed to connect: Connection refused [pulsesink.c(442): gst_pulseringbuffer_open_device (): /GstPipeline:pipeline0/GstPulseSink:pulsesink3]

2. Also MPlayer does not work anymore with PulseAudio as output.

AO: [pulse] Init failed: Connection refused
Failed to initialize audio driver 'pulse'
Could not open/initialize audio device -> no sound.
Audio: no sound

Killing PulseAudio with autospawn = yes and feeding for example 12 audio files into MPlayer, then maybe half of the time running `mplayer -ao pulse *` is able to play a song at the end of the list (e. g. 9th song) and fails for the following songs again.

Here is a excerpt from the debug messages. The whole file is attached.

$ LANG=C pulseaudio -vvvvv 2> 20100130--pa-vvvvv.log
[…]
D: module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: alsa-sink.c: Wakeup from ALSA!
I: module-suspend-on-idle.c: Source alsa_input.pci-0000_20_01.0.analog-stereo idle for too long, suspending ...
D: source.c: Suspend cause of source alsa_input.pci-0000_20_01.0.analog-stereo is 0x0004, suspending
I: alsa-source.c: Device suspended...
I: module-suspend-on-idle.c: Sink alsa_output.pci-0000_20_01.0.analog-stereo idle for too long, suspending ...
D: sink.c: Suspend cause of sink alsa_output.pci-0000_20_01.0.analog-stereo is 0x0004, suspending
I: alsa-sink.c: Device suspended...
D: reserve-wrap.c: Device lock status of reserve-monitor-wrapper@Audio0 changed: not busy
D: module-udev-detect.c: /dev/snd/controlC0 is accessible: yes
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionAdded
D: module-console-kit.c: dbus: interface=org.freedesktop.ConsoleKit.Seat, path=/org/freedesktop/ConsoleKit/Seat1, member=SessionRemoved
[…]

I am using Debian Sid/unstable and you can find the installed version at the end of this message. Please tell me what other information you need.

Thanks,

Paul

[1] http://fedoraproject.org/wiki/How_to_debug_PulseAudio_problems#General_advice

Version: 0.9.21-1
Versions of packages pulseaudio depends on:
ii  adduser                       3.112      add and remove users and groups
ii  consolekit                    0.4.1-3    framework for defining and trackin
ii  libasound2                    1.0.21a-1  shared library for ALSA applicatio
ii  libasyncns0                   0.3-1      Asyncronous name service query lib
ii  libc6                         2.10.2-5   Embedded GNU C Library: Shared lib
ii  libcap2                       1:2.17-2   support for getting/setting POSIX.
ii  libdbus-1-3                   1.2.16-2   simple interprocess messaging syst
ii  libgdbm3                      1.8.3-9    GNU dbm database routines (runtime
ii  libice6                       2:1.0.6-1  X11 Inter-Client Exchange library
ii  libltdl7                      2.2.6b-2   A system independent dlopen wrappe
ii  libpulse0                     0.9.21-1   PulseAudio client libraries
ii  libsamplerate0                0.1.7-3    Audio sample rate conversion libra
ii  libsm6                        2:1.1.1-1  X11 Session Management library
ii  libsndfile1                   1.0.21-2   Library for reading/writing audio 
ii  libspeexdsp1                  1.2~rc1-1  The Speex extended runtime library
ii  libudev0                      150-2      libudev shared library
ii  libwrap0                      7.6.q-18   Wietse Venema's TCP wrappers libra
ii  libx11-6                      2:1.3.3-1  X11 client-side library
ii  libxtst6                      2:1.1.0-2  X11 Testing -- Resource extension 
ii  lsb-base                      3.2-23     Linux Standard Base 3.2 init scrip
ii  udev                          150-2      /dev/ and hotplug management daemo

Versions of packages pulseaudio recommends:
ii  gstreamer0.10-pulseaudio      0.10.17-1  GStreamer plugin for PulseAudio
ii  libasound2-plugins            1.0.21-3   ALSA library additional plugins
ii  pulseaudio-esound-compat      0.9.21-1   PulseAudio ESD compatibility layer
ii  pulseaudio-module-x11         0.9.21-1   X11 module for PulseAudio sound se

Versions of packages pulseaudio suggests:
pn  paman                         <none>     (no description available)
pn  paprefs                       <none>     (no description available)
ii  pavucontrol                   0.9.9-1    PulseAudio Volume Control
pn  pavumeter                     <none>     (no description available)
ii  pulseaudio-utils              0.9.21-1   Command line tools for the PulseAu

[PaulePanter]

LANG=C pulseaudio -vvvvv 2> 20100130--pa-vvvvv.log

[coling]

Chances are your X11 properties are somehow out of sync with the running PA. This shouldn't really happen but does pax11publish -r help? Or running start-pulseaudio-x11 after killing PA (or after running it in the terminal manually - i.e. run start-pulseaudio-x11 in another term while the -vvv manual run is happily sitting and waiting)

Both methods should fix up the X11 settings that the client uses when connecting... Not certain this is the problem, but I suspect it's something in this area.

[PaulePanter]

Following your suggestions I found several things I find strange. I enumerated them. Please tell me if I should create separate tickets for those.

Replying to coling:

Chances are your X11 properties are somehow out of sync with the running PA. This shouldn't really happen but does pax11publish -r help?

Did you mean pax11publish -e to export the information to the X11 root window?

I did not know about pax11publish. The manual page lists xprop -root | grep ^PULSE_ to dump the raw information. pax11publish -d seems to output the Server and Cookie nicely formatted.

So with the PulseAudio server started by my GNOME session(?) I got.

$ xprop -root | grep ^PULSE_
PULSE_COOKIE(STRING) = "aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20"
PULSE_SERVER(STRING) = "{1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native"
PULSE_SESSION_ID(STRING) = "1572dc2ca76ca04c3351599547f539a6-1265011784.364806-1969959962"
PULSE_ID(STRING) = "1000@1572dc2ca76ca04c3351599547f539a6/3489"

$ pax11publish -d
Server: {1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native
Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20

Killing pulseaudio -k and starting PulseAudio pulseaudio -vvvvv with autospawn = no resulted in the following.

$ pulseaudio -k
$ xprop -root | grep ^PULSE
$ pax11publish -d
$ pulseaudio -vvvvv
$

So the PA server credentials were not published to the X root window. Wondering why, I noticed in the log or with list-modules in pacmd that module-x11-publish was not being loaded. It is commented out in /etc/pulse/defaul.pa.

$ more /etc/pulse/default.pa
### Publish connection data in the X11 root window
#.ifexists module-x11-publish.so
#.nofail
#load-module module-x11-publish
#.fail
#.endif

This was done in commit 3888bfcccd8324d23a7bc31ebb2d8063d9da1aaf with the commit message »enable exit-on-idle by default«. I cannot grasp the reasons behind this though. Maybe because it should not be loaded when running without X and one is supposed to use start-pulseaudio-x11 if a X server is running.

I do not know why module-x11-publish is loaded when my system starts

Anyway loading this module manually

$ pacmd
Welcome to PulseAudio! Use "help" for usage information.
>>> load-module module-x11-publish

seems to publish the credentials just fine.

$ xprop -root | grep ^PULSE_
PULSE_SESSION_ID(STRING) = "1572dc2ca76ca04c3351599547f539a6-1265011784.364806-1969959962"
PULSE_ID(STRING) = "1000@1572dc2ca76ca04c3351599547f539a6/24717"
PULSE_COOKIE(STRING) = "aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20"
PULSE_SERVER(STRING) = "{1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native"

$ pax11publish -d
Server: {1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native
Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20

1. Can module-x11-publish be loaded conditionally if a X server is running? It seems to be the task of the desktop environment, but as we have seen sometimes the PA server is killed and started automatically (autospawn = yes) or manually (autospawn = no).

To do some further tests I killed the PA server again and tried your suggestion to export the PA server credentials manually after starting the PA server again (without module-x11-publish).

$ pax11publish -e
PULSE_COOKIE(STRING) = "aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20"
PULSE_SERVER(STRING) = "myhostname"

$ pax11publish -d
Server: myhostname
Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20

So it looks a little bit different then from the beginning. Cookie has the same value, but the other information are all different or are not set. The problem with gstreamer-properties and mplayer are the *same* as in my original report, i. e. the connection is refused for them. I found out that paplay has the same problem.

$ LANG=C paplay song.flac
Connection failure: Connection refused

After killing this PA server (started with pulseaudio -vvvvv) with pulseaudio -k the credentials are not removed.

$ pulseaudio -k
$ pax11publish -d
Server: myhostname
Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20

2. It looks like pax11publish fails to publish the correct credentials as module-x11-publish is doing. Is that a bug?

Or running start-pulseaudio-x11 after killing PA

That one works because module-x11-publish is loaded when starting PA server with start-pulseaudio-x11.

$ LANG=C start-pulseaudio-x11
I: main.c: Daemon startup successful.
$ pax11publish -d
Server: {1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native
Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20
$ LANG=C paplay song.flac
$ # plays until end

(or after running it in the terminal manually - i.e. run start-pulseaudio-x11 in another term while the -vvv manual run is happily sitting and waiting)

I do not know what you mean by »sitting and waiting«. But if I run pulseaudio -vvvvv before in another terminal, running start-pulseaudio-x11 does not work.

$ LANG=C start-pulseaudio-x11
I: main.c: Daemon startup successful.
[(With `--daemonize=no` we get the reason.) E: pid.c: Daemon already running.]
Failure: Module initalization failed

3. This error message is in my opinion confusing. »E: pid.c: Daemon already running.« should be printed as the error.

Both methods should fix up the X11 settings that the client uses when connecting... Not certain this is the problem, but I suspect it's something in this area.

I think you were spot on and probably the instructions in the Wiki should be changed on how to start a PA server with a X server running.

PS: I hope publishing my PA cookie in this ticket will not have any security consequences for me. If you please tell me.

[coling]

Replying to PaulePanter:

Replying to coling:

Chances are your X11 properties are somehow out of sync with the running PA. This shouldn't really happen but does pax11publish -r help?

Did you mean pax11publish -e to export the information to the X11 root window?

That would work too, but -r removes the properties. At this point PA would likely fallback to the env vars of conf file (both of which are unlikely to be set unless you are specifically setting them).

I did not know about pax11publish. The manual page lists xprop -root | grep ^PULSE_ to dump the raw information. pax11publish -d seems to output the Server and Cookie nicely formatted. So with the PulseAudio server started by my GNOME session(?) I got.

It's started via XDG (to which Gnome session init conforms) at X11 login. The start-pulseaudio-x11 script is run and as a result the various x11 modules are loaded into the PA server. These modules are purely optional and only provide increased functionality for X11 users (PA can happily be started on the console too).

Killing pulseaudio -k and starting PulseAudio pulseaudio -vvvvv with autospawn = no resulted in the following.

So the PA server credentials were not published to the X root window. Wondering why, I noticed in the log or with list-modules in pacmd that module-x11-publish was not being loaded. It is commented out in /etc/pulse/defaul.pa.

It's not meant to be loaded via default.pa. See the start-pulseaudio-x11 script. As mentioned above PA should start and work via non-x11 sessions too.

This was done in commit 3888bfcccd8324d23a7bc31ebb2d8063d9da1aaf with the commit message »enable exit-on-idle by default«. I cannot grasp the reasons behind this though. Maybe because it should not be loaded when running without X and one is supposed to use start-pulseaudio-x11 if a X server is running.

Yes, that is the logic.

I do not know why module-x11-publish is loaded when my system starts

See above. start-pulseaudio-x11 is started at your X11 login via XDG.

Anyway loading this module manually

The cookies all match so it's likely not the problem.

1. Can module-x11-publish be loaded conditionally if a X server is running? It seems to be the task of the desktop environment, but as we have seen sometimes the PA server is killed and started automatically (autospawn = yes) or manually (autospawn = no).

Well it's generally not a problem. PA shouldn't crash (if it does we should fix those problems) and if you run PA manually you should be aware of what you are doing etc. etc. I'm not sure what effect including the modules in the default.pa within a .nofail block would have tho'. It may be enough to "just work" for the majority of cases.... I can think of some problems tho' e.g. connecting to a remote machine via X11 from a machine without PA, starting PA remotely, getting the root window (via SSH) properties set and then logging out. The initial machines PA related preferences will then be all messed up.

To do some further tests I killed the PA server again and tried your suggestion to export the PA server credentials manually after starting the PA server again (without module-x11-publish). {{{ $ pax11publish -e PULSE_COOKIE(STRING) = "aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20" PULSE_SERVER(STRING) = "myhostname" }}} {{{ $ pax11publish -d Server: myhostname Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20 }}} So it looks a little bit different then from the beginning. Cookie has the same value, but the other information are all different or are not set. The problem with gstreamer-properties and mplayer are the *same* as in my original report, i. e. the connection is refused for them. I found out that paplay has the same problem.

Likely all PA clients will have the same problem. This is not something that should affect one client but not another unless that client is specifically written to do something strange.

What is interesting here tho' is the fact that the socket path is not published. This means that in order for these settings to work, you *MUST* enable TCP connections. This seems very strange and I can't help but wonder why the local socket path is not included here..... (it seems this is the underlying problem with this particular "connection refused" which may or may not be the same as the original problem you are reporting).

After killing this PA server (started with pulseaudio -vvvvv) with pulseaudio -k the credentials are not removed.

That's expected. The PA server didn't set them, the pax11publish command did. So PA server will not remove them, the pax11publish -r command should.

{{{ $ pulseaudio -k $ pax11publish -d Server: myhostname Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20 }}} 2. It looks like pax11publish fails to publish the correct credentials as module-x11-publish is doing. Is that a bug?

I'm not sure. Perhaps. It depends on what pax11publish is really meant to do. I guess it's used primarily as a tool for connecting remotely so perhaps doesn't need to worry about local connections. But by the same token, I can't think of a reason why it would *not* include the local socket path either.

Or running start-pulseaudio-x11 after killing PA

That one works because module-x11-publish is loaded when starting PA server with start-pulseaudio-x11.

I know, that's why I suggested pax11publish -r or this method. -r would remove all X11 properties and basically take the X11 part of the config completely out of the equation...

{{{ $ LANG=C start-pulseaudio-x11 I: main.c: Daemon startup successful. $ pax11publish -d Server: {1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native Cookie: aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20 $ LANG=C paplay song.flac $ # plays until end }}}

So this suggests that you do not have TCP support enabled. That's fine. I guess you shouldn't run pax11publish (except with the -r command) until the scope of that tool has been confirmed and we can either open a bug or document it.

(or after running it in the terminal manually - i.e. run start-pulseaudio-x11 in another term while the -vvv manual run is happily sitting and waiting)

I do not know what you mean by »sitting and waiting«. But if I run pulseaudio -vvvvv before in another terminal, running start-pulseaudio-x11 does not work.

Are you sure?

{{{ $ LANG=C start-pulseaudio-x11 I: main.c: Daemon startup successful. [(With --daemonize=no we get the reason.) E: pid.c: Daemon already running.] Failure: Module initalization failed }}}

That doesn't mean the command wasn't successful. Using daemonize=no is going to create problems..... please don't turn that on. The start-pulseaudo-x11 script is *not* just trying to start the PA server. It will start it if it is not running, but it will happily accept the fact that it is started already. If you subsequently get a module initialisation problem, then it suggests you have actually run the script *twice* or have the x11 modules listed in default.pa which is non-standard (as loading two of the X11 modules for the same $DISPLAY is not meant to work, so failing to load the module is expected).

3. This error message is in my opinion confusing. »E: pid.c: Daemon already running.« should be printed as the error.

It's not the error. The whole point in the --start argument is to start the server if it's not running and to be quite happy if it's not. Don't set daemonize=no and no error is printed (as is correct - daemon already running is a good and valid outcome!).

Both methods should fix up the X11 settings that the client uses when connecting... Not certain this is the problem, but I suspect it's something in this area.

I think you were spot on and probably the instructions in the Wiki should be changed on how to start a PA server with a X server running.

There is not much to tell here. I think you've managed to over analyse the problem somewhat by not doing pax11publish -r at the beginning as I suggested and then didn't really appreciate what all the various scripts etc were meant to do and where the x11 modules should be used. I guess it's valid to put this info on the Wiki, but it's not information you generally want regular users to see as a first port of call. 99.99% of users wont care or want to know about this. It's only when you get into problems and fiddle with configurations that you get into this situation.

So what I would do is this:

1. Make sure your default.pa and daemon.conf are pristine and what we ship. Do not try to load X11 modules in there.
2. Boot up normally.
3. Before issuing your first pulseaudio -k, check xprop -root | grep PULSE to see what the values are and ensure that a socket path is indeed present, not just a hostname.
4. Issue pulseaudio -k, pulseaudio -vvvv
5. Things should still work (the socket path shouldn't change when stopping and restarting the PA server. If it does then this is where your problem lies).
6. If things do not work, issue pax11publish -r to *remove* the X11 properties. Confirm with xprop command.
7. Do things work now?
8. If things do not work, try start-pulseaudio-x11 (keeping the dameon running under -vvvv in your other terminal). The first time this script is run it should *not* produce any errors. Do things work now? If so, then the problem is very likely in your client.conf file (either /etc/pulse/client.conf or ~/.pulse/client.conf). It likely has a default-server specified. Under normal circumstances the X11 properties will take configuration precedence as part of a regular login. When you issue pulseaudio -k these properties will be deleted by the x11-publish module when it unloads. When you run pulseaudio -vvvv the properties will not be set (as expected) and as such we will fall back to the default case (check env vars, x11 props, client.conf then built in defaults). The built in defaults should work, but I'm guessing it's getting tripped up at the client.conf stage.

I hope that make sense. It's long winded I appreciate and the configuration steps are a little confusing to get your head round. I wrote all this up here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/

PS: I hope publishing my PA cookie in this ticket will not have any security consequences for me. If you please tell me.

Well if you enable a public facing tcp connection to PA someone could evesdrop on all your sound (VoIP calls etc.) or play some really bad tunes on your speakers.... it's the latter I'd be most worried about :p Just delete your ~/.pulse-cookie and restart and it'll generate a new one.

[PaulePanter]

Replying to coling:

Replying to PaulePanter:

Replying to coling:

[…]

Both methods should fix up the X11 settings that the client uses when connecting... Not certain this is the problem, but I suspect it's something in this area.

I think you were spot on and probably the instructions in the Wiki should be changed on how to start a PA server with a X server running.

There is not much to tell here. I think you've managed to over analyse the problem somewhat by not doing pax11publish -r at the beginning as I suggested and then didn't really appreciate what all the various scripts etc were meant to do and where the x11 modules should be used.

Thank you for your detailed response.

I guess it's valid to put this info on the Wiki, but it's not information you generally want regular users to see as a first port of call. 99.99% of users wont care or want to know about this. It's only when you get into problems and fiddle with configurations that you get into this situation.

I meant the Wiki pages like [Wiki:Troubleshooting], [Wiki:Community#BugsPatchesTranslations Community] or on debugging where you are told to kill the PA server. But it looks like that will not be necessary, because I think it is working and it was an error on my side.

So what I would do is this: 1. Make sure your default.pa and daemon.conf are pristine and what we ship. Do not try to load X11 modules in there.

No X11 modules are loaded from there and I never changed it, so they are pristine.

2. Boot up normally. 3. Before issuing your first pulseaudio -k, check xprop -root | grep PULSE to see what the values are and ensure that a socket path is indeed present, not just a hostname.

As before everything is set. My problem was just that it did not work after killing the PA server to debug ticket:758.

$ xprop -root | grep PULSE
PULSE_COOKIE(STRING) = "aa0cf9aa0ba2703f23be6741b64a9521bc460d6943b03c878fba145ce8823ff46253a04361b89cffd1a339293f09d1ae446297ca43129d58214f27e3acd54d643803da7cf9aca2455fac684f2323856b10d76186cdbbca8942e12d0c0f64f5202ac1d15714f6afc6335d6b3853ffe1024f1422e1d0390a44c4da8e4b02e56e270a23e4f0e95504cd22a1c0c080c01b9f3f7de653c8e5d25d0308e46d24439b66a5bc9363830eb8fe0b8e4e57483427437307e864528ea304d0f5f6c382e4113b7bed540371170ec1dab36f1d75dce14671c4a69871d8af336c47b1c1a0822a9d7066507aff52de158b7b796afcde280919a0dbce5a69fbc40cbc87d43edf1c20"
PULSE_SERVER(STRING) = "{1572dc2ca76ca04c3351599547f539a6}unix:/home/joe/.pulse/1572dc2ca76ca04c3351599547f539a6-runtime/native"
PULSE_SESSION_ID(STRING) = "1572dc2ca76ca04c3351599547f539a6-1265045213.7191-1110412686"
PULSE_ID(STRING) = "1000@1572dc2ca76ca04c3351599547f539a6/3617"

4. Issue pulseaudio -k, pulseaudio -vvvv 5. Things should still work (the socket path shouldn't change when stopping and restarting the PA server. If it does then this is where your problem lies).

What?! Things are working now. But I am sure they did not when I tried it last time. Especially since I did not know about all those scripts/options before.

The credentials for X server are also removed. (That is the same behavior as before.)

$ xprop -root | grep PULSE
$

I think I know where I screwed up. I had default-server=localhost:30002 set in ~/.pulse/client.conf which I think was added by X2go client for PA playback when I tried this feature. (I did not run a X2go client or a X2go session when having this problem and debugging it.) So that might be the reason why it did not work out in the beginning (initial post) and it could not connect. But I removed that line after seeing it with pax11publish -d and then I did not try to test again if it worked and only looked if the X11 credentials were set with xprop -root | grep ^PULSE_ and ran pax11publish -e right after that. That was my error. I made the false assumption that those values have to be set. But that is not the case. The application’s PA plugin can find the PA server automatically. Sorry for that!

6. If things do not work, issue pax11publish -r to *remove* the X11 properties. Confirm with xprop command. 7. Do things work now?

Sorry for not following your first suggestion. It made absolutely no sense to me that I should remove those credentials because xprop -root | grep ^PULSE_ did not return anything before. That was my other false assumption that you meant to publish the X11 credentials with -e which does not seem to work correctly locally.

8. If things do not work, try start-pulseaudio-x11 (keeping the dameon running under -vvvv in your other terminal). The first time this script is run it should *not* produce any errors. Do things work now? If so, then the problem is very likely in your client.conf file (either /etc/pulse/client.conf or ~/.pulse/client.conf). It likely has a default-server specified. Under normal circumstances the X11 properties will take configuration precedence as part of a regular login. When you issue pulseaudio -k these properties will be deleted by the x11-publish module when it unloads. When you run pulseaudio -vvvv the properties will not be set (as expected) and as such we will fall back to the default case (check env vars, x11 props, client.conf then built in defaults). The built in defaults should work, but I'm guessing it's getting tripped up at the client.conf stage.

You are spot on again. I screwed this all up by running pax11publish -e before.

I hope that make sense. It's long winded I appreciate and the configuration steps are a little confusing to get your head round. I wrote all this up here: http://colin.guthr.ie/2009/08/sound-on-linux-is-confusing-defuzzing-part-2-pulseaudio/

Nice post. Maybe this should be linked from somewhere.

Thank you for your tremendous help everyone and sorry for all this and your time. I am closing this ticket as invalid.

One last question. Should I open a separate ticket regarding pax11publish for a local PA server?

[coling]

Great. Glad it was ultimately a config problem :)

For your piece of mind (and your/mine/everyones sanity!) I think running pulseaudio --start will now verify if a default-server is specified (e.g. via any config mechanism) and if so, it will not start a local PA. This would not have solved your problem but it would have stopped a local PA being started at all and thus you would have continually received connection refused errors from the get go rather than only after killing and running manually which would probably have been easier to configure.

I'll probably write a little tool that dumps the client credentials so that we can ask people to run it when they encounter similar problems.

As for the pax11publish, yes I think that warrants a bug report. I just tested it here:

1. Fresh login, PULSE_SERVER prop is nicely verbose and contains local, tcp4 and tcp6 connection strings
2. pax11publish -r
3. pax11publish -e
4. Now the PULSE_SERVER prop just says my hostname. Ugg.