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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@mail.0pointer.de
https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
