Closed Bug 1914570 Opened 2 months ago Closed 2 months ago

smleaks.com - Audio is distorted

Categories

(Core :: Audio/Video: Playback, defect, P3)

Desktop
Linux
defect

Tracking

()

RESOLVED FIXED
132 Branch
Tracking Status
firefox132 --- fixed

People

(Reporter: rbucata, Assigned: padenot)

References

()

Details

(Keywords: webcompat:platform-bug, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:windows,mac,linux,android
impact:feature-broken
configuration:general
affects:all
branch:release

Attachments

(3 files)

Environment:
Operating system: Linux
Firefox version: Firefox 130.0

Steps to reproduce:

  1. Navigate to: https://smleaks.com
  2. Click on "Next Play audio" button
  3. Play an audio from the newly opened page and observe

Expected Behavior:
Audio plays as expected

Actual Behavior:
Audio is very 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/140651

NI?ing for this audio issue, should probably be moved to Core :: Audio/Video: Playback also. Fiddle link: https://jsfiddle.net/e6dkqguj/

Flags: needinfo?(padenot)
Assignee: nobody → padenot
Component: Site Reports → Audio/Video: Playback
Flags: needinfo?(padenot)
Product: Web Compatibility → Core

This refactors the method that fetches the layout from the same struct, and uses
it to fetch the SubFormat (that comes after the layout).

Spec: https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/WAVE.html

but it's clearer here:
https://learn.microsoft.com/fr-fr/previous-versions/dd757713(v=vs.85)
https://learn.microsoft.com/fr-fr/windows/win32/api/mmreg/ns-mmreg-waveformatextensible?redirectedfrom=MSDN

The first two bytes of the SubFormast (that is a GUID) is the format we're
looking for.

Web Audio API allows exercising the demuxer (unlike the Web Codecs API). I opted
to compare the audio instead of the files because there's various ways to make
valid RIFF files, and the existing method would compare byte per byte, and the
headers could be different.

Comparing the audio works well here.

Files generated like so:

sox -n -c 8 -r 48000 sine.wav synth 0.1 sine 480
ffmpeg -i sine.wav -c:a pcm_s16le 8ch-s16.wav
ffmpeg -i sine.wav -c:a pcm_f32le 8ch-f32le.wav

Severity: -- → S2
User Story: (updated)
Priority: -- → P3
Pushed by padenot@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/adbcf85fdaad Print the mimetype when logging an AudioInfo. r=media-playback-reviewers,karlt https://hg.mozilla.org/integration/autoland/rev/86f6571b3872 Use the SubFormat field to determine sample format when the format code is WAVE_FORMAT_EXTENSIBLE. r=media-playback-reviewers,karlt https://hg.mozilla.org/integration/autoland/rev/585aec33c0aa Test pcm f32 decoding when the demuxer is used. r=media-playback-reviewers,karlt
Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → FIXED
Target Milestone: --- → 132 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: