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. > 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). > Also, I seem to be missing something on native-protocol-tcp, because I > can do this with esound: > 1) Spot my desired sink: > $ pacmd list-sinks | grep -C 1 name: > index: 0 > name: <alsa_output.1.hdmi-stereo> > driver: <module-alsa-card.c> > -- > * index: 1 > name: <alsa_output.0.analog-stereo> > driver: <module-alsa-card.c> > > 2) Start an esound tcp connected to that sink: > pactl load-module module-esound-protocol-tcp port=12345 > auth-cookie-enabled=0 sink=1 > > 3) Now, I can't seem to play anything (any ideas why?): No ideas. I'm not familiar with esound. > esdcat -s localhost:12345 < some_file.wav > echo $? > 1 > Not exactly forthcoming with the cause of the problem, but at least > esound is listening on that port. > > Whereas with native, I can't even load the module if I specify a sink: > $ pactl load-module module-native-protocol-tcp port=12421 > 32 > That worked! > $ 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 > 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. -- Tanu Kaskinen
