On 05/10/2010 11:50 PM, Tanu Kaskinen wrote: > On Mon, 2010-05-10 at 22:46 +0700, Antoine Martin wrote: > >> Are there any reasons to prefer native over esound? >> > The one that I know is that the esound protocol doesn't provide latency > information, which makes reliable lip-synced video playback impossible. > > >> Does anyone know what the bandwidth requirement is for either of these >> protocols? >> > It depends mostly on the number of channels, sample format and sample > rate. For the most common audio streams the raw audio takes about 1.4 > Mbit/s. On top of that there's the protocol overhead, which should be > rather small in comparison for either protocol. > 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. >> 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? Using a ladspa plugin? Are there any examples anywhere? [snip] >> $ pactl load-module module-native-protocol-tcp port=12422 sink=1 >> "Failure: Module initalization failed" >> Hmm >> > module-native-protocol-tcp doesn't take a sink argument. The modules and > their arguments are documented on http://pulseaudio.org/wiki/Modules > DOH. I must have been staring at that page too long.. > >> 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? Thanks Antoine
