Open Bug 1171438 Opened 9 years ago Updated 2 years ago

Implement the new behavior for AudioParam.value

Categories

(Core :: Web Audio, defect, P3)

Product:
Core
Component:
Web Audio
Type:
defect

Tracking

()

People

(Reporter: padenot, Unassigned)

References

Details

(Whiteboard: [spec]) 

https://github.com/WebAudio/web-audio-api/issues/128

In short, doing `AudioParam.value = val` is now strictly equivalent to calling `AudioParam.setValueAtTime(context.currentTime, val);`: it adds an event to the timeline, for example.

The value returned when getting `AudioParam.value` is now the last value set using `AudioParam.value`, to avoid changing the behavior.
Rank: 25
Priority: -- → P2
Whiteboard: [spec]
The comment above says, "In short, doing `AudioParam.value = val` is now strictly equivalent to calling `AudioParam.setValueAtTime(context.currentTime, val".  I am writing some WebAudio code and finding this not to be true.  Please try out the following JSFiddle (link and code pasted below) with the console open and speakers or headphones attached.  I'm seeing two problems in Firefox 54.0:

1. The oscillator does not fade, it stops abruptly.  In Chrome it fades.  If the line "gainNode.gain.value" is replaced with "gainNode.gain.setValueAtTime( 1, audioContext.currentTime)" it fades, as expected.

2. When gainNode.gain.value is read, as is done in the interval function, it never reports any value other than 1, even if the sound is fading or muted.  The value DOES change in Chrome, Safari, and Edge when using "gainNode.gain.setValueAtTime( 1, audioContext.currentTime)", so Firefox is the odd man out on this behavior.

Link to JSFiddle example: https://jsfiddle.net/o7xdsgyk/16/

Example code:

var audioContext = new(window.AudioContext || window.webkitAudioContext)();
var gainNode = audioContext.createGain();
gainNode.connect(audioContext.destination);
var oscillator = audioContext.createOscillator();
oscillator.frequency.value = 440;
oscillator.connect(gainNode);
oscillator.start();
gainNode.gain.value = 1;
//gainNode.gain.setValueAtTime( 1, audioContext.currentTime);
var rampTime = 1; // in seconds
gainNode.gain.linearRampToValueAtTime(0, audioContext.currentTime + rampTime);
var logCountdown = 10;
var intervalTimer = setInterval(function() {
  console.log('countdown = ' + logCountdown);
  console.log('gain = ' + gainNode.gain.value);
  logCountdown--;
  if (logCountdown < 0) {
    clearInterval(intervalTimer);
  }
}, (rampTime * 1000) / logCountdown);
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3

Does anyone know if this will be fixed?

I cannot generate volume fading sounds with Firefox using the exponentialRampToValueAtTime method. That was a bad surprise. It worked very fine in Brave/Chromium. Looks like Mozilla has no interest in implementing the Audio API, so why is it even documented? So disappointing.

So will this be fixed or will you just close this issue and give up? I mean, after 7 years with no attention, what is the realistic chance of this being fixed?

The only workaround is pre-generating wave files in an audio editor and play them in the browser. It feels like pre-generating images in an image editor for simple effects like shadows or gradients. Like back in the 90s when we didn't have CSS.

(In reply to Yves Goergen from comment #5)

I cannot generate volume fading sounds with Firefox using the exponentialRampToValueAtTime method. That was a bad surprise. It worked very fine in Brave/Chromium. Looks like Mozilla has no interest in implementing the Audio API, so why is it even documented? So disappointing.

So will this be fixed or will you just close this issue and give up? I mean, after 7 years with no attention, what is the realistic chance of this being fixed?

The only workaround is pre-generating wave files in an audio editor and play them in the browser. It feels like pre-generating images in an image editor for simple effects like shadows or gradients. Like back in the 90s when we didn't have CSS.

About 2-3 years ago I removed FF from the list of supported browsers in the API doc so the documentation should be OK: https://developer.mozilla.org/en-US/docs/Web/API/AudioParam/exponentialRampToValueAtTime#browser_compatibility

The github admins for the API doc forced me to write "partial support" on the feature though, because "the function exists", even though by now the feature has been broken for more years than it could have been working. Judging by the age of this bug and taking into consideration that Mozilla has been cutting staff over the recent years, I sincerely doubt that this bug will ever be fixed. FF is falling apart and in turn bleeding users, because no users are interested in "Differentiated user experience" or fugly desktop tabs, when more and more websites are broken or underperforming in FF. I am inches away from moving to ungoogled-chromium or something similar, even though I have been a user since the beta days (even donated and bought a tshirt back when I was a poor high school student in 2004), but life is too short to waste time on a bug ridden semi-abandoned browser. I work for a company that makes B2B software, and they ditched official FF support about two years ago because (a) no costumers used FF anymore (b) every other month a new bug in FF would appear and break something and rarely be fixed. It was great while it was great.

Ahh.. glad to get that off my chest :)

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.