Bug 4411 - Audio sync seems not to work correctly
Summary: Audio sync seems not to work correctly
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Sound (show other bugs)
Version: 3.4.0
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.1.1
Assignee: Pierre Ossman
URL:
Keywords: astrand_tester, relnotes
Depends on: 4569
Blocks:
  Show dependency treegraph
 
Reported: 2012-10-01 15:57 CEST by Peter Åstrand
Modified: 2013-10-24 10:51 CEST (History)
0 users

See Also:
Acceptance Criteria:


Attachments

Description Peter Åstrand cendio 2012-10-01 15:57:08 CEST
Split off from bug 3222 comment #30:

 - Audio sync is off. Tested both totem and mplayer.
Comment 1 Aaron Sowry cendio 2012-10-25 10:04:40 CEST
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.
Comment 2 Peter Åstrand cendio 2013-03-27 09:24:44 CET
PulseAudio 3.0 is out, perhaps we should try it out.
Comment 4 Pierre Ossman cendio 2013-04-30 12:14:46 CEST
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.
Comment 5 Pierre Ossman cendio 2013-07-11 14:03:55 CEST
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.
Comment 6 Pierre Ossman cendio 2013-07-11 16:39:34 CEST
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.
Comment 7 Pierre Ossman cendio 2013-07-12 14:46:33 CEST
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.
Comment 9 Pierre Ossman cendio 2013-07-12 16:36:29 CEST
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.
Comment 10 Pierre Ossman cendio 2013-07-15 15:49:25 CEST
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.
Comment 11 Pierre Ossman cendio 2013-07-16 11:25:51 CEST
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.
Comment 12 Pierre Ossman cendio 2013-07-16 15:54:19 CEST
Both Flash and Firefox seem to like the hack in r27685. Also reported upstream:

https://bugs.freedesktop.org/show_bug.cgi?id=66962
Comment 13 Pierre Ossman cendio 2013-07-17 10:31:29 CEST
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.
Comment 14 Peter Åstrand cendio 2013-10-17 16:30:04 CEST
Works great as far as I can tell. Tested youtube with both HTML5 and Flash videos.
Comment 15 Peter Åstrand cendio 2013-10-21 09:07:16 CEST
(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.

Note You need to log in before you can comment on or make changes to this bug.