www.cendio.com
Bug 4411 - Audio sync seems not to work correctly
: Audio sync seems not to work correctly
Status: CLOSED FIXED
: ThinLinc
Sound
: 3.4.0
: PC Unknown
: P2 Normal
: 4.1.1
Assigned To:
:
:
: 4569
:
  Show dependency treegraph
 
Reported: 2012-10-01 15:57 by
Modified: 2013-10-24 10:51 (History)
Acceptance Criteria:


Attachments


Note

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


Description From cendio 2012-10-01 15:57:08
Split off from bug 3222 comment #30:

 - Audio sync is off. Tested both totem and mplayer.
------- Comment #1 From cendio 2012-10-25 10:04:40 -------
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 From cendio 2013-03-27 09:24:44 -------
PulseAudio 3.0 is out, perhaps we should try it out.
------- Comment #4 From cendio 2013-04-30 12:14:46 -------
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 From cendio 2013-07-11 14:03:55 -------
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 From cendio 2013-07-11 16:39:34 -------
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 From cendio 2013-07-12 14:46:33 -------
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 #8 From cendio 2013-07-12 16:00:48 -------
Filed two upstream bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=66855
https://bugs.freedesktop.org/show_bug.cgi?id=66857
------- Comment #9 From cendio 2013-07-12 16:36:29 -------
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 From cendio 2013-07-15 15:49:25 -------
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 From cendio 2013-07-16 11:25:51 -------
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 From cendio 2013-07-16 15:54:19 -------
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 From cendio 2013-07-17 10:31:29 -------
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 From cendio 2013-10-17 16:30:04 -------
Works great as far as I can tell. Tested youtube with both HTML5 and Flash
videos.
------- Comment #15 From cendio 2013-10-21 09:07:16 -------
(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.