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

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 
compression!
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 (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:
   name: <alsa_output.pci-0000_00_1b.0.analog-stereo>

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 
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: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 
module-native-protocol-*
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 
sustainable.
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 
testing!
>   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.

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