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
