[pulseaudio-discuss] pax11publish -e -S

[Colin Guthrie]

'Twas brillig, and Matt Zagrabelny at 05/11/10 00:57 did gyre and gimble:
> On Sun, Oct 24, 2010 at 11:48 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>> 'Twas brillig, and Matt Zagrabelny at 24/10/10 11:58 did gyre and gimble:
>>> On Sun, Oct 24, 2010 at 2:01 AM, Colin Guthrie <gmane at colin.guthr.ie> wrote:
>>>
>>>> For what it's worth, when you first log into X11, PA loads the modules
>>>> module-x11-publish (via start-pulseaudio-x11), which should export the
>>>> properties you need and not require pax11publish to be run manually.
>>>
>>> I didn't mention that 'zombie' is a headless system and PA is running
>>> in system mode.
>>
>> Oh right. I didn't fully read the previous email... turns out you're
>> kinda approaching the problem in the wrong way... I'll explain below.
>>
>>>> Make sure you are not using padevchooser as it's messes about with the
>>>> x11 properties and the default setup should be sufficient for your needs.
>>>
>>> Sure. I've stayed away from padevchooser after seeing recommendations
>>> to not use it on the list. Its interface is still pretty nice, though.
>>>
>>> Just out of curiosity, is it possible to send one application to
>>> another SINK/SERVER or do you need to send all of your local audio
>>> traffic to it?
>>
>>
>> Yes. You can do this one of two ways. The first way is a bit brutal: do
>> something like:
>>  export PULSE_SERVER=zombie; my-sound-producing-application
>>
>> this will tell your app to talk _directly_ to the zombie's PA server.
>>
>> And here is where things get interesting. You probably don't _want_ to
>> get your localhost to talk directly to zombie, but rather go through a
>> "tunnel" sink. Tunnels appear in your local PA and are the same as any
>> other real output device except, as the name suggests, they are just
>> tunnels over the network to the h/w on a remote machine.
>>
>> You can load a tunnel sink via:
>>
>> pacmd load-module module-tunnel-sink sever=zombie sink_name="tunnel"
>>
>> That way you don't mess around with pax11publish, or padevchooser or
>> client.conf at all, you just play to your local PA and when you want an
>> application to output to zombie, just fire up pavucontrol and find the
>> application in question under the "Playback" tab and move it to the
>> remove device.
>>
>> You don't even really need to load the module-tunnel-sink manually as
>> you can let avahi do this for you automatically. Just ensure you have
>> module-zeroconf-publish running in your system-wide PA on zombie and
>> then load up paprefs on your localhost and tick the box that says "Make
>> discovered devices on the network available locally" or something
>> similar. This setting in paprefs will load module-zeroconf-discover in
>> your localhost PA and thus load module-tunnel-sink for you automatically
>> when it finds one. This needs a working avahi setup obviously, but you
>> can debug that with avahi-browse -ta on your local machine.
> 
> Suppose I wanted to do this without avahi?
> 
> I've done the following:
> 
> pacmd load-module module-tunnel-sink sever=zombie sink_name="tunnel"
> Welcome to PulseAudio! Use "help" for usage information.
>>>> Module load failed.
>>>> %
> 
> So I tweaked the command a little:
> 
> pacmd load-module module-tunnel-sink server=zombie:4713
> sink=alsa_output.hw_0 format=s16le channels=2 rate=44100
> sink_name=tunnel.zombie channel_map=front-left,front-right
> Welcome to PulseAudio! Use "help" for usage information.
>>>>>>> %
> 
> It looks a little better.
> 
> pactl list | grep tunnel || echo not found
> not found
> 
> But I still don't see the tunnel device. Any ideas?

I didn't realise that the tunnel module needed some of those arguments
by default but hey ho.

It looks like your module load is all correct but for some reason it
subsequently failed to connect and ultimately unloaded itself again.

You'll really need to run the daemon with verbose logging to see what
happens here.

I'd imagine there is a permission problem with talking to the remote
end. e.g. auth-anon is not set on the remote end and they are using
different cookies.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
  Mageia Contributor [http://www.mageia.org/]
  PulseAudio Hacker [http://www.pulseaudio.org/]
  Trac Hacker [http://trac.edgewall.org/]