<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 05/11/2010 11:29 PM, Tanu Kaskinen wrote: <blockquote cite="mid:1273595379.28655.1433.camel@jarl" type="cite"> <pre wrap="">On Tue, 2010-05-11 at 12:21 +0700, Antoine Martin wrote: </pre> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap=""> The lack of compression is a known bug :) AFAIK nobody is currently working on the feature, though. </pre> </blockquote> 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? <blockquote cite="mid:1273595379.28655.1433.camel@jarl" type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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) </pre> </blockquote> <pre wrap="">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). </pre> </blockquote> <pre wrap="">Can you expand on that? I see no options for changing the bitrate in tunnel: <a class="moz-txt-link-freetext" href="http://pulseaudio.org/wiki/Modules#module-tunnel-sinksource">http://pulseaudio.org/wiki/Modules#module-tunnel-sinksource</a> Does this mean that I have to use another module to create the new source first? </pre> </blockquote> <pre wrap=""> 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.) </pre> </blockquote> Hah, yes, not obvious at all! The documentation for other modules say things like " <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: 'Times New Roman'; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; font-size: medium;">See module ...." or "In addition to ... this module supports", but this one doesn't. <blockquote cite="mid:1273595379.28655.1433.camel@jarl" type="cite"> <pre wrap="">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". </pre> </blockquote> 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) <blockquote cite="mid:1273595379.28655.1433.camel@jarl" type="cite"> <pre wrap="">Btw, what kind of setup is this? Speeds that are below 512 kbps don't sound like a reliable link.</pre> </blockquote> 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! <blockquote cite="mid:1273595379.28655.1433.camel@jarl" type="cite"> <pre wrap=""> My understanding is that Pulseaudio doesn't perform well on links where packets are dropped often, or where latencies vary a lot. </pre> </blockquote> 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. <blockquote cite="mid:1273595379.28655.1433.camel@jarl" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">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. </pre> </blockquote> <pre wrap="">I don't see other way than revoking the ssh access for the evil user altogether. </pre> </blockquote> <pre wrap="">Can I force unload the module if it is in use? </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> 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 </body> </html>