1803822 - webaudio envelope is crackling

Status: UNCONFIRMED

(Core :: Web Audio, defect)

Description

[Mikoláš Štrajt]

Attachment: envelope-crackle-firefox-107.wav

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

Open https://severak.github.io/cyber-music-studio/fm.html and play up and down with mouse.

Actual results:

In Firefox 107 it will crackle like a hell and in Chrome (and other Webkit based browsers) it sounds just OK

This was not an issue before. I used to develop this software on Firefox and while I was doing this (in 2021) it was sounding good.

Now it's crackling due some weird envelope behaviour. I can change code of my program. I can even do some special behaviour for Firefox here but I don't know how to do it.

Comment 1

[Mikoláš Štrajt]

First recording is from Firefox. Second one is from Chrome, it's just stitched together in Audacity.

I am also adding cross referencing to my own bug report in my software - https://github.com/severak/cyber-music-studio/issues/13

Comment 2

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

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

Comment 3

[Jim Mathies [:jimm]]

Could you help us out by capturing and uploading a Firefox performance profile when this happens? Visit https://profiler.firefox.com/ for more information. When capturing, please select the Media profile in the drop down.

Comment 4

[Jim Mathies [:jimm]]

I think I can reproduce this, a slight pop as the cursor drags over the piano keys. Doesn't reproduce in chrome.

Comment 5

[Jim Mathies [:jimm]]

https://share.firefox.dev/3hjKv7S - I don't see much here. I can generate logs if needed. This might be cubeb related, if so Paul please redirect to Mathew.

Comment 6

[Karl Tomlinson (:karlt)]

Envelope changes are often prone to problems due to currentTime being out of date by the time the changes are effected. The result is that the start of the ramp is missed and there is a discontinuity in the envelope. Chrome is less susceptible to this due to having a more dynamic implementation of currentTime, but that has the disadvantage of changes that are intended to be effected together potentially happening at different times.

You may be interested in the AudioBufferSourceNode approach that I used to workaround this for bug 943138, but that isn't guaranteed to work consistently in Chrome because it doesn't necessarily apply a sequence of changes made during a single event loop task as a single transaction - audio may be rendered between the changes.

Comment 7

[Mikoláš Štrajt]

(In reply to Jim Mathies [:jimm] from comment #3)

Could you help us out by capturing and uploading a Firefox performance profile when this happens? Visit https://profiler.firefox.com/ for more information. When capturing, please select the Media profile in the drop down.

I recorded profile from my development machine here - https://share.firefox.dev/3j5uRgE

Comment 8

[Mikoláš Štrajt]

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

You may be interested in the AudioBufferSourceNode approach that I used to workaround this for bug 943138, but that isn't guaranteed to work consistently in Chrome because it doesn't necessarily apply a sequence of changes made during a single event loop task as a single transaction - audio may be rendered between the changes.

I am interested in this. However I am not able to wrap my head around it yet. I will look into it later (when I am more fresh than today). Please let me know if there is more verbose write up of this trick you are using.

Generally - discontinuity in envelope is more problem than messed up timing, because envelope discontinuity means pops and clicks in sound. Bad timing is not such a problem because when playing live I can always pretend that's user problem. :-D