1934566 - www.merriam-webster.com - Audio playback of word pronunciation is distorted

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Raul Bucata]

Environment:
Operating system: Android 14
Firefox version: Firefox Mobile 132.0

Steps to reproduce:

1. Navigate to: https://www.merriam-webster.com/dictionary/matriculate
2. Click on the speaker icon located near a word
3. Observe the word audio pronunciation

Expected Behavior:
Audio is flawless

Actual Behavior:
Audio playback is distorted

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in firefox-nightly, and firefox-release
• Does not reproduce in chrome

Created from https://github.com/webcompat/web-bugs/issues/144629

Comment 1

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 2

[Dennis Schubert [:denschub]]

Might be bug 1893939?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

Easily reproed by me on android; works in chrome

Comment 4

[az [:az]]

Here's a profile of it reproing on my side.

Comment 5

[az [:az]]

I dug into this a bit more - seems like this is regressed by bug 1905636. 2024-06-30 Fenix nightly works fine, 2024-07-01 repros. If I check out 2024-07-01 and drop the bugfix the crackling clears up.

Comment 6

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

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

Comment 7

[Andreas Pehrson [:pehrsons]]

The profile shows this is playback, so latency and callback size is 100ms (4800 frames).
If I read AAudio and libaudioclient code right, then:

Before bug 1905636:

• burst size (hw callback) unclear but typically 5ms (240 frames)
• buffer size set to 3x the burst size, so 15ms (720 frames)
• buffer capacity is cubeb's requested latency, so 100ms (4800 frames)
• callback size (user callback) is cubeb's requested latency so 100ms (4800 frames) (its own buffer)

Note the comment on setting the callback size:

 * If you do call this function then the requested size should be less than
 * half the buffer capacity, to allow double buffering.

After bug 1905636:

• burst size (hw callback) unclear but typically 5ms (240 frames)
• buffer size not set, defaults to buffer capacity, so 300ms (14400 frames)
• buffer capacity is 3x cubeb's requested latency, so 300ms (14400 frames)
• callback size (user callback) is cubeb's requested latency so 100ms (4800 frames) (its own buffer)

From trying the STR on my own device I hear a gap of silence in the sound early on, then a premature end. It seems to me as if we receive more user callbacks right away in order to fill the larger buffer, but underrun in our buffer of decoded data, so insert silence into the stream (supported by the profile). The premature end probably means we don't drain the stream properly.

Keeping the ni? for now to keep this high on the list.

Comment 8

[Andreas Pehrson [:pehrsons]]

Looking at cubeb_aaudio.cpp, we handle draining by calling AAudioStream_requestStop which ends up calling AudioTrack::stop which seems to do the right thing:

    /* Stop a track.
     * In static buffer mode, the track is stopped immediately.
     * In streaming mode, the callback will cease being called.  Note that obtainBuffer() still
     * works and will fill up buffers until the pool is exhausted, and then will return WOULD_BLOCK.
     * In streaming mode the stop does not occur immediately: any data remaining in the buffer
     * is first drained, mixed, and output, and only then is the track marked as stopped.

Comment 10

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

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

Comment 11

[Andreas Pehrson [:pehrsons]]

The main issue was fixed in bug 1938570. Bug 1940733 fixed an additional issue (Android-specific) that I came across.