[pulseaudio-discuss] Choose remote default sink fromcommandline?

[Tanu Kaskinen]

On Tue, 2010-11-09 at 10:42 -0500, Dave wrote:
> At 05:31 AM 11/9/2010, you wrote:
> > > I tried adding each of the following (one at a time of course) to
> > > ~/.bashrc and none of these variations worked:
> > >
> > > export PULSE_SERVER=192.168.1.64
> >
> >This is the only form you need. I presume you logged out and back in
> >again after setting this env var?
> >
> >Try this on the command line and post the results:
> >
> >export PULSE_SERVER=192.168.1.64
> >export PULSE_LOG=99
> >paplay -vvv /usr/share/sounds/startup3.wav
> 
> jmrt at ubuntu-JMRT:~$ export PULSE_SERVER=192.168.64
> jmrt at ubuntu-JMRT:~$ export PULSE_LOG=99
> jmrt at ubuntu-JMRT:~$ paplay /usr/share/sounds/purple/logout.wav
> D: memblock.c: Using shared memory pool with 1024 slots of size 64.0 
> KiB each, total size is 64.0 MiB, maximum usable slot size is 65472
> D: context.c: Trying to connect to 192.168.64...
> Connection failure: Connection refused
> jmrt at ubuntu-JMRT:~$
> - No sound was played

"192.168.64" is not a valid address... I guess it's interpreted as a DNS
name. Resolving the name of course fails, but I would have expected some
other error message than "connection refused"...

Regarding the question of where to put the environment variable export
so that it's set for the whole session and not just terminal - I don't
think there's any standard place that will work everywhere. It's
possible to configure the system to have some environment variables
always set, but I don't know how it can be done specifically for your
system (I have done it in the past on my own system, but I don't
remember the specifics of that either).

But if you want to set the server address
globally, /etc/pulse/client.conf or ~/.pulse/client.conf is much better
place for configuring that than setting environment variables in some
obscure start-up script.

Also, as Colin pointed out earlier, tunnels might make more sense than
connecting directly to the remote server. If you never need to use the
local sound card, then connecting directly to the remote server is maybe
better, but if you need to switch between local and remote, then tunnels
are more convenient.

You had problems with configuring the tunnels - the command for loading
a tunnel sink is basically the following:

pactl load-module module-tunnel-sink server=192.168.1.64 sink=<remote sink name> sink_name=mytunnel

That creates a new local sink with name "mytunnel". When directing
applications to that sink the audio will be forwarded to <remote sink
name> (you'll have to figure out the remote sink name before loading the
tunnel sink module) at 192.168.1.64.

I don't remember whether the module arguments had to be put within
quotes, so try this if the first command doesn't work:

pactl load-module module-tunnel-sink "server=192.168.1.64 sink=<remote sink name> sink_name=mytunnel"

-- 
Tanu