Open Bug 1629286 Opened 11 months ago Updated 10 months ago

Firefox makes a buzzing sound when the audio backend is "jack"


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

75 Branch





(Reporter: yuri, Unassigned)


User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:75.0) Gecko/20100101 Firefox/75.0

Steps to reproduce:

1.Switch to the "jack" audio backend.
2. Navigate to any YouTube video and play it
3. Hit the "Back" button so that the browser would go to the previous page
4. Hear a buzzing sound.

Jack keeps playing the contents of the buffer left there when the client program stops adding new samples. The buffer needs to be reset to zero and/or connection to JACK needs to be closed.

Actual results:

Buzzing sound after the audio finishes.

Expected results:


I believe that this is a regression. Jack backend worked fine a few years ago when I tried it last.


We do not have right environment set up in order to reproduce this issue but I will set the component for it and maybe one of our developers will be able to reproduce it on their end.

In case you are abe to find the regression range yourself, here are the steps o do it correctly: (

install mozregression:
a. Download this executable:
b. Instal the app.
You have to determine a build that reproduces the issue. You have already done that: the latest Firefox ESR v68.2.0esr (64-bit), right? You can retest it anytime.
Then you should find one that does NOT reproduce it. Detailed steps:
a. Open Mozregression app;
b. Click "File" -> "Run a single build";
c. On the "Single Run Wizard" pop-up, "Basic configuration" page, change parameter "Build type" from "shippable" to "opt" and click "Next".
d. On the "Profile selection" page, just click the "Next" button.
e. On the "Build selection" page, change the "date" parameter to "release" by it's drop-down.
f. Then select a release number (numbers lower than 68 until you find one that does not reproduce the issue) on the from the drop-down on the left and click "Finish".
g. Now the mozregression app will open a firefox build of the selected release number and you can use it, close it and open another. (make a note of the version that does not reproduce the issue)
You will use mozregression app to "bisect" builds that reproduce the issue by builds that do not reproduce it in search of the one build/changeset that introduced the issue, in the first place:
a. Open mozregression-gui.exe
b. Click "File" -> "Run a new bisection"
c. On "Basic configuration" screen, select Build Type: "opt" and click "Next" button.
d. Skip "Profile selection" screen by the "Next" button.
e. On the Bisection wizard screen, you will need to select a build that reproduces the issue and one that does not:
e1. In the "Last known good build:" section, select "date" on the right drop-down and the date of the build you found NOT to reproduce the issue.
e2. In the "First known bad build:" section, select "date" on the right drop-down and the date of the build you found to reproduce the issue.
f. Click "Finish" to start the bisection process.
g. Builds will open one-by-one, you will need to test each one of them and see whether the issue reproduces. If it reproduces, then you need to select the "bad" button in the mozregression window and if not, you need to select the "good" button.
h. When bisection is done, you will have the information in the "Log View" section of the mozregression window; bisection may also fail due to not enough builds, but the logs can always be useful.
Copy the logs in a text file and attach it to this bug.
If there is still information you need regarding the regression process, please request information from me.

Thank you for your contribution! And thanks for the report.

Best regards,


Flags: needinfo?(yuri)
Component: Untriaged → Widget: Gtk
Product: Firefox → Core
Component: Widget: Gtk → Audio/Video: Playback

Resetting severity to default of --.

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --

Currently the JACK backend is supported by contributors. We'll accept patches for this, setting flags as appropriate.

Severity: -- → S4
Component: Audio/Video: Playback → Audio/Video: cubeb
Priority: -- → P5

The essence of this bug is that the application stops writing into a JACK buffer without clearing it in the end. Firefox should zero the buffer when there is nothing to write any more, not just leave it with the last data fragment.

Flags: needinfo?(yuri)

The fix should be very easy for the Jack backend maintainers.

You need to log in before you can comment on or make changes to this bug.