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

[Antoine Martin]

Hi,

I need to use some tcp transport (over an ssh tunnel) to forward sound 
from one box to another.
Are there any reasons to prefer native over esound?

Does anyone know what the bandwidth requirement is for either of these 
protocols?
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)

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?):
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

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.

Apologies if these questions have been covered elsewhere, I blame 
google: it couldn't find it.

Thanks
Antoine