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