[pulseaudio-discuss] native-protocol-tcp vs esound-protocol-tcp
antoine at nagafix.co.uk
Mon May 10 22:21:20 PDT 2010
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
> 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:
Does this mean that I have to use another module to create the new
Using a ladspa plugin? Are there any examples anywhere?
>> $ pactl load-module module-native-protocol-tcp port=12422 sink=1
>> "Failure: Module initalization failed"
> 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
Can I force unload the module if it is in use?
More information about the pulseaudio-discuss