1443716 - Full duplex streams don't recover after activating Siri with MDR-1000X (Bluetooth)

Status: RESOLVED DUPLICATE of bug 1489052

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

Description

[Matthew Gregan [:kinetik]]

Hit this accidentally while using appear.in with a Nightly build, but it's easy to reproduce using the GUM test page:

1. Open https://mozilla.github.io/webrtc-landing/gum_test.html
2. Start Audio test
3. Click Siri icon in top-right menu bar

With regular media playback, opening Siri causes the playing audio to be muted, and audio recovers once the Siri panel is closed.

With the GUM test page using the internal speakers and mic, playback/capture mutes and recovers in the same way.

With a Sony MDR-1000X selected as output (I haven't tested other headsets or Bluetooth vs USB, etc.) and the internal mic selected as input, opening Siri  causes a series of loud clicks.  libcubeb logging reports AudioUnitRender in audiounit_render_input is returning -10863 (kAudioUnitErr_CannotDoInCurrentContext).  After the Siri panel is closed, AudioUnitRender stops reporting this error, but the stream is left in a bad state (e.g. available_input_frames is now negative), and there's no capture audible.  Stopping and starting the test isn't sufficient to recover, but a page reload fixes the issue.

With the MDR-1000X selected as output and input, setup fails with the same AudioUnitRender error and we never have a working stream - although this might be intermittent as it worked the first time and failed every other time, even over page reloads.

Comment 1

[Matthew Gregan [:kinetik]]

> With the MDR-1000X selected as output and input, setup fails with the same AudioUnitRender error and we never have a working stream - although this might be intermittent as it worked the first time and failed every other time, even over page reloads.

Correction: the first attempt failed with kAudioUnitErr_CannotDoInCurrentContext, the second one succeeded, then several other tries failed.

Also worth noting that you usually wouldn't want to use the MDR-1000X's mic as it's located on top of the headband(!), I think it's used internally for ANC and exposed as an input device for phone use, but it's so badly located that it's not really useful for that purpose... unfortunately macOS selects it as the default input device when paired via BT.

Comment 2

[Alex Chronopoulos [:achronop]]

Can you mention the settings of MDR-1000X, like default sample rate, number of channels etc. Can you also try it with different default settings? I guess this would be reproducible if you test with a stand-alone cubeb app using duplex or input only.

Comment 3

[Matthew Gregan [:kinetik]]

There's a separate input and output device.  Input is 16kHz, 1 ch, 16-bit integer (only format available).  Output is 44.1 kHz, 2 ch, 32-bit float (and supports other common formats).

Based on the potential causes of kAudioUnitErr_CannotDoInCurrentContext, I suspected the output is changing format when the Siri panel is opened... sure enough, if you open Siri while watching the output format in AMS, it changes to match the input's format (and changes back shortly after Siri is closed).

Yes, you can repro this with cubeb's test_duplex.

Comment 4

[Paul Adenot (:padenot)]

fwiw I recently bought a Sony WH-1000XM2 (the model right after yours). I'm seeing other weirdness with it and Firefox, but the scenario you describe works well.

However, half the time, the audio input stream seemingly fails to start, and AudioUnitRender always returns `kAudioUnitErr_CannotDoInCurrentContext`.

Comment 5

[Alex Chronopoulos [:achronop]]

I reproduced something similar by using the Airpods for output device and the Plantronics headset for the input device. When Siri was on, render input was returning `AudioUnitRender rv=-10863`. On Firefox, when I close Siri I get the "series of loud clicks" similar to the description. On a stand alone cubeb application the stream recovers.

This is affected from the use of Aggregate Device. I disabled the AD (hard coded) and I do not have the failure any more, the stream recovers after closing Siri in both firefox and stand alone app. Also on one try I hit the following assert [1].

AD can be sensitive on format change. In addition AD may not be notified when Siri appears. It would good to know how Siri "steals" the audio from the device. From cubeb point of view, callback continues to circulate, in all cases.

[1] https://searchfox.org/mozilla-central/source/dom/media/webrtc/MediaEngineWebRTCAudio.cpp#840

Comment 6

[Jean-Yves Avenard [:jya]]

fixed with bug 1489052