1947917 - firefox android 135 audio crackling on any website while playing video or audio

Status: RESOLVED FIXED

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

Description

[hanuy]

Firefox for Android

Steps to reproduce:

Since v135 on Android, Firefox is emitting popping and crackling noise when playing audio or video on any website (very annoying). It is consistent and happens all the time during media reproduction. Same content is played without these noises on any other browser on the same device (Chrome, Samsung Internet, etc.).
This behavior never happened on versions previous to 135.

Need to rollback to previous version in order to eliminate issue, please fix ASAP, thanks!

Actual results:

Audio quality is bad due to constant popping and crackling sounds.

Expected results:

Audio should be clean without crackling sounds.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[az [:az]]

Could you paste the contents of your about:support here?

Are there any websites where this happens more often than others? Is there anything that seems to make the problem worse?

Capturing a profile of this behavior would be helpful. Close all open tabs, and follow the directions here to set up the profiler. Then, start the profiler (make sure to choose the "Media" profile), load up a site that has the popping and crackling noise, let it pop and crackle for a bit, and then stop the profiler and paste the link here or send it directly to me.

You could also check to see if the behavior persists on Firefox Nightly - with any luck, a patch has already landed to clear it up.

Thanks!

Comment 4

[az [:az]]

pehrsons, would you have any insight here?

Comment 5

[Cragsand]

Haven't found any workaround for this other than using an older version, 134 or older.

User Agent: Mozilla/5.0 (Android 12; Mobile; rv:135.0) Gecko/135.0 Firefox/135.0
My device is a Samsung Galaxy S10E

Play a YouTube video or any other embedded player. It's the same for all media players on news sites and video sharing sites.

The audio crackles and pops every 2-10 seconds. It's not super obvious right away if you have bad speakers or is not wearing headphones.

The issue is only present in Firefox Android V135 and forward. Also occurs on Firefox Android Beta V136.

Its millisecond long audio interrups that occur inconsistently but regularly enough that it's very noticable, especially when playing music.

Here's a video recording showing the problem and comparing it with Fennec V134 where the issue is not present: https://m.youtube.com/shorts/_oIkQUjLYUk
The testing video: https://www.youtube.com/watch?v=iR-K2rUP86M

The problem is actually worse than what is heard in the recording, likely the screen recording encoder makes the pops sporter than they really are.

Comment 6

[az [:az]]

Didn't attach the NI to my earlier message, so doing so now.

Comment 7

[Andreas Pehrson [:pehrsons]]

Android 12 which is API level 31 or 32 => we use AAudio.

A regression from bug 1938570 is likely. Marking it tentatively.
I cannot reproduce on my Galaxy S22.
134 used significantly more buffering, something like 300ms. Now we use a 50ms AAudio buffer for a 100ms callback. This means we put 100ms into the callback, which then fills the 50ms AAudio buffer and is blocked until empty. When the callback buffer becomes empty it gets dispatched again to the content process to get more data, and it has the 50ms worth of data in the AAudio buffer to return. If it doesn't, we underrun.

I imagine bug 1931080 would help here but would need a profile to verify the root cause. Unfortunately getting a profile on Android involves connecting it to a computer and controlling it there. I hope we can find someone to reproduce this internally.

We could try a simpler verification if either reporter is up for it:

• Install Firefox Nightly
• Go to about:config (not available on release, sorry)
• Click the plus sign to create a new pref
• Name: media.cubeb_latency_playback_ms
• Type: Integer
• Value: 200
• Click "Create"
• We'll now use a 100ms AAudio buffer and 200ms callback buffer, which should be plenty.
• Kill the app and relaunch it, optionally verifying that the pref is still there.
• Try to reproduce. Did this improve the situation?

Thanks in advance!

Comment 8

[guillaume brun]

i also got this annoying sound bug.
this bug appear with Firefox for Android 135 on Lenovo Tab P12 (Android 14)
no bug sound with Firefox for Android 134 or Chrome.
site where i find the bug : twitch, youtube, but i think all site with audio have it.

how to reproduce:
on Firefox for Android 135 open https://music.youtube.com/watch?v=XqoanTj5pNY (cancel open in another app)
use a Bluetooth headphone, you should ear cracking noise.

just try config media.cubeb_latency_playback_ms with 200 and 100 with no luck,
but 75 and 50 seams to be ok.

Comment 9

[Cragsand]

Profiler run on a fresh install of Firefox Nightly 137.0a1 where the issue is present
https://profiler.firefox.com/public/vgrqc15hjz0a0zp1b7zy8cd6hmp4zq7nfnnz1f8

What I did in total during the profiling:

1. Visited https://www.youtube.com/watch?v=iR-K2rUP86M
2. Watched an ad that has the audio crackling present
3. Watched about 40 seconds of the video where the audio crackling is present.

Device is a Samsung Galaxy S10E

Comment 10

[Cragsand]

(In reply to Andreas Pehrson [:pehrsons] from comment #7)

Android 12 which is API level 31 or 32 => we use AAudio.

A regression from bug 1938570 is likely. Marking it tentatively.
I cannot reproduce on my Galaxy S22.
134 used significantly more buffering, something like 300ms. Now we use a 50ms AAudio buffer for a 100ms callback. This means we put 100ms into the callback, which then fills the 50ms AAudio buffer and is blocked until empty. When the callback buffer becomes empty it gets dispatched again to the content process to get more data, and it has the 50ms worth of data in the AAudio buffer to return. If it doesn't, we underrun.

I imagine bug 1931080 would help here but would need a profile to verify the root cause. Unfortunately getting a profile on Android involves connecting it to a computer and controlling it there. I hope we can find someone to reproduce this internally.

We could try a simpler verification if either reporter is up for it:

• Install Firefox Nightly
• Go to about:config (not available on release, sorry)
• Click the plus sign to create a new pref
• Name: media.cubeb_latency_playback_ms
• Type: Integer
• Value: 200
• Click "Create"
• We'll now use a 100ms AAudio buffer and 200ms callback buffer, which should be plenty.
• Kill the app and relaunch it, optionally verifying that the pref is still there.
• Try to reproduce. Did this improve the situation?

Thanks in advance!

Did this, killed the app, checked that the preference was present in about:config but unfortunately the issue is still there.

Comment 11

[galaxy]

(In reply to Andreas Pehrson [:pehrsons] from comment #7)

Android 12 which is API level 31 or 32 => we use AAudio.

A regression from bug 1938570 is likely. Marking it tentatively.
I cannot reproduce on my Galaxy S22.
134 used significantly more buffering, something like 300ms. Now we use a 50ms AAudio buffer for a 100ms callback. This means we put 100ms into the callback, which then fills the 50ms AAudio buffer and is blocked until empty. When the callback buffer becomes empty it gets dispatched again to the content process to get more data, and it has the 50ms worth of data in the AAudio buffer to return. If it doesn't, we underrun.

I imagine bug 1931080 would help here but would need a profile to verify the root cause. Unfortunately getting a profile on Android involves connecting it to a computer and controlling it there. I hope we can find someone to reproduce this internally.

We could try a simpler verification if either reporter is up for it:

• Install Firefox Nightly
• Go to about:config (not available on release, sorry)
• Click the plus sign to create a new pref
• Name: media.cubeb_latency_playback_ms
• Type: Integer
• Value: 200
• Click "Create"
• We'll now use a 100ms AAudio buffer and 200ms callback buffer, which should be plenty.
• Kill the app and relaunch it, optionally verifying that the pref is still there.
• Try to reproduce. Did this improve the situation?

Thanks in advance!

Noticed the problem for firefox nightly about 2-5 weeks ago and since then its spread to every firefox android app. The fix you mentioned did work, but not with media.cubeb_latency_playback_ms set to 200. It worked by setting it to 50 (as one one previous mentioned) and the audio artifacts appears to be gone.

Comment 12

[Cragsand]

That actually seems to work!

To summarize for anyone else having this problem with crackling and popping audio the following workaround also works on the Stable version of Firefox Android.

1. Go to the secret about:config page since the default one is disabled on the main stable version. Copy and paste the following into your adress bar and hit go:
   chrome://geckoview/content/config.xhtml
2. Click the plus sign to create a new preference and name it:
   media.cubeb_latency_playback_ms
3. Select type: Integer and set Value: 50
4. Click "Create"
5. Kill the app from app manager and restart it.

Cheers!

Comment 13

[johan]

(In reply to Cragsand from comment #12)

That actually seems to work!

To summarize for anyone else having this problem with crackling and popping audio the following workaround also works on the Stable version of Firefox Android.

1. Go to the secret about:config page since the default one is disabled on the main stable version. Copy and paste the following into your adress bar and hit go:
   chrome://geckoview/content/config.xhtml
2. Click the plus sign to create a new preference and name it:
   media.cubeb_latency_playback_ms
3. Select type: Integer and set Value: 50
4. Click "Create"
5. Kill the app from app manager and restart it.

Cheers!

Seems to work for me, thanks 🙂

Comment 14

[hanuy]

I can also confirm that workaround given is effective and resolving the issue.

Will this be included in the next releases? The latency value modified manually will be overwritten with the next version of Firefox and will need to be reapplied again on user side?

Thanks!

Comment 15

[Lauchlin]

(In reply to Cragsand from comment #12)

That actually seems to work!

To summarize for anyone else having this problem with crackling and popping audio the following workaround also works on the Stable version of Firefox Android.

1. Go to the secret about:config page since the default one is disabled on the main stable version. Copy and paste the following into your adress bar and hit go:
   chrome://geckoview/content/config.xhtml
2. Click the plus sign to create a new preference and name it:
   media.cubeb_latency_playback_ms
3. Select type: Integer and set Value: 50
4. Click "Create"
5. Kill the app from app manager and restart it.

Cheers!

Can confirm this workaround seems to also work on Lenovotab m11 (with or without bluetooth earbuds).

Comment 16

[Andreas Pehrson [:pehrsons]]

[Tracking Requested - why for this release]: Any audio playback may have glitches. Seems to depend on device, with higher prevalence on lower-end devices, probably due to system load being higher as our audio thread scheduling isn't great. May also

Thanks for the help so far. I also got my hands on an S10e and am debugging on it. It has just been factory reset, so not much background workload to speak of, and I'm using the Geckoview Example which also does less in the background. All in all I cannot reproduce because there is less timing variation, but I understand the problem.

Note setting the latency to 50ms works because then we tell the platform to use a low latency stream, as opposed to a power saving stream, and also the buffering logic works slightly differently. This threshold is at 4000 frames latency (which for the most common sample rate of 48k is at 83.3ms).

What happens on the S10e is roughly this order of events:

• cubeb is told by Gecko to create a 100ms (4800 frames) latency stream
• cubeb tells AAudio to create a stream with 200ms (9600 frames) buffer capacity and 100ms callback buffer size
• AAudio creates a stream with a 66.6ms (3200 frames) burst size
• cubeb tells the AAudio stream in this case to set the buffer size (has to fit within the capacity) to 3200 frames

So buffer sizes per burst should look something like (-> being an aaudio callback):

• start: aaudio=0, callback=0 -> aaudio=3200, callback=1600
• burst1: aaudio=1600, callback=0 -> aaudio=3200, callback=3200
• burst2: aaudio=3200, callback=0 -> aaudio=3200, callback=4800
• burst3: aaudio=3200, callback=1600 (no aaudio callback)
• go to burst1

The callback timing observed in a profile of my S10e is (d being system time since previous callback):

• cb1: t=0 (start)
• cb2: t=152ms (d=152ms; burst0?)
• cb3: t=308ms (d=156ms; burst1)
• cb4: t=379ms (d=71ms; burst2)
• cb5: t=509ms (d=130ms; burst1)
• cb6: t=578ms (d=69ms; burst2)
• ...

Similarly the profile in comment 9 shows:

• cb1: t=0 (start)
• cb2: t=610ms (d=610ms; burst0?)
• cb3: t=727ms (d=117ms; burst1)
• cb4: t=798ms (d=71ms; burst2)
• cb5: t=938ms (d=140ms; burst1)
• cb6: t=1005ms (d=67ms; burst2)
• ...

So a 66ms cadence with every 3rd callback is absent. Fits the bill.
I'm not sure where the glitches come from. We seem to serve the audio callbacks rather timely. But a buffer size of a single burst does seem a bit unnecesssary, especially with the mismatch between burst size and callback size only leaving 33ms in the AAudio buffer at the lowest point. Interestingly doubling the requested latency to 200ms essentially doubles all numbers above and glitches are still reported. I can only assume something further down the stack causes it.

Let's prototype a fix with a buffer of at least 2* the burst size.

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1938570

Comment 18

[Andreas Pehrson [:pehrsons]]

I have a minimal candidate for a fix here. This is a link to our try server, where you can inspect the change if you prefer. The link to a testable APK is here. It is for our "GeckoView Example" test app -- it's the same engine as Firefox for Android but with minimal UI. It behaves the same wrt web content. Please test and let me know whether or not it helps.

Would those who can reproduce the issue give this one a shot? I'll throw some needinfos around. Note the more devices tested the better, but also any signal is better than no signal!

I have tested on a Galaxy S10e and a Galaxy S22. Both sound good, but then again I couldn't reproduce before.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Too late to fix for 135 at this point, but keeping it on the radar for 136+.

Comment 20

[galaxy]

(In reply to Andreas Pehrson [:pehrsons] from comment #18)

I have a minimal candidate for a fix here. This is a link to our try server, where you can inspect the change if you prefer. The link to a testable APK is here. It is for our "GeckoView Example" test app -- it's the same engine as Firefox for Android but with minimal UI. It behaves the same wrt web content. Please test and let me know whether or not it helps.

Would those who can reproduce the issue give this one a shot? I'll throw some needinfos around. Note the more devices tested the better, but also any signal is better than no signal!

I have tested on a Galaxy S10e and a Galaxy S22. Both sound good, but then again I couldn't reproduce before.

With that app, the audio artifacts seems to be gone for my S10 Lite. So it appeared to solve the problem!

Comment 22

[Andreas Pehrson [:pehrsons]]

(In reply to galaxy from comment #20)

(In reply to Andreas Pehrson [:pehrsons] from comment #18)

I have a minimal candidate for a fix here. This is a link to our try server, where you can inspect the change if you prefer. The link to a testable APK is here. It is for our "GeckoView Example" test app -- it's the same engine as Firefox for Android but with minimal UI. It behaves the same wrt web content. Please test and let me know whether or not it helps.

Would those who can reproduce the issue give this one a shot? I'll throw some needinfos around. Note the more devices tested the better, but also any signal is better than no signal!

I have tested on a Galaxy S10e and a Galaxy S22. Both sound good, but then again I couldn't reproduce before.

With that app, the audio artifacts seems to be gone for my S10 Lite. So it appeared to solve the problem!

Thanks, I'll get it landed!

Comment 23

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1947917 - Add cubeb patch to increase AAudio buffering when not doing low-latency and re-vendor. r?padenot

Comment 24

[Andreas Pehrson [:pehrsons]]

Attachment: Bug 1947917 - Add cubeb patch to increase AAudio buffering when not doing low-latency and re-vendor. r?padenot

Original Revision: https://phabricator.services.mozilla.com/D238767

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/466537a4e851
Add cubeb patch to increase AAudio buffering when not doing low-latency and re-vendor. r=padenot,cubeb-reviewers

Comment 26

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Audio glitches during playback
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Play audio. E.g from youtube, spotify, other services, files. Listen for glitches, i.e. tiny gaps in the audio. If no glitches are obvious without the fix you may try to provoke them by doing other things (causing higher load) on the device.
• Risk associated with taking this patch: Low
• Explanation of risk level: Simple doubling of the buffering level in AAudio. No logic changes, but may consume more decoded data at the start of playback. I have checked that we haven't re-regressed bug 1934566 on the devices I have available.
• String changes made/needed: None
• Is Android affected?: yes

Comment 27

[Kacper]

(In reply to Andreas Pehrson [:pehrsons] from comment #18)

I have a minimal candidate for a fix here. This is a link to our try server, where you can inspect the change if you prefer. The link to a testable APK is here. It is for our "GeckoView Example" test app -- it's the same engine as Firefox for Android but with minimal UI. It behaves the same wrt web content. Please test and let me know whether or not it helps.

Would those who can reproduce the issue give this one a shot? I'll throw some needinfos around. Note the more devices tested the better, but also any signal is better than no signal!

I have tested on a Galaxy S10e and a Galaxy S22. Both sound good, but then again I couldn't reproduce before.

I can confirm that this example APK solved this issue for me on Pixel 9

Comment 29

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/466537a4e851

Comment 30

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/3688ba31eb0a