[pulseaudio-discuss] pavucontrol -- server selection?

Paul Fox pgf at foxharp.boston.ma.us
Mon Feb 25 05:22:05 PST 2008

colin wrote:
 > David KÃ¥gedal wrote:
 > >Paul Fox <pgf at foxharp.boston.ma.us> writes:
 > >> well, i was about to point out that i'd already tried PULSE_SERVER,
 > >> but i tried it again, and now it works.  dammit.  :-)
 > >>
 > >> i have no idea why it didn't work before.  i found the command in
 > >> my shell history to re-run it, so it wasn't a typo.  i've used pulse
 > >> to listen to some music in the meantime, but i'd be surprised if that
 > >> affected how pavucontrol works.  :-/
 > >>
 > >> well....  wait.  it now works remotely, but not locally.
 > >>
 > >> okay.  i'm confused.
 > > 
 > > It sounds like you need to show us exactly the commands you
 > > run. Starting from a fresh shell.

yes, sorry, i certainly should have done that.

 > Yeah I think you may not be using/understanding "export" correctly.

thanks.  i'm a unix veteran -- but you wouldn't have known that
from my meager problem report.  i was frustrated last night, and
didn't present all of the information properly.  my fault.

 > From a fresh shell you can do:
 > $ PULSE_SERVER=xxx.xxx.xxx.xxx pavucontrol

this is exactly the form i tend to use, except for using hostname
instead of ip address:
   $ PULSE_SERVER=pulseserver pavucontrol

looking back on it, i think i was hitting several problems at once,
only one of which still exists:

    1) initially, i think the pulseaudio server had died, and i
	didn't realize this when trying to connect remotely.  it
	seems to die fairly often -- i think i need to run it
	from init to keep it going at all times.  so naturally
	running this failed:
	    $ PULSE_SERVER=pulseserver pavucontrol

    2) when i moved to the server machine, and tried to connect
	locally using just the command:
	    $ pavucontrol
	(i.e. not specifying a server) i was distractd by a cookie
	permission error:

	    E: authkey.c: failed to open cookie file \
	    	'/home/pgf/.pulse-cookie': Permission denied

	i eventually tracked that down to ~/.pulse-cookie being
	owned by root.  since i run pulseaudio in system mode, i
	simply deleted the cookie to fix this problem.  but in the
	process of debugging it, i believe i restarted the
	pulseaudio server, and it's quite possible i didn't retry
	a remote connection after that point.

    3) at this point, the only problem left was that local connection
	on the server still didn't work.  i.e., this works:
	   $ PULSE_SERVER=localhost pavucontrol
	but this doesn't:
	   $ pavucontrol

	this is still the case, right now.
is it perhaps the case that when running in system mode, the
server must always be specified explicitly?  i don't recall
reading this anywhere, but i can imagine it might be the case.

(this notion of each user running a "personal" copy of a sound
daemon seems odd to me, but i'm sure i'll understand it in time.
right now i have no need for that capability.  since the daemons
are part of my home automation and audio distribution system --
there's nothing "per-user" about my audio needs.)

many thanks for your patience.

 paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 23.0 degrees)

More information about the pulseaudio-discuss mailing list