933198 - gum_test.html doesn't provide audio on Windows nightly builds

Status: VERIFIED FIXED

(Core :: Audio/Video, defect)

Description

[Mark Banner (:standard8)]

Running the audio tests on http://mozilla.github.io/webrtc-landing/gum_test.html with Windows nightly builds provides no audio feedback. I can swap to FF 24 release and it works fine.

Bad versions: Nightly 28.0a1 2013-10-30, Aurora 27.0a2 2013-10-31

Known good: Aurora 26.0a2, 2013-10-28

So this affects 27 & later at the moment.

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Confirmed on my win7 nightly, and 10/30 win nightly debug.  (Lenovo W520 if it matters).

Works fine on linux inbound.

Appears to be an AudioStream/cubeb bug.  I turned on medialatency:5,mediastreamgraph:5,getusermedia:5,mediamanager:5,audostream:5 and everything up to AudioStream seems to be working.  however, the medialatency debugs tell me no DataCallbacks are occurring, so I suspect an earlier error or bug in cubeb.

The only audiostream logs I get are:

4876[1390a570]: mozilla::BufferedAudioStream::Init  channels: 2, rate: 16000
10100[13909548]: Latency: AudioStream Create,342605744,131,340266112
(That just lets us connect the AudioStream to the MediaStream feeding it)

Critical regression.  Perhaps it's my changes in bug 920325 that landed over the weekend, but looking at the diffs I don't see how it could cause this (especially the windows-only aspect, doubly-so when the medialatency logging is off).  Perhaps someone could try a backout of that bug and see.

Since Paul is on PTO, can someone else have a look?  Kinetik?  Roc?  I have to leave for IETF tomorrow so I don't know when I'll be able to attack this (I'll be traveling through Saturday, and have things planned for Sunday and need to do slides).  This requires being able to build and debug windows.

It might be as simple as relaxing the cubeb latency target (I hope).  Also, regression window will help a lot.

Comment 2

[Matthew Gregan [:kinetik]]

The WASAPI backend's cubeb_stream_init is bailing here: http://mxr.mozilla.org/mozilla-central/source/media/libcubeb/src/cubeb_wasapi.cpp#681 because we're requesting 10ms (which was returned by cubeb_get_min_latency).  Removing the 30ms sanity check and allowing the stream to be configured with 10ms latency seems to work fine on Windows 8.1 for me locally.  It's possible that the 30ms check is too conservative now that we can query the OS capabilities, so let's remove it.  If I'm wrong, Paul can explain why when he returns.

Comment 3

[Matthew Gregan [:kinetik]]

Attachment: bug933198_v0.patch

Comment 4

[Emanuel Hoogeveen [:ehoogeveen]]

In my experience shared mode WASAPI empties buffers in 10ms chunks. It may be that it does 15ms chunks on systems where thread time slice length defaults to 15ms - in that case you would need at least two, 15ms buffers to alternate between (one for the system to use, and one to write to).

So in my experience, 10ms is the smallest sensible buffer length (outside exclusive mode, where you can request a different callback frequency). Alternatively, 30ms would be the smallest buffer length that is an integer multiple of both 10ms and 15ms. I haven't looked at the code enough to know which reasoning it uses, but maybe that helps to clear things up.

Comment 5

[Emanuel Hoogeveen [:ehoogeveen]]

Oh, and of course it's possible that Windows 8.1 changes things so that the minimum buffer length is smaller (sorry about bugspam).

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 825811 [details] [diff] [review]
bug933198_v0.patch

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

Verified on Win7 Lenovo W520.  If we end up finding that there are systems this *doesn't* work on, the alternative would be instead to put a lower limit on latency to 30ms.  Try: https://tbpl.mozilla.org/?tree=Try&rev=b7a2f068ab8a

Comment 7

[Randell Jesup [:jesup] (needinfo me)]

checkin-needed because I have to get on an airplane and will be unavailable for a couple of days.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 825811 [details] [diff] [review]
bug933198_v0.patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): padenot's cubeb changes right before 27 uplift

User impact if declined: Audio will not work on many/all windows machines

Testing completed (on m-c, etc.): Tested locally, try pushed, should be considered for landing in Aurora as soon as it's on m-c.

Risk to taking this patch (and alternatives if risky): Very low risk

String or IDL/UUID changes made by this patch: none

Comment 9

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/df72f9b8213f

Comment 10

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/df72f9b8213f

Comment 11

[Mark Banner (:standard8)]

I just verified this is working for me on the setup it was broken with when I reported the bug.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/362d4f9fe2d5

Comment 13

[Ada [:adalucinet]]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0

Reproduced with Nightly from 2013-10-30.
Verified as fixed with Firefox 27 beta 6 (Build ID: 20140113161826): audio feedback is received on http://mozilla.github.io/webrtc-landing/gum_test.html (Audio and Audio/Video)