[pulseaudio-discuss] native-protocol-tcp vs esound-protocol-tcp

Antoine Martin antoine at nagafix.co.uk
Tue May 11 13:48:24 PDT 2010

On 05/11/2010 11:29 PM, Tanu Kaskinen wrote:
> On Tue, 2010-05-11 at 12:21 +0700, Antoine Martin wrote:
>> Add-to-wishlist: ability to use codecs here would be nice. I doesn't
>> look like I can use ladspa plugins over the tunnel, or can I? If so, how?
>> 1.4Mbit/s is a little high when most modern cpus can compress audio to
>> 192Kbit/s on the fly without consuming any significant amount of CPU.
> The lack of compression is a known bug :) AFAIK nobody is currently
> working on the feature, though.
That's a shame.
Especially since it consumes the whole bandwidth allocation whether 
actual sound is being played or not! Ouch.
Well, at least when using an ssh tunnel with CompressionLevel=9 you can 
reduce that down to around 220Kbit/s when idle. (from 1.4Mbit/s) I 
haven't tried with single-channel 22KHz yet.

The SSH transport is not the best place to be doing this sort of 
Aren't there any open-source codec frameworks that could easily be 
plugged into the tcp transport?
>>>> Is there a way to reduce the bandwidth used if I know in advance that
>>>> the line is not going to be able to sustain it? (via some kind of
>>>> filter? for my use case, horrible sound quality is better than getting
>>>> disconnected! think<512Kbit/s)
>>> You can run pulseaudio servers locally on the clients and create tunnel
>>> sinks. You can configure the tunnel sinks to use a lower-quality stream
>>> format (e.g. mono 22050 kHz ->   ~350 kbit/s).
>> Can you expand on that?
>> I see no options for changing the bitrate in tunnel:
>> http://pulseaudio.org/wiki/Modules#module-tunnel-sinksource
>> Does this mean that I have to use another module to create the new
>> source first?
> Module-tunnel-sink accepts the generic device options listed in the
> beginning of the Modules page. (Yes, the documentation isn't very clear
> about this.)
Hah, yes, not obvious at all!
The documentation for other modules say things like " See module ...." 
or "In addition to ... this module supports", but this one doesn't.
> So on the sound-producing client you would put something like this in
> default.pa:
> load-module module-tunnel-sink server=localhost:12345 sink=<name_of_the_sink_at_the_other_end>  sink_name=tunnel_output rate=22050 channels=1 channel_map=mono
> The server parameter points to the remote server, except I guess with
> ssh tunneling you're going to use localhost (I'm not too familiar with
> ssh tunneling)? The sink parameter tells the module which sink at the
> remote end should receive the stream. The sink_name parameter gives an
> identifier for the local sink - you can choose the name quite freely.
> The rest of the parameters define the stream format. The channel_map
> parameter is probably redundant - Pulseaudio should be able to guess
> that you want a mono stream based on the fact that the channels
> parameter has value "1".
OK, this may help others to have a simple example, so here is what I've 
used for barebones tunnel setup:

On the box that is going to receive the audio (
$ pactl load-module module-native-protocol-tcp port=12345 auth-anonymous=1
Identified the sink name I want to use (there is only one):
$ pacmd list-sinks | grep name:
   name: <alsa_output.pci-0000_00_1b.0.analog-stereo>

Then on the box that wants to send the audio (
$ pactl load-module module-tunnel-sink server= 
sink=alsa_output.pci-0000_00_1b.0.analog-stereo sink_name=tunnel_sink

If you want to use an SSH tunnel you can do:
ssh -L 54321:
Or if doing it from the other end with a reverse tunnel:
ssh -R 54321:
Then all you have to do is point to ''

If you want to add authentication, change auth-anonymous=0
Just add your cookie file as "auth-cookie=" parameter to 
And add "cookie=" param to module-tunnel-*
(obviously the contents of the cookie file need to be identical)

> Btw, what kind of setup is this? Speeds that are below 512 kbps don't
> sound like a reliable link.
Well, in the part of the world I am in at the moment, this is what you 
get... I occasionally get more (up to ~2Mbps), but it is generally not 
I don't expect the software I have written to be used on such slow lines 
very often... But it would be nice not to completely DoS the line during 
>   My understanding is that Pulseaudio doesn't
> perform well on links where packets are dropped often, or where
> latencies vary a lot.
Dropped packets aren't a huge problem here, latency to the rest of the 
world can be pretty bad though...

Anyway, for the testing above I am doing everything on a LAN, I just 
want to ensure that I can cope with slow WANs too if needed.
>>>> Finally, is there a way to change the auth-cookie on the fly?
>>>> (with/without disconnecting clients if possible)
>>>> So that I can revoke the access that I had previously granted to a
>>>> remote user.
>>> I don't see other way than revoking the ssh access for the evil user
>>> altogether.
>> Can I force unload the module if it is in use?
> Sorry, I don't really understand the question. Which module are you
> talking about? Module-tunnel-sink? The module is loaded on the client's
> machine, which means that no, you can't unload that from the server
> machine.
I've just tried and I can unload the module-native-protocol-tcp even 
when there is a tunnel-sink connected to it, which does the job.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pulseaudio-discuss/attachments/20100512/53a305e4/attachment.htm>

More information about the pulseaudio-discuss mailing list