Open Bug 1899750 Opened 6 months ago Updated 6 months ago

retro.logidroflex.com -The sound starts to crackle when playing Rayman

Categories

(Core :: Web Audio, defect)

Product:
Core
Component:
Web Audio
Type:
defect

Tracking

()

People

(Reporter: rbucata, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

Environment:
Operating system: Windows 11
Firefox version: Firefox 128.0

Preconditions:
See Github report for credentials

Steps to reproduce:

  1. Navigate to: https://retro.logidroflex.com
  2. Search for Rayman and launch the game
  3. Observe the audio once the game starts

Expected Behavior:
Normal sound

Actual Behavior:
Crackling sounds

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in Firefox Nightly, Firefox Release
  • Does not reproduce in Chrome

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

Summary: retro.logidroflex.com -The sound starts to crackle and crackle when playing Rayman → retro.logidroflex.com -The sound starts to crackle when playing Rayman

Thank you very much, I'll give you identifiers here so you don't have to search in the previous conversation.

Username : supportmozilla
Password : 1D8@f4hdP

Website : https://retro.logidroflex.com/

This sounds like something the media team should look at.

Component: Site Reports → Audio/Video
Product: Web Compatibility → Core

Thanks for the report. I can see that AudioBufferSourceNode is used for sound. At currentTime=251.805333, an AudioBufferSourceNode is scheduled on the JS thread to start at 251.805333. By the time the audio rendering thread receives the message to start, it has likely already rendered for that time, and so the AudioBufferSourceNode starts late and does not align as intended with adjacent buffers.

D/WebAudioAPI 251.805333: GainNode 2 Connect() to GainNode 1
D/WebAudioAPI 251.805333: detune for 27912 SetValue value=0 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27912 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27912 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27912 Connect() to GainNode 2
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27912 Start(251.805333, 0, 2.22507e-308)
D/WebAudioAPI 251.805333: detune for 27913 SetValue value=0 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27913 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27913 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27913 Connect() to GainNode 2
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27913 Start(251.811138, 0, 2.22507e-308)
D/WebAudioAPI 251.805333: detune for 27914 SetValue value=0 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27914 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27914 SetValue value=1 time=0.000000 constant=0

I expect the sound would be better if the AudioBufferSourceNodes were always scheduled far enough in the future that they would render on time.
However, AudioWorkletNode would be a better way to render audio.

Severity: -- → S3
Depends on: 956574
Component: Audio/Video → Web Audio

(In reply to Karl Tomlinson (:karlt) from comment #3)

Thanks for the report. I can see that AudioBufferSourceNode is used for sound. At currentTime=251.805333, an AudioBufferSourceNode is scheduled on the JS thread to start at 251.805333. By the time the audio rendering thread receives the message to start, it has likely already rendered for that time, and so the AudioBufferSourceNode starts late and does not align as intended with adjacent buffers.

D/WebAudioAPI 251.805333: GainNode 2 Connect() to GainNode 1
D/WebAudioAPI 251.805333: detune for 27912 SetValue value=0 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27912 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27912 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27912 Connect() to GainNode 2
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27912 Start(251.805333, 0, 2.22507e-308)
D/WebAudioAPI 251.805333: detune for 27913 SetValue value=0 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27913 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27913 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27913 Connect() to GainNode 2
D/WebAudioAPI 251.805333: AudioBufferSourceNode 27913 Start(251.811138, 0, 2.22507e-308)
D/WebAudioAPI 251.805333: detune for 27914 SetValue value=0 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27914 SetValue value=1 time=0.000000 constant=0
D/WebAudioAPI 251.805333: playbackRate for 27914 SetValue value=1 time=0.000000 constant=0

I expect the sound would be better if the AudioBufferSourceNodes were always scheduled far enough in the future that they would render on time.
However, AudioWorkletNode would be a better way to render audio.

I don't know much about it but it's clear enough to be understood by a beginner like me.
nevertheless I find this subject very interesting.

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