[pulseaudio-discuss] native-protocol-tcp vs esound-protocol-tcp
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:
>> 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
> 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 (192.168.0.101).
$ 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:
Then on the box that wants to send the audio (192.168.0.100):
$ pactl load-module module-tunnel-sink server=192.168.0.101:12345
If you want to use an SSH tunnel you can do:
ssh -L 54321:127.0.0.1:12345 192.168.0.101
Or if doing it from the other end with a reverse tunnel:
ssh -R 54321:127.0.0.1:12345 192.168.0.100
Then all you have to do is point to '127.0.0.1:54321'
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
>> 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
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...
More information about the pulseaudio-discuss