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
=---------------------
paul fox, pgf at foxharp.boston.ma.us (arlington, ma, where it's 23.0 degrees)
