[pulseaudio-discuss] module-tunnel.c: Server signalled buffer overrun/underrun

[Antoine Martin]

Colin Guthrie wrote:
> 'Twas brillig, and Antoine Martin at 28/09/09 07:53 did gyre and gimble:
>> Hi,
>>
>> I am trying to get some apps to talk to a seconday pa server, and
>> redirect the output of that server to another (ie: the regular pa server
>> on my machine) using pactl when desired, and fallback to null-sink when
>> not present.
>>
>> I start the new server with:
>> pulseaudio -n --start -vvvv --daemonize=false --system=false
>> --use-pid-file=false --exit-idle-time=-1 --load=module-null-sink
>> --load=module-rescue-streams "--load=module-native-protocol-unix
>> socket=/tmp/testpulse"
>> So far, so good. I can play files - they just get sent to /dev/null
>>
>> Now, when I try to tell this new server to add a new sink which points
>> to my existing pa server (which I also tested, and also works fine on
>> its own), I use:
>> pactl -s /tmp/testpulse load-module module-tunnel-sink
>> server=unix:/tmp/pulse-sJWIUwdZZeny/native sink_name=pulse_main
>>
>> Unfortunately, the new pa server seems to get into a spin:
>>
>> I: sink.c: Created sink 1 "pulse_main" with sample spec s16le 2ch
>> 44100Hz and channel map front-left,front-right
>> I: source.c: Created source 1 "pulse_main.monitor" with sample spec
>> s16le 2ch 44100Hz and channel map front-left,front-right
>> D: module-tunnel.c: Thread starting up
>> D: rtpoll.c: Acquired POSIX realtime signal SIGRTMIN+28
>> I: module.c: Loaded "module-tunnel-sink" (index: #3; argument:
>> "server=unix:/tmp/pulse-sJWIUwdZZeny/native sink_name=pulse_main").
>> D: module-tunnel.c: Connection established, authenticating ...
>> D: module-tunnel.c: Protocol version: remote 14, local 14
>> D: module-tunnel.c: Connection authenticated, creating stream ...
>> I: client.c: Freed 0 "pactl"
>> I: protocol-native.c: Connection died.
>> D: module-tunnel.c: Stream created.
>> D: module-tunnel.c: Server reports playback started.
>> I: module-tunnel.c: Server signalled buffer overrun/underrun.
>> D: module-tunnel.c: Server reports playback started.
>> I: module-tunnel.c: Server signalled buffer overrun/underrun.
>>
>> [repeated hundreds of times]
>>
>> D: module-tunnel.c: Server reports playback started.
>> I: module-tunnel.c: Server signalled buffer overrun/underrun.
>> W: module-tunnel.c: Stream died.
>> I: module.c: Unloading "module-tunnel-sink" (index: #3).
>> D: module-rescue-streams.c: No sink inputs to move away.
>> D: module-rescue-streams.c: No source outputs to move away.
>> D: module-tunnel.c: Thread shutting down
>> I: sink.c: Freeing sink 1 "pulse_main"
>> I: source.c: Freeing source 1 "pulse_main.monitor"
>> I: module.c: Unloaded "module-tunnel-sink" (index: #3).
>>
>> Am I missing something obvious?
>> I thought the module-tunnels-sink should be straightforward to enable,
>> ultimately I want to use it through a vpn/tunnel, but if I can't get it
>> to work with plain unix sockets... there's not point in even trying that
>> is there?
> 
> Odd. I've never tried this setup but I can't see why this would cause
> problems.
Indeed, that was only meant as a PoC for network streams... Nothing fancy.

> You may have to dig through the code and work out why the under/over
> runs are being signalled.
What is really odd (and that I forgot to mention) is that both servers
are idle: not playing anything as I didn't get that far.
So why would I get overruns/underruns?
There shouldn't be any data exchanged apart from the initial handshake,
or just occasional sync packets of some sort (dunno the inner workings
of PA).

I've just tried calling paplay and it eventually timed out without playing.

> In an ideal world module-tunnel-* would work
> in a glitch free way (e.g. dynamic buffer adjustment to compensate for
> when underruns occur etc. which would help smooth out any network issues
> too and as a side effect, probably solve this problem.
> 
> You maybe want to narrow down as to whether it is an under or an overrun
> that is occurring if you can.
> 
> 
> So I don't have a magic bullet, but for the record, rather than loading
> module-null-sink, you probably want to load module-always-sink. This
> module is specifically designed to keep a null sink loaded whenever a
> real sink (e.g. a tunnel or another null sink) is not present. This
> means that you'll probably get the automatic switching between the real
> and a dummy device that you want.
Thanks, that's much smaller/better.

Antoine

> Of course that's all irrelevant if the
> actual tunnel is playing up!
> 
> Col
>