797517 - <audio> (and <video>) stutters heavily under Remote Desktop connections

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[bugzmailer]

Connect to a remote machine using Window's built-in Remote Desktop with audio redirection enabled (the default). Try to play any HTML5 media with audio.

The playback will be very stuttery, and the playback time will advance slowly. It might fix itself after a (long) while, but only until you pause and resume again the playback.

Other tested applications (including Flash Player) work just fine. Local playback is fine.

I've tested this on several machines, though all of them were running Win7. The network connections were top-notch (wired LAN).

Comment 1

[Matthew Gregan [:kinetik]]

Would you mind testing with the beta version (16) and experimenting with a pref?  In about:config, create the integer pref "media.cubeb_latency_ms", and test with it set to 200 and 500?  You don't need to restart between changes, just reload the video.

Comment 2

[bugzmailer]

Sure. Setting it to 200 fixes the problem. I attempted to lower it further, 140 is broken whereas 150 works. Thanks!

Comment 3

[Matthew Gregan [:kinetik]]

Thanks for testing!  I'm looking at raising it to at least 150 in bug 788005 to solve an underrun issue on Vista, so I'll make sure I test with RDP at the same time.

Comment 4

[Matthew Gregan [:kinetik]]

Test builds are available here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-dea67cb72a59/try-win32/

Feedback from anyone suffering from this bug would be much appreciated.

Comment 5

[bugzmailer]

Hi,

Unfortunately I don't have the same machines I tested on originally. The server is the same but the client is weaker and is connected via local WiFi (as opposed to gigabit LAN).

In this configuration, the try build helps a bit but it's still broken. I went back to testing media.cubeb_latency_ms values and found that now 210 just barely works (with a bit or cracking at the beginning and after seeks), and 250 works well.

The problem is, I don't know why it needs higher values now. It might be the client machine (which runs Win7 too). It might be the connection - this is bad news because while it's worse it's still very good (<10ms ping, >10mbps) and I don't have means to test over the Internet. So I don't know what would be a safe enough value. Other applications (and Flash) keep working just fine.

Sorry about the mess.

Comment 6

[Matthew Gregan [:kinetik]]

Thanks for testing the build and updating the bug.  Based on this, I think I'll remove the RDP part of the workaround from bug 788005 and go ahead with that fix for Vista, and leave this bug open to track the fix for RDP.

Comment 7

[Matthew Gregan [:kinetik]]

Actually, I changed my mind.  I can do better than what I said above.  I'll change the code in bug 788005 to return a minimum latency rather than just signalling a that it's running in a "high latency" environment.  That way, I allow Vista to continue using the lowest latency that works, and just return something like 500ms (the value we used in the old audio backend) for RDP connections.

Comment 8

[Matthew Gregan [:kinetik]]

The bug in bug 788005 is now in nightlies, so marking this fixed based on the fact that I've reverted the buffering under RDP to the same value as the old backend.  Please reopen if this is still a problem.

Comment 9

[bugzmailer]

Seems fixed, thanks.

Not to nitpick but the code should have checked for remote session first, and Vista last, otherwise you get 200 on Vista RDP servers.

As a side note, installing the KB2592687 update on both client and server and setting the server to use RDP8 makes this patch unnecessary (not sure which step fixes it). The update isn't automatic though so it'll take several years for this to be fixed on MS' side.

Comment 10

[Matthew Gregan [:kinetik]]

You're right, thanks for pointing that out.

Comment 11

[Matthew Gregan [:kinetik]]

Attachment: patch v0

Simple change, test for RDP before Vista.

Comment 12

[cajbir (:cajbir)]

Comment on attachment 682940 [details] [diff] [review]
patch v0

Review of attachment 682940 [details] [diff] [review]:
-----------------------------------------------------------------

Apologies for the delay!

Comment 13

[Matthew Gregan [:kinetik]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/2c8ad66cebc4

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/2c8ad66cebc4