Closed Bug 1489052 Opened 6 years ago Closed 6 years ago

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

Categories

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

x86_64
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla64
Tracking Status
firefox-esr60 --- wontfix
firefox62 --- wontfix
firefox63 --- verified
firefox64 --- verified

People

(Reporter: jya, Assigned: jya)

References

Details

Attachments

(1 file)

Connect the Momentum M2 over BT go to a appear.in video call people can't hear you. works in Chrome
interestingly https://mdn.github.io/voice-change-o-matic/ shows that audio is heard just fine.
Priority: -- → P3
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?
Flags: needinfo?(jyavenard)
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
With the Sony, other person could hear me but I couldn't hear them
Summary: Can't get audio to work over BT with Seinheiser Momentum M2 → Can't get audio to work over BT with Bluetooth headset
This needs to be backported, make BT headset unusable on mac otherwise
Flags: needinfo?(jyavenard)
This probably fixes bug 1443716 too.
See Also: → 1443716
(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.
(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 on attachment 9009595 [details] Bug 1489052 - Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246. Paul Adenot (:padenot) has approved the revision.
Attachment #9009595 - Flags: review+
Pushed by jyavenard@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/169eb24672a7 Resync cubeb to b832dae6e48d3a95d1e6d977d0b7c53a873fd246. r=padenot
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Assignee: nobody → jyavenard
Blocks: 1492488
No longer blocks: 1492488
See Also: → 1492488
Please request uplift when you get a chance.
Flags: needinfo?(jyavenard)
(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 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]:
Flags: needinfo?(jyavenard)
Attachment #9009595 - Flags: approval-mozilla-beta?
Priority: P3 → P2
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.
Attachment #9009595 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+
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.
Status: RESOLVED → VERIFIED
(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.
Status: VERIFIED → RESOLVED
Closed: 6 years ago6 years ago
(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.
Flags: needinfo?(brindusa.tot)
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.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
Flags: needinfo?(brindusa.tot)
See Also: → 1500109
Depends on: 1501605
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: