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

Colin Guthrie gmane at colin.guthr.ie
Mon Sep 28 01:03:22 PDT 2009


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

You may have to dig through the code and work out why the under/over 
runs are being signalled. 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. Of course that's all irrelevant if the 
actual tunnel is playing up!

Col

-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
   Tribalogic Limited [http://www.tribalogic.net/]
Open Source:
   Mandriva Linux Contributor [http://www.mandriva.com/]
   PulseAudio Hacker [http://www.pulseaudio.org/]
   Trac Hacker [http://trac.edgewall.org/]




More information about the pulseaudio-discuss mailing list