1670633 - Intermittent audio or 'robotic voice' issues with aggregate device on Mac

Status: RESOLVED FIXED

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

Description

[Marco Butera]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Steps to reproduce:

I connect to google meet to join a meeting but

Actual results:

I had many problems with intermittent audio., also other colleagues report this problem (but I don't know if they used firefox). I suggest to move to google chrome and after the people that has problems move to chrome the problem are solved

Expected results:

we expect to use google meet also on other browsers

Comment 1

[Dan Minor [:dminor]]

Hi Marco,

Thank you for your bug report! When you say you have problems with intermittent audio, is the problem with others hearing intermittent audio when you speak, or you hearing intermittent audio when others speak, or possibly both? Do you know if this is a new problem with Firefox 81, or have you noticed this with earlier versions? Thanks!

Comment 2

[Jovan Gerodetti]

Hello Dan,
We are also experiencing this problem. For us it's usually that people who join the meeting get an audio delay of about ~1 - 2 seconds. This means I won't hear anything the other person says for a second and after that the audio will be slightly out of sync with the video.
Let me know if I can provide more details.

Comment 3

[batista_jose]

Hello,

I have the same problem, since yesterday (29/10).
I got the reconnect indication during the meeting, but I was still connected. I also had real disconnection. The other navigation pages also happen to be slowed down.
The previous weeks, I had no slowdown in navigation and discussion.

For exemple: I write a text on google translate and it takes a few seconds before being updated on the translated part.

Os : Windows 10 64b
Firefox : 82.0.2 64b

Comment 4

[Dan Minor [:dminor]]

Hi Paul, I'm not sure if there is anything actionable here right now, but there are enough reports that I think this is a real problem. Do you mind having a look at prioritization?

Comment 5

[Paul Adenot (:padenot)]

P1 S1 until proven otherwise. Slowness of the whole browser I've seen myself, but we don't have enough resources to work on it. The rest is a regular performance issue it sounds like.

Comment 6

[Andrew Overholt [:overholt]]

We're looking at a policy change of asking for active assignees on S1 bugs. Is there anything we can do here?

Comment 7

[Nils Ohlmeier [:drno]]

I just reached out to the Meet team.

To the reporter here on the bug: what kind of audio equipment are you using?
Is by any chance everyone using Bluetooth head sets?

Comment 8

[Marco Butera]

(In reply to Dan Minor [:dminor] from comment #1)

Hi Marco,

Thank you for your bug report! When you say you have problems with intermittent audio, is the problem with others hearing intermittent audio when you speak, or you hearing intermittent audio when others speak, or possibly both? Do you know if this is a new problem with Firefox 81, or have you noticed this with earlier versions? Thanks!

Hello, I had at the time of the bug report the last Firefox version, the intermittent audio was when other speak. I din't use bluethoot or other equipements, just the laptop that usially I use.

This problem disappear when I moved to Google Chrome to follow the meeting.

Comment 9

[Andrew Overholt [:overholt]]

This bug seems bad but also, sadly, unactionable. Is there more information we could get that would allow progress? Should we mark it as stalled?

Comment 10

[Nils Ohlmeier [:drno]]

Unfortunately the Meet folks were not able to help us with these reports so far.

Comment 11

[Likshan Lingam]

The bug is so annoying because I use firefox daily but I am unable to join google meets because even though I have a persistent connection the audio. I can here it for like 3 sec and it stops for about 8 sec. This repeats for the entire meet.

Firefox 90 and Firefox 91 have seemed to fixed
But Firefox 92 and The Beta version 93 are affected

Please fix this bug as fast as possible I'm temporarily migrating to chromium.

Or I'll roll back to previous versions and update if the bug can be reproduced.
If not I'll be using the older version until it's fixed

Comment 12

[Jim Mathies [:jimm]]

Bug 1739505 may help here. TBD once that work lands.

Comment 13

[Coral Mountain]

I have this same issue on Firefox 100.0.1 on macOS 12.3.1. My device is a MacBookPro16,1. After a couple of minutes the audio starts to be intermittent (robotic, distorted, and scratchy) in both direction: I hear the scratches, and on the other end they hear me distorted. When joining the same call in Google Chrome (with the exact device and configuration) I have no issues. Let me know if there's additional info that I can provide.

Comment 14

[Paul Adenot (:padenot)]

This is a different bug. Can you please describe your setup in terms of audio input and output devices? A copy of the raw data of about:support will also help.

Comment 15

[Coral Mountain]

(In reply to Paul Adenot (:padenot) from comment #14)

This is a different bug. Can you please describe your setup in terms of audio input and output devices? A copy of the raw data of about:support will also help.

Feel free to point me to a different bug, or let me know if it's necessary to file a new one. In terms of audio input/output I'm using the machine built-in microphone and speakers.

Comment 16

[Paul Adenot (:padenot)]

(In reply to Coral Mountain from comment #15)

(In reply to Paul Adenot (:padenot) from comment #14)

This is a different bug. Can you please describe your setup in terms of audio input and output devices? A copy of the raw data of about:support will also help.

Feel free to point me to a different bug, or let me know if it's necessary to file a new one. In terms of audio input/output I'm using the machine built-in microphone and speakers.

I think this is new, especially if you're using a recent macbook and Fx 100. You can open a new bug at https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Audio%2FVideo%3A%20cubeb (this goes to the right component so I'm immediately notified).

I'll provide you instructions for recording an example of audio and getting us logs so we can investigate / fix it. Thanks!

Comment 17

[Jim Mathies [:jimm]]

For anyone running into audio issues, please post your about support text. Also, if you can please install the firefox profiler extension and capture a 'media' profile when you experience the issue, upload the profile and post the link here. Thanks!

https://profiler.firefox.com/

Comment 18

[Jan Honza Odvarko [:Honza] (always need-info? me)]

From: https://github.com/webcompat/web-bugs/issues/107298#issuecomment-1185791486

I was able to catch it in a profile, here: https://share.firefox.dev/3IEKdBP. The entire time period of this profile was while the call was choppy and my CPU was downclocked.

It seems like it happens more when screen sharing is being used (another person sharing their screen with em), but not exclusively.

Comment 19

[Michael Cooper [:mythmon]]

Attachment: my about:support data

Replying here instead of the Github thread so I can more easily attach a file.

I've also taken a profile with the Media preset (the last one was the Firefox preset). https://share.firefox.dev/3octUTh

I agree that this looks like thermal throttling, though I don't think my laptop is getting particularly hot. It's warm to the touch, but not unusually so, and watching sensor temperatures doesn't show CPU temps above 70C, and typically around 60C. That seems like reasonable temperature to me that should not cause throttling.

I've attached my about:support data.

Comment 20

[Paul Adenot (:padenot)]

Yes, your machine is completely overloaded. Even the real-time audio threads don't have their scheduling slices. You probably want to vaccum it or something, that can't hut. Please also make sure the audio threads are promoted appropriately, I'm not sure one has to do something specific with Arch. To check this, do a WebRTC call (just yourself in a Meet room is enough), and run:

watch -n1 "ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm -T | grep ' RR '"

check that there are threads called AudioIPC0 with the PID of the tab. There should also be rtkit-daemon and then some PulseAudio or PipeWire threads.

Additionally, and more importantly, your machine is using WebRender with software fallback, so it's not really using the GPU to composite a bunch of videos (webcam, screen capture, that might be quite big), in addition to decoding them, and encoding yours (plus audio encoding/decoding, plus audio processing, etc.). This is the thing you want to fix first.

Comment 21

[Michael Cooper [:mythmon]]

watch -n1 "ps -eo pid,tid,class,rtprio,ni,pri,psr,pcpu,stat,wchan:14,comm -T | grep ' RR '"

    853     964 RR      20   -  60   0  0.1 Ssl  do_epoll_wait  pipewire
    855     960 RR      20   -  60   1  0.0 Ssl  do_epoll_wait  wireplumber
    856     963 RR      20   -  60   6  0.0 SLsl do_epoll_wait  pipewire-pulse
    860     947 RR      99   - 139   7  0.0 SNsl -              rtkit-daemon
   6073    6219 RR      10   -  50   5  0.0 Sl   do_epoll_wait  AudioIP~ack RPC
   6073    6288 RR      10   -  50   1  0.0 Sl   futex_wait_que AudioIPC0
 322192  322483 RR      10   -  50   2  0.7 Sl   futex_wait_que AudioIPC0

That last row has the PID of the Google Meet tab. I'm not sure how to tell if it's being properly promoted. Does this look wrong?

Yes, your machine is completely overloaded.

I mentioned this in the Webcompat issue, but I haven't here yet. The symptom I'm observing is that while I'm on a Google Meet my CPu will drop from it's normal frequency down to it's minimum frequency (about 600MHz if memory serves) and hold there for ~10 seconds before recovering. It's during that time that the audio is choppy. In fact my entire system is pretty much unusable for those ten seconds. It's not at all surprising that the audio threads are being overloaded. This does not seem to correlate with increased CPU temperature.

Notably, this does not happen when I use another WebRTC site, https://gather.town, in Firefox and it doesn't happen with Meet in Chrome. I think the issue here is that something is causing my CPU to downclock, not that the audio gets choppy when they are starved for CPU time.

Additionally, and more importantly, your machine is using WebRender with software fallback, so it's not really using the GPU to composite a bunch of videos (webcam, screen capture, that might be quite big), in addition to decoding them, and encoding yours (plus audio encoding/decoding, plus audio processing, etc.). This is the thing you want to fix first.

Is there any documentation for how I can fix this? I didn't see anything on SuMo. I switched over to using Wayland directly instead of XWayland, and although that helped things be generally visually smoother, it didn't help with the video call issues.

Comment 22

[Paul Adenot (:padenot)]

That last row has the PID of the Google Meet tab. I'm not sure how to tell if it's being properly promoted. Does this look wrong?

Yes, it works well if it appears at all because of the grep RR that filters by thread that have been promoted successfuly.

Is there any documentation for how I can fix this? I didn't see anything on SuMo. I switched over to using Wayland directly instead of XWayland, and although that helped things be generally visually smoother, it didn't help with the video call issues.

No idea, #gfx-firefox on chatmo will know more, or maybe :jrmuizel knows who will know or what to do?

Comment 23

[Jim Mathies [:jimm]]

(In reply to Michael Cooper [:mythmon] from comment #21)

Additionally, and more importantly, your machine is using WebRender with software fallback, so it's not really using the GPU to composite a bunch of videos (webcam, screen capture, that might be quite big), in addition to decoding them, and encoding yours (plus audio encoding/decoding, plus audio processing, etc.). This is the thing you want to fix first.

Is there any documentation for how I can fix this? I didn't see anything on SuMo. I switched over to using Wayland directly instead of XWayland, and although that helped things be generally visually smoother, it didn't help with the video call issues.

You can try enabling it via prefs, visit about:config, and check the values for
gfx.webrender.enabled
gfx.webrender.fallback.software

Comment 24

[Michael Cooper [:mythmon]]

I think I was able to get Webrender into hardware mode instead of software. The problem occured again today with that configuration. Here's about:config and a profile.

Comment 25

[Paul Adenot (:padenot)]

That looks better from an real-time audio point of view.

The audio threads now has a reasonnable load (about 7%). Do you still experience the same issue, where sometimes the audio goes bad for some time, and then it's better?

Comment 26

[Michael Cooper [:mythmon]]

This still happens regularly yes. While on Google Meet calls my computer becomes unusable for ~10ish seconds at a time. As well as the audio problems, other programs slow down, my mouse lags, and sometimes I get application not responding notices from Firefox.

I noticed that when it's happening sometimes a process called "RDD" is using a lot of CPU, and also sometimes WirePlumber is using a lot of CPU. This may simple be that with the reduced pie of my downclocked CPU, any activity will pin the CPU, but maybe something weird is going on?

Although the temperatures of any particular component aren't getting too high, it does feel like a thermal limiting problem. Maybe one particular component of my processor is getting overwhelmed?

Comment 27

[Paul Adenot (:padenot)]

Yes, this is likely to be a thermals problem, or something else outside of our control. Maybe the computer has lots of dust in the fan intake/exhaust.

We're making optimizations to the WebRTC stack at the moment to lower the resource usage, which will mitigate the problem, but it's a real problem anyway.

Comment 28

[tom.spiderbrain]

I have the same issue. Firefox 102 on Kubuntu 22 LTS. No audio on the Google Meet speaker test, and no audio from other meeting attendees. Everything works fine in Chrome.

Comment 29

[Diego Caravana]

I have the "robot voice" issue with Firefox only and an external Logitech webcam (below), but using Chrome there is no problem:

Name 	Group 	Vendor 	State 	Preferred 	Format 	Channels 	Rate 	Latency
MacBook Pro Microphone	builtin-internal-mic|spk	Apple Inc.	Enabled	None	default: F32LE, support: S16LE S16BE F32LE F32BE	1	default: 48000, support: 44100 - 96000	2454 - 6535
C270 HD WEBCAM	C270 HD WEBCAM:046D:0825	Unknown Manufacturer	Enabled	All	default: F32LE, support: S16LE S16BE F32LE F32BE	1	default: 48000, support: 16000 - 48000	63 - 4144

Yes, this is likely to be a thermals problem, or something else outside of our control. Maybe the computer has lots of dust in the fan intake/exhaust.

I'm quite paranoid about resource usage (I've started programming with 1 MHz 8 bit CPUs and 5 Kb RAM...) and heating efficiency (we had a constant of > 35 C here this summer).

Therefore I'm confident in saying that CPU usage goes up at sensibly higher levels with Firefox in my case, while with Chrome it stays low.

I'm currently on an Apple Powerbook 16'' (Intel) in clamshell (closed-lid) mode.

The problem literally never happened before with open-lid/internal webcam/mic.

Comment 30

[Jim Mathies [:jimm]]

Hey Diego,

Could you help us out by capturing and uploading a Firefox performance profile when this happens? Visit https://profiler.firefox.com/ for more information. When capturing, please select the Media profile in the drop down.

Comment 31

[Diego Caravana]

Here you go Jim: https://share.firefox.dev/3feguVo

By the way I'm using Firefox 106b2 because I read it brings a lot of improvements about WebRTC, I tried it yesterday in a real-world scenario but I've got the exact same robotic-voice issue as with 105.

Comment 32

[Jim Mathies [:jimm]]

Hey diego, any chance you can do another media profile for us?

Comment 33

[Diego Caravana]

(In reply to Jim Mathies [:jimm] from comment #32)

Hey diego, any chance you can do another media profile for us?

Hey Jim, sorry for the long wait but I haven't had access to my hardware for the past month.

Also, using Firefox 117, I just did a fairly long Google Meet session (> 1hr) with almost 10 people (with screen sharing, too) using my external camera and I haven't had the issue at all.

Actually I haven't had any issue, including heating for too much CPU usage (which is higher than Chrome but still - also wondering how Chrome manages to reach such low levels of CPU usage...).

From now on, I'll restart using Firefox for my meetings and I will report as soon as anything weird happens, however my gut feeling is that this bug has been solved.

Comment 34

[Jim Mathies [:jimm]]

Thanks for the report back!

Comment 35

[Jim Mathies [:jimm]]

We closed this but the reporter commented in another bug they ran into again. Then yesterday the webconf team was in their Whereby standup and Nico ran into the robotic voice issue.

NI to Nico for some information on what the hardware set up was for that.

Comment 36

[Nico Grunbaum [:ng, @chew:mozilla.org]]

(In reply to Jim Mathies [:jimm] from comment #35)

We closed this but the reporter commented in another bug they ran into again. Then yesterday the webconf team was in their Whereby standup and Nico ran into the robotic voice issue.

NI to Nico for some information on what the hardware set up was for that.

I am using Nightly on macOS 13.4.1 (c) on an Apple M2 Pro laptop, which is closed and connected to an external monitor, a Logitech c920 webcam, and a Bose QC45 Bluetooth headset. The problem occurred when I was using the c920 for A/V capture and the QC45 for audio output. It did not happen when I used the QC45 for audio capture and output while using the c920 for video capture.

Comment 37

[Nico Grunbaum [:ng, @chew:mozilla.org]]

Attachment: Nico's about support

Comment 38

[Jim Mathies [:jimm]]

Nico also experienced this in Whereby vs. Meet. So probably not site specific.

Comment 39

[Andreas Pehrson [:pehrsons]]

padenot tells me cubeb doesn't correct for drift between input and output, so it's likely the problem is here.

If someone sees this again, please enable the webrtc-preset logs on about:logging, and share the resulting profile. cubeb:5 is what's most interesting here (so the media playback preset should also work).

Comment 40

[Diego Caravana]

Here you go:

https://share.firefox.dev/48fRvIm

I've managed to reproduce the issue with my external webcam, and I can confirm it only happens when you select the external microphone (not the video stream I mean).

Also, when you switch back to the internal mic, the sound goes back to normal.

I played a bit with changing sources during the recording of the logs.

Only two participants with Google Meet.

Comment 41

[Andreas Pehrson [:pehrsons]]

Thank you! There are no cubeb logs in this profile however. Diego, could you make sure to include the AudioIPC Server RPC thread when you share the profile? Thanks.

Comment 42

[Andreas Pehrson [:pehrsons]]

I see a cubeb_log thread that we might need too. If you don't mind, just include all threads, including all hidden ones. The heuristic that selects which threads to unhide is based on cpu usage afaik.

Comment 43

[Diego Caravana]

Here we go again, this time including what you asked for Andreas:

https://share.firefox.dev/48kgdaS

Last time didn't include anything optional because it was giving a size-too-big error so I had to keep this session quite short to be able to do it.

Comment 44

[Andreas Pehrson [:pehrsons]]

Thank you! And the audio input sounded robotic while capturing this profile also?

Because there is no sign of cubeb_resampler throwing data out here.

I've tried reproducing myself on Mac too with various external web cam mics but I have not observed any drift. I'll give it a go on linux too where we don't have any drift correction provided by the platform.

Could you also get a profile just covering setting up the call, please? To have an idea of how we are setting up the streams -- maybe it shows something unusual. In the profiler, the parent process' "AudioIPC Server RPC" thread is of interest in this case. Thanks.

Comment 45

[Diego Caravana]

Here Andreas: https://share.firefox.dev/3ZrGRdB

I wasn't able to activate the "hidden threads" checkbox because the profiler gave me a profile-too-big error, however I can re-upload it if you explain me how to do it.

Let me also add that this bug is really still there, only quite difficult to reproduce even by myself: in fact, when I set up the session, I have to wait and maybe fiddle a bit with Google Meet seetings (activate/deactivate noise suppression for instance).

Comment 46

[Andreas Pehrson [:pehrsons]]

Can you unhide the AudioIPC ones, and the cubeb_log thread before you share? Then you can avoid sharing all hidden threads. This is at the top left where it says X/Y tracks and you need to click the little down-arrow.

You can hide other processes than the parent.

Comment 47

[Diego Caravana]

Here again: https://share.firefox.dev/46jG3cY

This time I've configured the upload as instructed ie. by enabling that AudioIPC Server RPC, but also all audio* and cube* threads for the actual Meet process (36436) and server.

Comment 48

[Andreas Pehrson [:pehrsons]]

Thank you. That looks perfectly normal I'm afraid.

Some good news however, in that I've been able to reproduce this issue. I'll see if I can figure it out.

Comment 49

[Andreas Pehrson [:pehrsons]]

I have reproduced this with standalone cubeb (our audio library), which on Mac creates an aggregate device with drift correction enabled. I have verified the aggregate device is set up as it should by making it non-private. Regardless of whether drift correction is enabled for the input on the aggregate device (the output is the clock source) I get no drift in the data handed to us by the platform, and in both cases I get the robotic voice.

If I disable the aggregate device (in code) I get drift as expected between the input and output callbacks, and no robotic voice as you'd expect.

The obvious solutions here appear to be to either: 1) have Apple fix it in the platform, or 2) stop using aggregate devices and implement drift correction ourselves. I'm unassigning myself as we discuss what approach to take.

Comment 50

[Diego Caravana]

As a Firefox user, I thank you Andreas for your work here.

I'm a software engineer, too, but I don't know the first thing about how Firefox is implemented.

However I'd like to add two points that might help the discussion:

1. Out of curiosity, I've just tried to reproduce the issue with Chrome but I wasn't able. Given what you said, this could mean Chrome either has its own implementation for drift correction, or they use aggregate devices in a different way, or more simply I had bad luck.
2. With Google Meet, on my machine CPU utilisation with Chrome is quite low (like half of Firefox, but this is a very empirical measure of mine), even with many people and screen sharing, in which case Firefox easily goes over 100% CPU utilisation (referring to a core not the overall CPU combined computing power); in case of Firefox, could the high CPU utilisation be contributing to a poor experience with external devices for some reason?

Comment 51

[Paul Adenot (:padenot)]

(In reply to Diego Caravana from comment #50)

As a Firefox user, I thank you Andreas for your work here.

I'm a software engineer, too, but I don't know the first thing about how Firefox is implemented.

However I'd like to add two points that might help the discussion:

1. Out of curiosity, I've just tried to reproduce the issue with Chrome but I wasn't able. Given what you said, this could mean Chrome either has its own implementation for drift correction

This is the case, they implement a drift correction algorithm. They also high very high audio latency compared to Firefox, because of this drift correction and also because of other historical architectural decisions. If they were to attempt to have low latency, they'd have the same issue and would have to make the same fix we're doing now.

fwiw, we're able to reproduce this issue without Firefox, just by opening audio streams on macOS in a small test program. The immense majority of device setup of macOS users doesn't trigger this issue, so we'll be fixing this in a way that it doesn't regress most users (that have stable audio input/output and latency as low as possible), but fixes the other cases that hit this bug.

2. With Google Meet, on my machine CPU utilisation with Chrome is quite low (like half of Firefox, but this is a very empirical measure of mine), even with many people and screen sharing, in which case Firefox easily goes over 100% CPU utilisation (referring to a core not the overall CPU combined computing power); in case of Firefox, could the high CPU utilisation be contributing to a poor experience with external devices for some reason?

This is likely unrelated and Andreas is actually working on lowering resource usage of WebRTC calls by optimizing lots of things related to cameras (which is horribly unoptimized today, in a way that does a lot of memory traffic, and that affects everything because the memory bus is a shared resources).

We'll also be investigating using hardware decoders and encoders, and enabling them for WebRTC, as part of our Web Codecs API implementation (encoders and decoders can be shared in Firefox, but not always, and we're working on consolidating and optimizing the lower level to benefit everything).

Comment 52

[Andreas Pehrson [:pehrsons]]

The only mention of an aggregate device I see in Chromium is an implicit one from setting up a VoiceProcessingIO AudioUnit. Unclear how that handles drift, but it could possibly be a third approach to investigate.

Comment 53

[Stefan Fleiter (:sfleiter)]

Hey Paul,

would you mind sharing the small test program that also causes this?

Also, what is the specific device setup so that

The immense majority of device setup of macOS users doesn't trigger this issue

Background: I am able to reproduce something very similar in an unreleased (for Firefox) VC solution.

Comment 54

[Andreas Pehrson [:pehrsons]]

(In reply to Stefan Fleiter (:sfleiter) from comment #53)

Hey Paul,

would you mind sharing the small test program that also causes this?

We have observed this with standalone cubeb with the cubeb-coreaudio-rs backend:

• Set up the build locally through these steps: https://github.com/mozilla/cubeb-coreaudio-rs/blob/trailblazer/build-audiounit-rust-in-cubeb.sh
• Turn up this delay (which is in millis) to cover whatever time is needed to trigger the issue.
• Build
• Make the device pair that is known to trigger the issue the default input and output device on the system.
• Run CUBEB_BACKEND="audiounit-rust" ./test_duplex --gtest-filter=cubeb.duplex while creating some sound for said input device to pick up and listen to said output device for audio distortions. It's a simple loopback test so you'll want to avoid external speakers!

Also, what is the specific device setup so that

The immense majority of device setup of macOS users doesn't trigger this issue

What we've seen trigger this is some input device that brings its own clock (digital, like usb or bluetooth) and has sufficient drift compared to the output device. I have reproduced it with a Microsoft Lifecam HD-3000 or a cheap USB-TRS adapter as input, and an external analog headset as output. Diego above in comment 29 reported reproducing this with a Logitech C270 HD webcam. I have heard reports of airpods too, but I'm unsure if they were used for input, output, or both.

Background: I am able to reproduce something very similar in an unreleased (for Firefox) VC solution.

Comment 55

[Stefan Fleiter (:sfleiter)]

Thanks a lot for the detailed answer.
I have a Logitech C920 HD Pro external Webcam hitting this.

I could not get the tests to run (yet), I have not done any real C/C++ coding for a long time...

Test project /Users/stefanfle/Development/opensource/cubeb-coreaudio-rs/cubeb-build
      Start  1: sanity
 1/15 Test  #1: sanity ...........................Subprocess aborted***Exception:   0.00 sec
dyld[48694]: Symbol not found: __ZN7testing15AssertionResultC1ERKS0_
  Referenced from: <1E33111E-525E-3B66-9130-ABC4D3B81D41> cubeb-coreaudio-rs/cubeb-build/test_sanity
  Expected in:     <no uuid> unknown

probably this?

Comment 56

[Andreas Pehrson [:pehrsons]]

Cubeb includes gtest directly: https://github.com/mozilla/cubeb/blob/f9c118ddc050d15ffb3ac2babff06a833d0ac740/CMakeLists.txt#L39-L52
I guess from your error that gtest was compiled with different flags than cubeb for some reason.

Comment 57

[Paul Adenot (:padenot)]

We now know that this is an OS bug and are working on a workaround, without regressing latency.

Comment 58

[Andreas Pehrson [:pehrsons]]

Workaround WIP: https://github.com/mozilla/cubeb-coreaudio-rs/pull/185.

Comment 60

[Jim Mathies [:jimm]]

Fix for this will merge into 122 with a cubeb update.

Comment 63

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1670633 - Update bindgen to 0.69.1 and coreaudio-sys to 0.2.14. r?#supply-chain-reviewers

This sets the stage for an update to cubeb-coreaudio-rs.

Comment 64

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1670633 - Update cubeb-coreaudio-rs to 964e1462. r?#cubeb-reviewers

Comment 65

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bace8b9c91dc
Update bindgen to 0.69.1 and coreaudio-sys to 0.2.14. r=supply-chain-reviewers,glandium
https://hg.mozilla.org/integration/autoland/rev/be8e9a8eaa80
Update cubeb-coreaudio-rs to 964e1462. r=cubeb-reviewers,padenot

Comment 66

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/bace8b9c91dc
https://hg.mozilla.org/mozilla-central/rev/be8e9a8eaa80

Comment 67

[Serban Stanca [:SerbanS]]

Backed out as requested for causing Bug 1866014.

• Backout link

Comment 68

[Norisz Fay [:noriszfay]]

Backout merged to central: https://hg.mozilla.org/mozilla-central/rev/5cdd21545087

Comment 69

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a849a8e4bd37
Update bindgen to 0.69.1 and coreaudio-sys to 0.2.14. r=supply-chain-reviewers,glandium
https://hg.mozilla.org/integration/autoland/rev/e7d101bd73d9
Update cubeb-coreaudio-rs to 964e1462. r=cubeb-reviewers,padenot

Comment 70

[Cristian Tuns]

Backed out for causing build bustages in MediaEngineWebRTCAudio.cpp

• Backout link
• Push with failures
• Failure Log
• Failure line: /builds/worker/checkouts/gecko/dom/media/webrtc/MediaEngineWebRTCAudio.cpp:330:6: error: "Must remove this quick fix to bug 1866014 before reaching beta"

Comment 71

[Andreas Pehrson [:pehrsons]]

Ok, then I'll have to land without the compiler error that ensures this is fixed before reaching beta. Seems non-ideal but it is what it is.

Comment 72

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6e04dea4b4c3
Update bindgen to 0.69.1 and coreaudio-sys to 0.2.14. r=supply-chain-reviewers,glandium
https://hg.mozilla.org/integration/autoland/rev/8609d1fdbe1e
Update cubeb-coreaudio-rs to 964e1462. r=cubeb-reviewers,padenot

Comment 73

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/6e04dea4b4c3
https://hg.mozilla.org/mozilla-central/rev/8609d1fdbe1e

Comment 74

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

In-call workaround: Disconnect and reconnect the AirPods will temporarily fix the symptom, e.g. using the Bluetooth toggle in the upper right of macOS's menu bar, or by physically putting them in their case for a second.