1586379 - Youtube sound is gone unexpectedly when running unplug-device tests

Status: NEW

(Core :: Audio/Video: cubeb, defect, P3)

Description

[C.M.Chang[:chunmin]]

This happens in the Rust backend and the C backend, on MacOS

Step to reproduce:

1. Open a youtube video
2. Run $ cargo test test_reinit_output_stream_by_unplugging_a_default_output_device -- --ignored --nocapture from the audiounit-rust test suite.

Expected result:

The sound keeps playing
(Chrome can play without any problems.)

Actual Result:

The sound is gone, but the video keeps playing

Note

If $ cargo test test_reinit_output_stream_by_unplugging_a_default_output_device -- --ignored --nocapture runs when spotify is playing, the spotify playback may skip to the next song unexpectedly, or the playback will be stopped unexpectedly with an error message: Oooops, something went wrong with the playback. Reload

Comment 1

[C.M.Chang[:chunmin]]

I haven't checked the log or trace the code yet, but I suspect the cause might be same as bug 1572273.

Comment 2

[C.M.Chang[:chunmin]]

[Child 8864: Unnamed thread 0x10fb03710]: E/cubeb media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:636: (0x13b2d0000) output: buffers 1, size 4464, channels 2, frames 558.
[Child 8864: Unnamed thread 0x10fb03710]: E/cubeb media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:636: (0x13b2d0000) output: buffers 1, size 4456, channels 2, frames 557.
[Child 8864: Unnamed thread 0x10fb03710]: E/cubeb media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:860: (0x13b2d0000) Audio device changed, 1 events.
[Child 8864: Unnamed thread 0x10fb03710]: E/cubeb media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:868: Event[0] - mSelector == kAudioHardwarePropertyDefaultOutputDevice for id=1
[Child 8864: Unnamed thread 0x136a3a080]: E/cubeb media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:3363: (0x13b2d0000) Create output device info failed. This can happen when last media device is unplugged
[Child 8864, Unnamed thread 136a3a080] WARNING: 13b25c820 StateCallback() state 1 cubeb error: file /Users/cchang/Work/gecko/dom/media/AudioStream.cpp, line 624
[Child 8864: Unnamed thread 0x136a3a080]: E/cubeb media/libcubeb/cubeb-coreaudio-rs/src/backend/mod.rs:3445: (0x13b2d0000) Could not reopen the stream after switching.
[Child 8864, MediaDecoderStateMachine #1] WARNING: Decoder=136437000 [OnMediaSinkAudioError]: file /Users/cchang/Work/gecko/dom/media/MediaDecoderStateMachine.cpp, line 3639

After invastigating the problem, I found the audiounit_get_default_device_id will return kAudioObjectUnknown without any error in this case (which means AudioObjectGetPropertyData will return NoErr).

What $ cargo test test_reinit_output_stream_by_unplugging_a_default_output_device -- --ignored --nocapture does is faking pluging an output device into the system, set it to the default output device, and then unplugging it. During my test, there are still 4 output devices in my macOS, so getting kAudioObjectUnknown from audiounit_get_default_device_id is really weird.

Since audiounit_get_default_device_id is not reliable, we should probably use one random device in the available devices. Or we need to find how to refresh the default device in the system, so audiounit_get_default_device_id can return something useful.

(In reply to C.M.Chang[:chunmin] from comment #1)

I haven't checked the log or trace the code yet, but I suspect the cause might be same as bug 1572273.

I had a wrong guess. It's not.

Comment 3

[C.M.Chang[:chunmin]]

I cannot reproduce it with my real devices. I plug a headset that will automatically become my default output and then unplug it during one youtube is playing. The video and the device-switch work fine. I've tried this several times.

The test run by $ cargo test test_reinit_output_stream_by_unplugging_a_default_output_device -- --ignored --nocapture is about 200ms. Maybe it's too aggressive. I don't know why Chrome works fine with that test. Either their device-switch is more stable than us, or it works slower than us (so when its new media stream starts, after the new default output is set, the stream can get the right default device id without noticing a device was just plugged then unplugged).

Comment 4

[Alex Chronopoulos [:achronop]]

Does the error change if you change the sleep value to something smaller in [1].

[1] https://searchfox.org/mozilla-central/rev/05a22d864814cb1e4352faa4004e1f975c7d2eb9/dom/media/MediaManager.cpp#2197

Comment 5

[C.M.Chang[:chunmin]]

(In reply to C.M.Chang[:chunmin] from comment #2)

After invastigating the problem, I found the [audiounit_get_default_device_id][audiounit_get_default_device_id] will return kAudioObjectUnknown without any error in this case (which means [AudioObjectGetPropertyData][AudioObjectGetPropertyData] will return NoErr).

What $ cargo test test_reinit_output_stream_by_unplugging_a_default_output_device -- --ignored --nocapture does is faking pluging an output device into the system, set it to the default output device, and then unplugging it. During my test, there are still 4 output devices in my macOS, so getting kAudioObjectUnknown from [audiounit_get_default_device_id][audiounit_get_default_device_id] is really weird.

(In reply to C.M.Chang[:chunmin] from comment #3)

I cannot reproduce it with my real devices. I plug a headset that will automatically become my default output and then unplug it during one youtube is playing. The video and the device-switch work fine. I've tried this several times.

This problem is happening in bug 1631814. It's better to find a way to deal with this. At least now we might have a way to reproduce bug 1631814.