1893939 - Audio crackling when AudioContext is used

Status: UNCONFIRMED

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

Description

[bugzilla]

Attachment: fenix-AudioContext.flac

Steps to reproduce:

Visit https://mdn.github.io/webaudio-examples/audio-basics/ and tap the play button on the boombox.

Actual results:

The sound plays, but with an annoying crackle.

Expected results:

It should sound the same as it does on desktop Firefox, or on Chrome for Android - a clear sound with no crackling.

Attached a short recording of the sound in Fenix, followed by the same sound on the same device (Fairphone 4) and recording setup on Chrome for comparison

Comment 1

[Jim Mathies [:jimm]]

Maybe Paul has some ideas.

Comment 2

[Paul Adenot (:padenot)]

Buffer size is likely too low. John, can you get us a performance profile on that device? https://profiler.firefox.com/docs/#/./guide-profiling-android-directly-on-device explains how, nothing to install, but please make sure to select the preset "Media". Paste the link here when that's done.

Comment 3

[bugzilla]

https://profiler.firefox.com/public/fkwy0ktp86d50ts4c0g1dk85eqc5hffs9tcsgkr

Comment 4

[bugzilla]

In case it matters: the screen locked at about 30 seconds in, and the crackling seemed to get significantly worse

Comment 5

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

The severity field is not set for this bug.
:padenot, could you have a look please?

For more information, please visit BugBot documentation.

Comment 7

[Paul Adenot (:padenot)]

We need to retry this.

Comment 8

[Andreas Pehrson [:pehrsons]]

I barely hear any underruns with the screen on, but they're plenty with the screen off or with the lock screen visible.

Comment 9

[Paul Adenot (:padenot)]

We should really get to the bottom of this, if that happens even with your recent changes. Maybe we should bump the latency even more?

Comment 10

[Andreas Pehrson [:pehrsons]]

I think my recent changes were input-specific. This is output-only realtime audio.

Comment 11

[Karl Tomlinson (:karlt)]

Those input-specific changes were https://github.com/mozilla/cubeb/pull/790, I assume.

Comment 12

[Karl Tomlinson (:karlt)]

https://profiler.firefox.com/public/fkwy0ktp86d50ts4c0g1dk85eqc5hffs9tcsgkr has 11.4ms spend in DataCallback at 36.577s, while the budget is only 5.3ms.
The long duration in DataCallback seems to be an exception.

The DataCallback was already late, at 15ms since the previous callback.
The late callback is much more frequent issue.
Another, at 37.248s, is 26ms after the previous callback.

Comment 13

[Andreas Pehrson [:pehrsons]]

Having just looked into bug 1934566 I think this is what we configure AAudio with:

Before bug 1930825:

• sampling rate 48kHz
• cubeb's requested latency is 5.333ms (256 frames) (most likely, since it comes from Android's PROPERTY_OUTPUT_FRAMES_PER_BUFFER and 256 was observed for callback size)
• burst size (hw callback) probably matches PROPERTY_OUTPUT_FRAMES_PER_BUFFER 5.333ms (256 frames)
• buffer size not set, defaults to buffer capacity, so 16ms (768 frames)
• buffer capacity is 3x cubeb's requested latency, so 16ms (768 frames)
• callback size (user callback) is 5.333ms (256 frames) (its own buffer)

After bug 1930825:

• sampling rate 48kHz
• cubeb's requested latency is 21.333ms (1024 frames) (from here)
• burst size (hw callback) probably matches PROPERTY_OUTPUT_FRAMES_PER_BUFFER 5.333ms (256 frames)
• buffer size not set, defaults to buffer capacity, so 64ms (3072 frames)
• buffer capacity is 3x cubeb's requested latency, so 64ms (3072 frames)
• callback size (user callback) is 21.333ms (1024 frames) (its own buffer)

I imagine bug 1930825 brought some improvement.