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

[Antoine Martin]

Off-list, just to say: thank you very much!

Antoine



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.
>
>    
>> 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.
>
>