[pulseaudio-discuss] padevchooser replacement

[Colin Guthrie]

'Twas brillig, and Victor Mataré at 15/12/11 23:56 did gyre and gimble:
> So now I disabled IPv6 on avahi and module-zeroconf-discover works as
> expected. The tunnel sink to the networked server however doesn't. E.g.
> with Xine, I get severe synchronization problems (stuttering and
> skipping sound). Sometimes I can switch from local to networked playback
> no problem, but when I switch back to local the playback halts for ~10
> seconds. Repeat and Xine freezes entirely.
> The Youtube player doesn't even work at all when using the networked
> sink. Sound is played fine, but video is frozen.
> All this used to work nicely when the client connects to the networked
> server directly. Now I'm not sure if these are client implementation
> problems or pulseaudio bugs. Any idea how to investigate further?

It's usually a combination of both. It's certainly true that the tunnel
module adds more overhead (that's the cost of the flexibility I guess),
and it could certainly benefit from optimisation (hell, it's long been
mooted that we should use a proper RTP-ish setup for tunnel stuff with
separate control and data channels.

But ultimately the clients do need to be have better too. Many clients
work by the grace of good luck rather than by design. They do not do
proper adjustment for latency and cope with the values reported to them.
Xine is certainly one of these. It's PA output is shocking and always
has been. I've generally recommended that people avoid Xine anyway
seeing as it's a dead project (even if some people try and keep it on
life support). There are better options out there than Xine.

Flash is a pain as it's closed source and Adobe are generally pretty
poor at doing anything with upstream projects even if we do try and goad
them all the time. They are just really, really poor at engaging.

> I remember reading some advice against module-tunnel-sink which said
> that you lose buffer control and that glitches became more likely. Seems
> like this hasn't changed. But then why is the direct connection way
> being deprecated?

Direct connections are not deprecated at all. padevchooser is, but
that's not anything that limits direct connections. It's generally
easier and nicer from a GUI perspective to use tunnels and it ultimately
gives you more flexibility, but if you absolutely need to use a direct
connection, then just carry on doing so.

All padevchooser did was tweak the X11 root window properties (xprop
-root | grep PULSE_SERVER). These are only read once when the client
connects and thus it ultimately provides a very patchey experience to
users, but provided you know the limitations and are happy enough to
live with them you can still take that approach.

Building a replacement for padevchooser should be trivial.


The only bit we did deprecate is libpabrowse: This should just be done
directly in avahi. No need for a wrapped up library. It was deprecated
in PA 1.0.

And we generally discourage messing with the X11 properties considering
they only affect things at client startup (for the PULSE_SERVER variable
anyway - although this is somewhat client dependant as they may
establish new connections at times other than app startup - again it's
inconsistent which is not good for user experience either). This is why
we didn't officially develop padevchooser and discourage it's use.


In an ideal world, the tunnel code would get some love and be able to
work as nicely as direct connections for the most part (there will
always be some overhead tho'). However we're massively under resourced
and, quite frankly the network support stuff is simply not at the top of
the agenda right now. We would more than welcome anyone wanting to
contribute to this area and would endeavour to help them code it.


All the best

Col


-- 

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

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/