Open Bug 1435625 Opened 4 years ago Updated 2 years ago

exponentialRampToValueAtTime on gainNode doesn't work as expected

Categories

(Core :: Web Audio, defect, P2)

60 Branch
Unspecified
All
defect

Tracking

()

Tracking Status
firefox58 --- affected
firefox59 --- affected
firefox60 --- affected

People

(Reporter: jonbro, Unassigned)

Details

Attachments

(2 files)

Attached file audioRampIssue1.html
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180204102054

Steps to reproduce:

On Firefox Nightly 60.0a1 (2018-02-04) (64-bit)
I set up a simple audio volume ramp using gainNode.gain.exponentialRampToVolumeAtTime(0.01, context.currentTime+1).

It seems that this ramp issue effects all aRate parameters, I first noticed it on this page: https://tonejs.github.io/examples/#rampTo


Actual results:

The gain jumps to the requested gain, rather than ramping to the requested gain.


Expected results:

The gain should ramp to the value requested.

I also tested this with the code specified in the documentation (https://developer.mozilla.org/en-US/docs/Web/API/AudioParam/exponentialRampToValueAtTime), and it doesn't work there (slightly modified so the code runs without SyntaxError: An invalid or illegal string was specified error)
A slightly modified version of this documentation page that also illustrates this bug. The example on the page does not run as posted, which is why I modified it.

https://developer.mozilla.org/en-US/docs/Web/API/AudioParam/exponentialRampToValueAtTime
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Firefox: 60.0a1, Build ID 20180207100355

I have managed reproduce the issue on Windows 10 x64, Ubuntu 14.04 x64 and Mac 10.13 with Firefox release (58.0.1) and the latest Nightly (60.0a1) build. 
Also when I've tested this issue on other browsers I've found out that this behavior is not reproducible on Google Chrome and Opera but it is reproducible on Microsoft Edge.

This issue is not a regression because I've went back as far as Firefox 29 and the issue is still reproducible (on versions older than Firefox 29 it does not work at all).

Considering this I will assign a component to this issue in order to get the engineering team involved.
Status: UNCONFIRMED → NEW
Component: Untriaged → Web Audio
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Rank: 15
Priority: -- → P2

Was this ever resolved? I'm still able to reproduce it in FF 66.

AudioParam spec is now stable, so we can fix this now (it was changing quite a lot, we're down to one issue to fix on the spec). This is related to the value setter I think, which was stabilized a few weeks back.

Great to hear. Thanks!

What's the status of this bug fix? My experience is the same as that initially reported while using Firebox version 68.0.2.

Flags: needinfo?(drno)

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Keywords: regression

I redirect the question and NI to Paul.

Flags: needinfo?(drno) → needinfo?(padenot)

Nothing new to report. We want to fix this, but we haven't took the time to do so yet.

Flags: needinfo?(padenot)
You need to log in before you can comment on or make changes to this bug.