Closed Bug 1469152 Opened Last year Closed Last year

mono audio plays only in the left speaker (OS X, 61+)

Categories

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

x86
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox60 --- unaffected
firefox61 --- wontfix
firefox62 + fixed
firefox63 --- fixed

People

(Reporter: asqueella, Assigned: jya)

References

Details

(Keywords: regression)

Attachments

(3 files)

Attached file about-support
Similar to bug 1461131, when playing the "Test file" on https://www.audiocheck.net/audiotests_frequencychecklow.php , sound only comes from the left speaker for me.

Unlike that bug, I can reproduce in the current nightly (62) and beta (61), but not on 60esr.

This is on an old OS X (10.9.5), clean Firefox profile. The media section of about:support has this:

Audio Backend: audiounit
Max Channels: 2
Preferred Sample Rate: 44100
Output Devices
Name: Group
Headphones: AppleHDAEngineOutput:1B,0,1,1:0
Input Devices
Name: Group
Internal microphone: AppleHDAEngineInput:1B,0,1,0:1
I originally encountered this trying to listen to a ted talk: https://www.ted.com/talks/sam_rodriques_neuroscience_s_next_100_years
Do you get the same issue with Safari?

Launching the MIDI utility, do you see any channels remap?

I'm not aware of the mac audio backend ever doing this.
Flags: needinfo?(asqueella)
Can't reproduce on MBP with 10.13.3
Good to know it's just me! I'm willing to assume it's because I'm stuck on an ancient OS X version -- should I close the bug?

I should have mentioned that Safari (and Chrome) are dealing with the link in the description just fine, playing (presumably the same sound) both through the left and the right headphone.

I'm not sure how remapped channels would look like and I'm not familiar with the "MIDI utility", so I've attached the screenshot of the only MIDI-related app I found on the system ("Audio MIDI Setup").

Note that most audio (e.g. Google Music, and the youtube videos I tried) plays fine in the Nightly (I assume because they're stereo).
Flags: needinfo?(asqueella)
Its obviously a regression since it works in esr60.

Could you run mozregression utility to determine the exact change that caused this. I have an idea, but better be sure... https://mozilla.github.io/mozregression/install.html
Rank: 19
Component: Audio/Video → Audio/Video: Playback
Priority: -- → P2
Component: Audio/Video: Playback → Audio/Video: cubeb
Flags: needinfo?(asqueella)
Several audio-related changes in that range.
Has Regression Range: --- → yes
Flags: needinfo?(jyavenard)
I've been toying with standalone cubeb on the weekend and I've been able to repro this one. I'm using a Focusrite Scarlet 6i6, running El Capitan (OSX 10.11.6), was configuring a cubeb stream to output mono, and I only had audio in the left speaker, so this is very likely a problem in the cubeb part of the changes above.

I think I should be able to repro with the built-in sound card, but I don't think it matters.
Assignee: nobody → padenot
Flags: needinfo?(jyavenard)
I hope "me too" posts aren't a problem, but I thought I'd verify that the issue is replicatable: 

I'm on a Mac, OS 10.9, and when I updated to Firefox (quantum) 61.0, all mono files started playing on the left side only. Other browsers continued to play mono files through both speakers. I tried to run safe mode, dumped all my addons and refreshed firefox...  all to no avail. But once I went back one version and re-installed version 60, the issue was no longer present. It's maddening though, in that small itch I can't-quite-reach sort of way.
10.13.5, anything from version 61 onward, mono audio gets routed to left channel only.
(In reply to dakindred from comment #10)
> 10.13.5, anything from version 61 onward, mono audio gets routed to left
> channel only.

What audio card are you using?
Two problems at hand.

The one with macOS < 10.12, is the use of the kAudioUnitProperty_AudioChannelLayout API, it only exist from macOS 10.12 onward

https://developer.apple.com/documentation/audiotoolbox/1534199-generic_audio_unit_properties/kaudiounitproperty_audiochannellayout?language=objc

The other, are due to the use of audio card with high channel count (e.g. 9+), those cards report the first channels as known (left, right, center etc..) but all the other are listed as kAudioChannelLabel_Unknown. so we end up with a channel layout containing multiple times the same channel which isn't allowed.

When encountering either of those case, smart downmixing/upmixing doesn't occur, we just copy the channels we have and drop the excess ones.
We were using an audio API not available prior 10.12. Also add a workaround for 3rd party audio cards with unusually high channels count.

This cherry-pick cubeb commits 59f5cb4ba01f21c4ad87e9404d1e470408e18505 and dbd61924736fbe1a1caf1cbd544f7d197f1836f7
[Tracking Requested - why for this release]: annoying regression, let's get this fixed in beta if we can..
Comment on attachment 8990915 [details]
Bug 1469152: Fix playback on older macOS systems and some 3rd party audio cards.

Matthew Gregan [:kinetik] has approved the revision.

https://phabricator.services.mozilla.com/D2041
Attachment #8990915 - Flags: review+
Assignee: padenot → jyavenard
Change was verified by :padenot with his weird 14 channels audio card
Pushed by jyavenard@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/aa7fc71b0f23
Fix playback on older macOS systems and some 3rd party audio cards. r=kinetik
https://hg.mozilla.org/mozilla-central/rev/aa7fc71b0f23
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → mozilla63
Could you try with a tonight's nightly containing this and verify that the problem is fixed for you?

thank you
Flags: needinfo?(asqueella)
Thanks a lot! The 20180710222524 nightly indeed fixes the problem on the pages from comments 0 and 1.
Flags: needinfo?(asqueella)
Comment on attachment 8990915 [details]
Bug 1469152: Fix playback on older macOS systems and some 3rd party audio cards.

Approval Request Comment
[Feature/Bug causing the regression]: 1432779
[User impact if declined]: Invalid playback for some streams (mono) or people using non standard audio cards.
[Is this code covered by automated tests?]: no
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: First post description contains all the information
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: we retrieve the channel layout configuration like we used to in bug 1432779, and this is only used as fallback. So it can't regress things that used to work.
[String changes made/needed]: none
Attachment #8990915 - Flags: approval-mozilla-beta?
Comment on attachment 8990915 [details]
Bug 1469152: Fix playback on older macOS systems and some 3rd party audio cards.

Fix for regression on older macOS, from 61. Verified in nightly. Let's uplift for beta 8.
Attachment #8990915 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Someone using this external audio card https://audient.com/products/audio-interfaces/id22/tech-specs/
mentioned that it was still hearing thing on the left only.

I've ordered one to have a look at what's going on
Depends on: 1475642
Mozilla/5.0 (Machintosh; Intel Mac OS X 10.12; rv:63.0) Gecko/20100101 Firefox/63.0 (20180713100116)

I have tested this report on the latest Nightly build and Beta 62.0b8 using OS X 10.14 and 10.12. I'm not able to reproduce the issue. The audio output from the links in comment 0 & comment 1 is coming as expected from both speakers. Based on this and comment 20 I will mark this as verified on both Fx63 and Fx62
To see that bug you need to use either an external audio card with more than 2 channels out, or running macOS 10.11 or less
The idea here is, since we never saw the bug (the incorrect behavior) we can't really verify that the issue was fixed. (And apparently it wasn't.)
I have this issue (mono sound plays only in left speaker) in Firefox 61.0.1 on OS X 10.11.6 and a Focusrite Scarlett 18i20 audio interface. 

I tested Firefox Nightly 63.0a1 (2018-08-03) and it is indeed fixed for me in that version.
You need to log in before you can comment on or make changes to this bug.