Split off from bug 3222 comment #30: - Audio sync is off. Tested both totem and mplayer.
Also seeing this when connecting to the demo system from a F17 machine (client build 3697). Totem has hacky playback, mplayer is smooth but audio sync is way off.
PulseAudio 3.0 is out, perhaps we should try it out.
I had a quick look at this, and it seems to be related to prebuffering. It seems like the stream fails to prebuffer sufficiently, and as a results ends up with constant underruns. The new code for this is very complex, so it's difficult to say how things are supposed to work. Will have to compare with the old code to make sense out of it.
The 4.0 upgrade makes things slightly better, although there is still some sync issues remaining. Youtube also completely refuses to play audio on our internal ThinLinc server.
Done some tests with PulseAudio 4.0 and mplayer. Buffering seems to be working correctly, but the sink latency goes bonkers now and then. This is from a sane run: 139946 160820 148458 145920 141176 159708 151744 143632 158695 153589 141244 It stays constantly at ~150 ms. And here is a run that fails: 0 0 0 0 0 0 0 0 0 0 0 0 143055 166102 158625 149045 143824 140546 160302 148017 143955 412459 638529 867677 1099646 1349557 1575456 876754 457231 671137 883336 1089101 It is just all over the place.
From what I can tell, they've spent a lot of effort into the latency measurement code for normal clients. Unfortunately they haven't ported over much of that work to the tunnel modules. And what they have ported over seems buggy.
Filed two upstream bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66855 https://bugs.freedesktop.org/show_bug.cgi?id=66857
The most grievous error fixed in r27673. Still need to look at getting feature parity with the client code. Also, Youtube is still horribly broken. Might be a completely different bug.
I've found the issue. Flash _really_ needs to have the minimum request size respected. This is from our old PulseAudio: D: memblockq.c: memblockq requested: maxlength=4194304, tlength=88200, base=4, prebuf=3528, minreq=3528 D: memblockq.c: memblockq sanitized: maxlength=4194304, tlength=88200, base=4, prebuf=3528, minreq=3528 And with the new one: D: [pulseaudio] memblockq.c: memblockq requested: maxlength=4194304, tlength=132300, base=4, prebuf=3528, minreq=44100 maxrewind=0 D: [pulseaudio] memblockq.c: memblockq sanitized: maxlength=4194304, tlength=132300, base=4, prebuf=3528, minreq=44100 maxrewind=0 As you can see the new one increases the minreq substantially. Fixing just this one part makes Flash behave sanely. I'm getting the same issue against ThinLinc on my Fedora 18. The question is why this isn't a problem on my local desktop.
Some confusion here. Our internal server doesn't have flash installed, so the problems there are with its native player (the "HTML5" one). My tests systems have been using Flash though, so that's where I've focused my efforts. Hopefully Firefox is poorly implemented in the same manner as Flash is, so I don't have to hunt even more bugs.
Both Flash and Firefox seem to like the hack in r27685. Also reported upstream: https://bugs.freedesktop.org/show_bug.cgi?id=66962
I'm satisfied for now. We could do a lot to improve the update rate of the latency measurements, but I'm not sure it's worth the effort right now. Hopefully the rewrite will be finished in a not too far off future.
Works great as far as I can tell. Tested youtube with both HTML5 and Flash videos.
(In reply to comment #14) > Works great as far as I can tell. Tested youtube with both HTML5 and Flash > videos. VLC on "eudemo" also works, although not as smooth. This version however is pretty old and I believe it has known PulseAudio bugs. So good enough for me.
