Closed Bug 1299047 Opened 8 years ago Closed 8 years ago

Intermittent dom/media/tests/mochitest/test_getUserMedia_mediaElementCapture_audio.html | Test timed out.

Categories

(Core :: WebRTC, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla52
Tracking Status
firefox50 --- unaffected
firefox51 --- wontfix
firefox52 --- fixed

People

(Reporter: intermittent-bug-filer, Assigned: pehrsons)

References

Details

(Keywords: intermittent-failure)

Looking at the screenshot the audio appears to work at the right frequency, but the amplitude is too low for some reason.
Rank: 55 → 35
Component: Audio/Video → WebRTC
Priority: P5 → P3
Paul, what do you think this could be? I'm stumped.

It's just after audio-only gUM that we forward the audio track through a media element's mozCaptureStream() (which is just a regular MediaInputPort locked to that one track) and the amplitude of the analysed TEST_AUDIO_FREQ appears too low.

I was going to suggest MediaEngineDefaultAudio underruns but this is so early in the test and I think it buffers up some extra data in the beginning so it shouldn't be that.
Flags: needinfo?(padenot)
How low is it? Could it be because of the windowing of the AnalyserNode ?
Flags: needinfo?(padenot) → needinfo?(pehrson)
Currently I'm looking at multiple tests failing in the same way, though this is the only one where we have some kind of proof of what's going on.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=557cd026f3bc
Depends on: 1307042
See Also: → 1306821
I think this is because of MediaEngineDefaultAudio being push based, but let's see.
Flags: needinfo?(padenot)
This has been fixed by bug 1307042.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Assignee: nobody → pehrson
Target Milestone: --- → mozilla52
You need to log in before you can comment on or make changes to this bug.