Implement the new behavior for AudioParam.value
Categories
(Core :: Web Audio, defect, P3)
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.
Updated•9 years ago
|
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);
Comment 2•7 years ago
|
||
Mass change P2->P3 to align with new Mozilla triage process.
Comment 5•3 years ago
|
||
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 :)
Comment hidden (advocacy) |
Updated•2 years ago
|
Description
•