How do I debug issues with Pulse Audio?

I have installed Ubuntu 11.10 in my machine. I have logged in as USER_A. My external audio device is a Headset and I was able to hear the audio properly.

I need to join my Ubuntu machine to a window's domain (my office server). I followed the steps explained in http://www.ghacks.net/2010/04/21/join-a-ubuntu-machine-to-a-windows-domain/ and was successful in joining my ubuntu machine to the windows domain.

sudo apt-get install likewise-open5
sudo domainjoin-cli join DOMAIN USER_B

Now when I logged in as USER_B, there is no audio for this user in the same machine.

I crossed check with my User_A account. There is no issues with the sound for User_A. Only for User_B, there is no audio.

When I checked the sound settings of User_B, there is no device listed in Hardware, Input and Output. Whereas for User A, my Headset is listed in Input and Output.

Can anyone please help me on this. Why there is no sound for User_B?

Can you please brief me a little more on how to 'Check whether users are added or not in the audio group'.

And also when I tried to execute pulseaudio -k in a terminal (from User_B)

E: [pulseaudio] main.c: Failed to kill daemon: No such process

And also I have found this on pulse audio log. When I run:

pulseaudio --log-level=4 --log-target=stderr

I found the following error lines in my log:

E: [pulseaudio] module-dbus-protocol.c: dbus_server_listen() failed: org.freedesktop.DBus.Error.BadAddress: Abstract socket name too long
E: [pulseaudio] module-dbus-protocol.c: Starting the local D-Bus server failed.
E: [pulseaudio] module.c: Failed to load module "module-dbus-protocol" (argument: ""): initialization failed.
E: [pulseaudio] main.c: Module load failed.
E: [pulseaudio] main.c: Failed to initialize daemon.

Solution 1:

This preliminary answer summarizes steps involved to debug sound available for one user only in an environment where domains were joined for this user. It may need be extended later.

In case we have sound for one user only we may have some bad configuration in this one user account's setting. We need to take the following steps from the affected user account to get further insights into the problem.

1. Is pulseaudio running at all?
   Usually you will see that from having access to the sound menu in the top bar. Alternatively we can issue the following command in a terminal:

   pulseaudio -k
   

   There will be an error in case pulseaudio does not run. In addition this command takes care of stopping and respawning pulseaudio in case it hangs.

2. Are there wrong user settings for the pulseaudio daemon?
   To test this we have to rename the settings directory in the affected user's HOME followed by a restart of pulseaudio (see 1.):

   mv ~/.pulse ~/.pulse.bad
   

   or

   mv ~/.config/pulse ~/.config/pulse.bad  ## for newer releases
   

3. Are channels muted from ALSA?
   We may open the alsamixer in a terminal to adjust channel volumes, and to unmute a channel in case it was accidentally muted:

   alsamixer
   

4. Make sure users are not in the 'audio' group
   A user in the audio group has exclusive access to the pulseaudio server. Other users can not access it while this user uses it. Therefore user should not be in the audio group.

5. Start Pulseaudio manually
   In case pulseaudio was not running we can also start the daemon from command line with

   pulseaudio -D
   

   Pulseaudio then uses default settings and starts it's daemon. We can also put this command to our Autostart Applications to overcome the case when pulseaudio fails to run before the desktop was loaded.

6. Browse log files
   Pulseaudio will be loaded on system start up, and on user login. Therefore errors can only be read from a log generating on starting pulseaudio. See this guide on how to generate a pulsaudio log script. In short, we have to take care pulseaudio does not respawn we may run it in verbose mode:

   pulseaudio -vvvv <options>
   

_{to be completed}

In the case given in the question we could see that pulseaudio fails to run because it was unable to start the D-Bus service. This may likely be caused by a broken or overlong path to the user's HOME (see bug #872992). As a workaround we may issue pulseaudio without D-Bus control by commenting out the following line in /etc/pulse/default.pa like this:

# load-module module-dbus-protocol

However then we (and our applications) will not be able to control pulseaudio using D-Bus.

Solution 2:

on my Debian system, I was able to get this working after, on the advice of someone smarter than me, copying (as root) the $HOME/.pulse/ folder and $HOME/.pulse-cookie files from $USER_A to $USER_B, chowning them appropriately.