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>
