[pulseaudio-discuss] module-tunnel-sink: where to start?

[Chris Hamilton]

Alright... so, I've finally got an environment with bleeding edge
everything, and am able to build and run pulseaudio from GIT.  However,
the GIT version dies right away with a PA_SINK_INPUT_IS_LINKED
assertion.  I saw a mention on trac that this is known issue, and that
there are a few workarounds, but I didn't get that far ;)  For the time
being, I elected to stick with the last 'stable' release of 0.9.13.

With 0.9.10, I was using esound tunnels to play via remote servers.
However, with 0.9.13 these die quite quickly when calling
PA_SINK_MESSAGE_GET_LATENCY.  (I thought the fact that esound tunnels
don't have latency measurement was expected behaviour?)

Anyhow, I'd really like to use native tunnels, because of their latency
measurement, so that I can play audio simultaneously across all of the
systems in my house.  My one server (the sink) is running 0.9.10, while
my laptop (the source) is running 0.9.13.  If I play audio over a tunnel
only, 9 times out of 10, everything is just fine.  Occasionally, I'll
have a glitch.  If I go to a combined sink (local ALSA and remote
tunnel), 9 times out of 10, all hell breaks loose.  Things start out
well, but a few seconds into playback, I start getting glitches on the
remote machine, which get worse and worse.  PA report a remote sample
rate estimation that is way out of whack (> 80,000 Hz) and the audio
pretty much drops out altogether.

Is this an issue that would likely go away if both ends were running
bleeding edge ALSA and PA?  Or is this something that can be addressed
in module-tunnel?  If the latter, then where would be a good place to start?

(And I still want to mock up some audio-panel pavucontrol-on-steroids
type application, but I spent 2 days this week restoring my server after
a hard-drive crash... alas, haven't had any tinkering time!)

Cheers,

Chris