Filed by: cbrindusan [at] mozilla.com
Parsed log: https://treeherder.mozilla.org/logviewer.html#?job_id=264892924&repo=mozilla-central
Full log: https://queue.taskcluster.net/v1/task/IjLn9q23RtWB0dZBOz2-hQ/runs/0/artifacts/public/logs/live_backing.log

09:21:59 INFO - TEST-START | /media-source/mediasource-changetype-play-implicit.html
09:21:59 INFO - Closing window 59
09:21:59 INFO - PID 11316 | [Parent 7216, Gecko_IOThread] WARNING: pipe error: 109: file z:/task_1567565531/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 341
09:21:59 INFO - PID 11316 | [Child 7152, Chrome_ChildThread] WARNING: pipe error: 109: file z:/task_1567565531/build/src/ipc/chromium/src/chrome/common/ipc_channel_win.cc, line 341
09:21:59 INFO - PID 11316 | [Child 7152, Chrome_ChildThread] WARNING: pipe error: 109: file z:/task_1567565531[Child 10284, MediaDecoderStateMachine #1] WARNING: 1db5556bb80 Can't get cubeb context!: file z:/task_1567565531/build/src/dom/media/AudioStream.cpp, line 274
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db56147400 [OnMediaSinkAudioError]: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3636
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db56147400 Decode error: NS_ERROR_DOM_MEDIA_MEDIASINK_ERR (0x806e000b) - OnMediaSinkAudioError: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3305
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: 1db56159e80 Can't get cubeb context!: file z:/task_1567565531/build/src/dom/media/AudioStream.cpp, line 274
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db56149400 [OnMediaSinkAudioError]: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3636
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db56149400 Decode error: NS_ERROR_DOM_MEDIA_MEDIASINK_ERR (0x806e000b) - OnMediaSinkAudioError: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3305
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: 1db5554b880 Can't get cubeb context!: file z:/task_1567565531/build/src/dom/media/AudioStream.cpp, line 274
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db5614a800 [OnMediaSinkAudioError]: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3636
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db5614a800 Decode error: NS_ERROR_DOM_MEDIA_MEDIASINK_ERR (0x806e000b) - OnMediaSinkAudioError: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3305
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: 1db5554bf40 Can't get cubeb context!: file z:/task_1567565531/build/src/dom/media/AudioStream.cpp, line 274
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db5614bc00 [OnMediaSinkAudioError]: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3636
09:22:00 INFO - PID 11316 | [Child 10284, MediaDecoderStateMachine #1] WARNING: Decoder=1db5614bc00 Decode error: NS_ERROR_DOM_MEDIA_MEDIASINK_ERR (0x806e000b) - OnMediaSinkAudioError: file z:/task_1567565531/build/src/dom/media/MediaDecoderStateMachine.cpp, line 3305
09:22:02 INFO -
09:22:02 INFO - TEST-PASS | /media-source/mediasource-changetype-play-implicit.html | Check if browser supports enough test media types and pairs of audio-only or video-only media with same bytestream format
09:22:02 INFO - TEST-UNEXPECTED-FAIL | /media-source/mediasource-changetype-play-implicit.html | Test audio-only implicit changeType for audio/webm; codecs="vorbis" <-> audio/webm; codecs="vorbis" - assert_unreached: Unexpected event 'error' Reached unreachable code

Doesn't seem to coincide with the initial landing of this test case, but the test-case is not all that old. The ini file has disabled the reporting of this failure as of Oct 15, along with some others:

https://searchfox.org/mozilla-central/rev/088e2cf29c59d733d57af43903eb0267dbf72e2a/testing/web-platform/meta/media-source/mediasource-changetype-play-implicit.html.ini

Probably related to bug 1586374, maybe related to bug 1583803.

Any idea what might be going on here?

Is this potentially related to moving vorbis to RDD?

The error is in MediaSink , cubeb by the look of things.

no idea why it would error, but this isn't a MSE error per say, nor a decoding error.

This is failing on aarch64/Windows 10 only. Do our aarch64/Windows 10 machines have audio hardware available to the test infrastructure? Is this really a P2?

In the logs, GetCubebContext fails and returns nullptr, indicating either no audio hardware (or some other error). The test is audio only so MDSM fails playback rather than falling back to the system clock, and the test fails due to the unexpected error event it receives. It seems like this test will always fail when run on a device with no audio hardware and needs to handle that case, somehow.

I tried a test run with additional cubeb logging to understand why GetCubebContext fails, but the test is no longer grouped in wpt11. I triggered the other wpt tests, but 6 hours later none of them have started.

It looks like the failing test is grouped into wpt7 now, so I'll retrigger a full build and see what happens: https://treeherder.mozilla.org/#/jobs?repo=try&revision=932b92e4e55b92570533b8c0e8c0a802893e1e40

Looking at several retriggers of wpt7, most of them seem to have workingaudio hardware and cubeb WASAPI initializes correctly, as expected . In the cases where wpt7/mediasource-changetype-play-implicit fails, it appears that the environment has no audio hardware available .

In the failing case, IMMDeviceEnumerator::GetDefaultAudioEndpoint returns E_NOTFOUND (0x80070490), indicating no audio hardware is available; cubeb then falls back to the WinMM backend, where waveOutGetNumDevs also reports no audio hardware is available.

Note that in the cases where cubeb fails to init, this happens reliably from the beginning of the job run for every test that requests a cubeb context. Other tests seem to handle this situation, suggesting this particular test is broken in the absence of audio hardware. Nils, who maintains this test?

I'm not sure why some test runners are missing audio hardware. As far as I can tell, they're all Yoga C630 devices, so should have identical hardware. Possibly missing drivers on some devices? Edwin, are you the right person to ask about these machines, or can you point me in the right direction?

:kinetik - I did stand up the machines though I no longer manage the windows10-aarch64 hardware.

I can see over in the slack channel for managing the windows10-aarch64 hardware that some of the machines have had issues with generic-worker. Granted, the issues appear to be that machines hang because of user account issues post or pre-test run, so that does not seem like it would affect just the audio driver.

Over in the arm64 slack channel I found these issues, not sure if any of them relate to the bug here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1592826
https://bugzilla.mozilla.org/show_bug.cgi?id=1580742

Other than that, I am not aware of any specifically audio related bugs reported against windows10-aarch64.

We have shipped our last beta for 71 so this is wontfix for 71.

This is only on Windows 10, and clearly related to the way our test images are built: sometimes audio isn't working and we can't run tests.

Edwin, who is maintaining this right now?

:padenot - management of windows10-aarch64 machines is now done by Bitbar and I have not really interacted with them much over the second half of 2019 and this year. I know Mark Cornmesser and Rob Thijssen have been interacting with Bitbar quite often, but not sure if it's related to this issue.

Without knowing too much about the underlying issue, is the issue due to the way machines are configured? Would having new hardware help?

What we know is that when this happens, then the machine's audio system doesn't work: simply enumerating devices reports an error. This is not normal behaviour, so I believe there is something going on sometimes, but I don't know what.

I'm putting this out of the backlog for now, but not closing it so we can revisit if we need to.

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit auto_nag documentation.

(In reply to Release mgmt bot [:sylvestre / :calixte / :marco for bugbug] from comment #16)

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit auto_nag documentation.

I doubt this is supposed to be closed. There's something wrong with some of the test machines here. Somebody will need to take a look eventually.

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit auto_nag documentation.