[pulseaudio-discuss] native-protocol-tcp vs esound-protocol-tcp

[Antoine Martin]

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