Closed Bug 1732466 Opened 3 years ago Closed 3 years ago

Broken microphone input on Linux Firefox after FF 90.0.2

Categories

(Core :: Audio/Video: MediaStreamGraph, defect)

Firefox 91
defect

Tracking

()

RESOLVED DUPLICATE of bug 1725810
Tracking Status
firefox-esr78 --- unaffected
firefox-esr91 --- wontfix
firefox92 --- wontfix
firefox93 --- fixed
firefox94 --- fixed

People

(Reporter: aafnbugzilla.map1bid, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:90.0) Gecko/20100101 Firefox/90.0

Steps to reproduce:

Easy way to reproduce the problem:

  • Enable your microphone
  • Start FF
  • Go to https://www.onlinemictest.com/
  • Accept all cookies (I guess this has no impact, but just to be rigorous in my test")
  • Start "The mic test"
  • Allow the microphone on the little FF pop-up
  • Emit a sinus-like wave in your mike (typically a humming sound works better than open mouth, as it produces a cleaner sinus wave)

Actual results:

The displayed sinus wave is not continuous, it is broken in pieces which makes a flashing line, like having packets of audio which separated by blanks or whatever

Note: the problem is very impacting !

  • I came to that simplified procedure to better identify the root cause.
  • However, the origin problem is that I can't use my webex session due to that = other people in the meeting cannot hear me correctly, my voice is cracky, distorded, interrupted, and so not intelligible
    => this breaking remote web sessions functionality for me, I have to stay with FF 90.0.2 for things to work

Expected results:

The displayed wave should be a smooth uninterrupted sinus-like line, slowly moving, but no hashed / packet / flashy behavior

(and of course, in my Webex sessions, people can clearly hear me, my voice is fully audible and intelligible)

I made a mozregression bisection using my simplified and easy procedure above, and that identified the root for the problem as being the fix for bug 1702646
whose description corresponds very well to the domain and effects I am observing (audio segments and interleaved buffers).

Here is the last part of the bisection:

2021-09-24T16:12:33.754000: INFO : Narrowed integration regression window from [fe803065, f0c73621] (3 builds) to [3793e0a6, f0c73621] (2 builds) (~1 steps left)
2021-09-24T16:12:33.760000: DEBUG : Starting merge handling...
2021-09-24T16:12:33.760000: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=f0c736218ab6592dbd8f973af162fbac414266fd&full=1
2021-09-24T16:12:33.760000: DEBUG : redo: attempt 1/3
2021-09-24T16:12:33.760000: DEBUG : redo: retry: calling _default_get with args: ('https://hg.mozilla.org/integration/autoland/json-pushes?changeset=f0c736218ab6592dbd8f973af162fbac414266fd&full=1',), kwargs: {}, attempt #1
2021-09-24T16:12:33.762000: DEBUG : urllib3.connectionpool: Resetting dropped connection: hg.mozilla.org
2021-09-24T16:12:35.017000: DEBUG : urllib3.connectionpool: https://hg.mozilla.org:443 "GET /integration/autoland/json-pushes?changeset=f0c736218ab6592dbd8f973af162fbac414266fd&full=1 HTTP/1.1" 200 None
2021-09-24T16:12:35.079000: DEBUG : Found commit message:
Bug 1702646 - Add an util-function to append interleaved buffer in AudioSegment r=padenot

Add an utility function named AppendFromInterleavedBuffer in
AudioSegment to append data from the given interleaved buffer. This
function does the same job as what AudioInputProcessing::InsertInGraph
and NativeInputTrack::ProcessInput were used to do. As a result, these
two functions can be eliminated or simplified.

Depends on D116673

Differential Revision: https://phabricator.services.mozilla.com/D116674

2021-09-24T16:12:35.079000: DEBUG : Did not find a branch, checking all integration branches
2021-09-24T16:12:35.083000: INFO : The bisection is done.
2021-09-24T16:12:35.085000: INFO : Stopped

AS said above, this is a very impacting bug, I simply can't use anything based on my microphone, whichever microphone I use (internal, headset .. etc ..), and in particular cannot participate in web meetings for my job, as I work remotely like many of us in these Covid times.

Only workaround I have for now is to stay on FF 99.0.2

Thanks, aaFn.

Has Regression Range: --- → yes
Component: Untriaged → Audio/Video: MediaStreamGraph
Keywords: regression
Product: Firefox → Core
Regressed by: 1702646

Chun-Min, I think this is already fixed by 1725810, which is in 91?

Reporter, please try to upgrade and see if this is fixed ?

Flags: needinfo?(cchang)
Flags: needinfo?(aafnbugzilla.map1bid)

Hello, bug 1725810 is not in FF 91.
I see it is a candidate for FF 93 for now.
And I confirm the problem is still active in latest 92.0.1

If it is in some nightly build that I can test, let me know.

Flags: needinfo?(aafnbugzilla.map1bid)

Indeed, my mistake, it's in 93, to be released soon (2021-10-05). A Nightly (https://www.mozilla.org/fr/firefox/channel/desktop/#nightly) or Beta (https://www.mozilla.org/fr/firefox/channel/desktop/#beta) will have the fix, if you want to try. You can simply decompress and run after having closed all Firefox instance, to test.

I tested with 93b9. Althought the sine wave is not as nice as in 90, things are not "packetized" / distorted anymore, and I checked in a meeting, and voice is again audible and intelligible.

So I guess that will do it, thank you.

Interesting that it's "not as nice", it should be strictly equivalent. Are you able to make a recording?

Cross-platform instructions are here: https://docs.google.com/document/d/1WY65bzjngZASzKD3XsodNbiFgrMqYCHpwVgvQ7pMy9w/edit?usp=sharing, but for the Linux desktop it boils down to:

MOZ_DUMP_AUDIO=1 MOZ_DISABLE_CONTENT_SANDBOX=1 path/to/firefox

the contents of the files are explained in the document above, if you can attach the files for output and input here, we can have a look.

So I tested again on FF 90.0.2 .. and bear with me, this must be my voice of today which is not as "clean" as during my test last Friday, as I see also there that the sine wave is "not as nice" as then (I promise, I am not a smoker :-D )

So please disregard my comment on "not as nice", and consider 93b9 contains the fix to this problem.

Thank you, aaFn.

Thanks for double-checking everything, with us, and sorry about the problem in the first place.

I'm closing this as a duplicate, please comment or open a new bug should you have any new issue!

Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(cchang)
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.