1489052 - Can't get audio to work over BT with Bluetooth headset

Status: VERIFIED FIXED

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

Description

[Jean-Yves Avenard [:jya]]

Connect the Momentum M2 over BT
go to a appear.in video call

people can't hear you.

works in Chrome

Comment 1

[Jean-Yves Avenard [:jya]]

interestingly
https://mdn.github.io/voice-change-o-matic/ shows that audio is heard just fine.

Comment 2

[Matthew Gregan [:kinetik]]

Does cubeb logging show anything interesting if you repro with it enabled? Or (given the voice changer works), is something going wrong at a level above cubeb?

Comment 3

[Jean-Yves Avenard [:jya]]

I got a Sony WH-1000XM3, issue is the same.. Works in Chrome just fine but not Firefox.

Will run it again with logs next time I'm in a call

Comment 4

[Jean-Yves Avenard [:jya]]

With the Sony, other person could hear me but I couldn't hear them

Comment 6

[Jean-Yves Avenard [:jya]]

This needs to be backported, make BT headset unusable on mac otherwise

Comment 7

[Jean-Yves Avenard [:jya]]

https://github.com/kinetiknz/cubeb/pull/457

Comment 8

[Matthew Gregan [:kinetik]]

This probably fixes bug 1443716 too.

Comment 9

[Matthew Gregan [:kinetik]]

(In reply to Matthew Gregan [:kinetik] from comment #8)
> This probably fixes bug 1443716 too.

Not quite.  I tested this and with PR457 applied, we now hit the new assert just before calling into the resampler.

Comment 10

[Matthew Gregan [:kinetik]]

(In reply to Matthew Gregan [:kinetik] from comment #9)
> Not quite.  I tested this and with PR457 applied, we now hit the new assert
> just before calling into the resampler.

Specifically, I hit https://github.com/kinetiknz/cubeb/blob/master/src/cubeb_audiounit.cpp#L639 with input_frames >= output_frames == false.  input_frames == 512, output_frames == 1411.  We never stuff silence into input_linear_buffer because available_input_frames == 1412 but input_linear_buffer.length() == 512.

I suspect that's because we recreate input_linear_buffer when the device is reinitialized after we hit kAudioUnitErr_CannotDoInCurrentContext, but available_input_frames is not reset.

Comment 11

[Jean-Yves Avenard [:jya]]

Attachment: Bug 1489052 - Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246.

Comment 12

[Paul Adenot (:padenot)]

Comment on attachment 9009595 [details]
Bug 1489052 - Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246.

Paul Adenot (:padenot) has approved the revision.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/169eb24672a7
Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246. r=padenot

Comment 14

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/169eb24672a7

Comment 16

[Julien Cristau [:jcristau] (back April 22)]

Please request uplift when you get a chance.

Comment 17

[Jean-Yves Avenard [:jya]]

(In reply to Julien Cristau [:jcristau] from comment #16)
> Please request uplift when you get a chance.

how long can I bake it for in central?

Comment 18

[Jean-Yves Avenard [:jya]]

Comment on attachment 9009595 [details]
Bug 1489052 - Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246.

Approval Request Comment
[Feature/Bug causing the regression]: none
[User impact if declined]: BT headsets won't work with mac
[Is this code covered by automated tests?]: no, too hard to simulate those
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: yes. Steps can be easily reproduced using a BT headset that supports both the handsfree profile and the A2DP one (the most common type)
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: medium.
[Why is the change risky/not risky?]: it's a rather extensive change, however it has been well tested over the past two weeks in nightly. There's also quite a lot of bugs that were fixed in the process.
[String changes made/needed]:

Comment 19

[Pascal Chevrel:pascalc]

Comment on attachment 9009595 [details]
Bug 1489052 - Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246.

Approved for 63 beta 10 as it is a visible bug for end-user affecting popular headsets and we have duplicates. Thanks.

Comment 20

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/releases/mozilla-beta/rev/dbf63fb2036a

Comment 22

[Andrei Bodea[:andrei]]

Confirm this issue as fixed on the Beta build version 63.0b13 with Google Pixel C(Android 8.0.0) following the information from the Comment 18.

Comment 23

[Paul Adenot (:padenot)]

(In reply to AndreI Bodea from comment #22)
> Confirm this issue as fixed on the Beta build version 63.0b13 with Google
> Pixel C(Android 8.0.0) following the information from the Comment 18.

This is an OSX bug.

Comment 24

[Ioana Chiorean]

(In reply to Paul Adenot (:padenot) from comment #23)
> (In reply to AndreI Bodea from comment #22)
> > Confirm this issue as fixed on the Beta build version 63.0b13 with Google
> > Pixel C(Android 8.0.0) following the information from the Comment 18.
> 
> This is an OSX bug.

Sorry for that - was a direct request from Desktop team and missed to check the platform. Back to Desktop side.

Comment 25

[Daniel Bodea [:danibodea]]

Hello,

I am attempting to verify the fixes on a MacBook with Mac OS X 10.13.6 with a Bluetooth Plantronics S5XX17 headset, in a appear.in video call with another Mac OS.

On an affected build, Nightly v64.0a1 from 2018-09-15, the video call was made, the video was decent on both machines, but sound would not be heard at all on either of the systems (after making sure that output and input were properly set up).
On the fixed build, Nightly v64.0a1 from 2018-10-12, both the video and audio of the call was behaving nicely.
Considering uplift to Beta, I have tested the fix in Beta v63.0b13, both the video and audio were behaving nicely.

Uplift successful! Thank you.