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

[Colin Guthrie]

'Twas brillig, and Chris Hamilton at 12/12/08 18:47 did gyre and gimble:
> I apologize for the previous thread hijack... an inadvertant 'reply to'
> instead of 'compose to'.
> 
> Anyhow, the same message, but now with new thread goodness!
> 
> -----
> 
> 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.

The patches I posted work for me.... Lennart can you get the right one 
into master to save peoples hassle?
See http://www.pulseaudio.org/ticket/398

Of course another workaround is to just disable suspend on idle...

> 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?)

I would think that esound modules will still have to handle the message 
cleanly tho'. I guess this is probably a bug... I'm not familiar with 
that bit of the code tho'.

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

Don't really know but I'd guess the problem lies at the PA side rather 
than the alsa side. If you can try both sides being git master that 
would probably be best.

Also if you are using 0.9.13 please make sure you apply all the patches 
from the fedora 0.9.13 package as 0.9.13 on it's own is not perfect :)


> (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!)

Cool :) and Bummer :(


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/]