This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
From “Review of Web Audio Processing: Use Cases and Requirements” http://lists.w3.org/Archives/Public/public-audio/2012AprJun/0852.html Are there issues with needing to provide a way for limits e.g., on total volume when multiple tracks layered, or is this handled by audio equipment? Wouldn't want combinatorial effects to create excessively loud spots. Consider users who have audio volume higher than usual because of hearing impairment, but still we can't allow eardrum-damaging levels to come out.
My understanding is that this is a non-issue, but it could benefit from input by our audio specialists. 1) Should we document this in the requirements or is it absolutely evident that the loudness of the sound processed through the web audio API would be limited by the constraints of the system-wide volume control? 2) If 1, then do how does the current web audio API fare with regards to these requirements?
It seems to me that this, too, belongs at the operating system level, since multiple applications may be producing output.
I can't quite find a hook for this requirement (indeed, as mentioned in Comment #2, more of an OS-level requirement) and audio processing requirements.
For what it's worth, we have already received bug reports that certain demos (like Jussi's http://niiden.com/orbisyn/ demo) cause deafeningly loud noise in the current shipping versions of Chrome and Safari for the Mac. The output is so overwhelmingly loud that the system volume controls have no apparent effect. So, while conceptually this is a task for the OS to regulate, UAs will have a great deal of pressure to add some kind of volume check to the WebAudio API. The question is, will this limit be part of a spec or not.
(In reply to comment #4) > For what it's worth, we have already received bug reports that certain demos > (like Jussi's http://niiden.com/orbisyn/ demo) cause deafeningly loud noise in > the current shipping versions of Chrome and Safari for the Mac. The output is > so overwhelmingly loud that the system volume controls have no apparent effect. > > So, while conceptually this is a task for the OS to regulate, UAs will have a > great deal of pressure to add some kind of volume check to the WebAudio API. > The question is, will this limit be part of a spec or not. This is true. The issue with my demo is however a bit parallel with Bug 18539 [1]. The demo gets underruns which, due to the nature of JS nodes, cause the high Q low pass filters to have significant feedback. My proposition for mitigating issues like this for Jer was to monitor the dB levels at the AudioContext's listener and mute for a certain amount of time if a certain threshold is topped. This is afaict common behaviour in popular DAWs as well. This threshold would preferably be above +0.0dB as it may become a nuisance if any distorted value mutes the output, although preferably developers should avoid levels like that by for example using a compressor. But this is not always in the developers hands, like in the DAW use case. It might also be useful to notify the developer of the mute, for example with an event on the AudioContext. [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=18539
(In reply to comment #4) > For what it's worth, we have already received bug reports that certain demos > (like Jussi's http://niiden.com/orbisyn/ demo) cause deafeningly loud noise in > the current shipping versions of Chrome and Safari for the Mac. The output is > so overwhelmingly loud that the system volume controls have no apparent effect. This part "system volume controls have no apparent effect" seems like an important clue to try to fix this problem. I'm guessing that what we need to do in the AudioDestination is to clip the final output to 0dBFS (a range from -1 -> +1). This is supposed to be the clipping point anyway, so I'm interested if this helps fix the problem. I'm guessing that the rendered audio signal is so "hot" that even with drastic gain reductions using the system volume control, it won't help... > > So, while conceptually this is a task for the OS to regulate, UAs will have a > great deal of pressure to add some kind of volume check to the WebAudio API. > The question is, will this limit be part of a spec or not.
Thanks Jer, Jussi. You gave me enough material to add something to the requirements document. Let's continue the discussion about whether/how to add it to the spec in Bug 18539.
(In reply to comment #6) > (In reply to comment #4) > > For what it's worth, we have already received bug reports that certain demos > > (like Jussi's http://niiden.com/orbisyn/ demo) cause deafeningly loud noise in > > the current shipping versions of Chrome and Safari for the Mac. The output is > > so overwhelmingly loud that the system volume controls have no apparent effect. > > This part "system volume controls have no apparent effect" seems like an > important clue to try to fix this problem. I'm guessing that what we need to > do in the AudioDestination is to clip the final output to 0dBFS (a range from > -1 -> +1). This is supposed to be the clipping point anyway, so I'm interested > if this helps fix the problem. I'm guessing that the rendered audio signal is > so "hot" that even with drastic gain reductions using the system volume > control, it won't help... Does this mean that the current WebKit implementation just passes the signal on to the OS without clamping to [-1, 1]?
(In reply to comment #8) > (In reply to comment #6) > > (In reply to comment #4) > > > For what it's worth, we have already received bug reports that certain demos > > > (like Jussi's http://niiden.com/orbisyn/ demo) cause deafeningly loud noise in > > > the current shipping versions of Chrome and Safari for the Mac. The output is > > > so overwhelmingly loud that the system volume controls have no apparent effect. > > > > This part "system volume controls have no apparent effect" seems like an > > important clue to try to fix this problem. I'm guessing that what we need to > > do in the AudioDestination is to clip the final output to 0dBFS (a range from > > -1 -> +1). This is supposed to be the clipping point anyway, so I'm interested > > if this helps fix the problem. I'm guessing that the rendered audio signal is > > so "hot" that even with drastic gain reductions using the system volume > > control, it won't help... > > Does this mean that the current WebKit implementation just passes the signal on > to the OS without clamping to [-1, 1]? Good question. Come to think of it, It depends which port of WebKit. I think that Apple's "mac" port does *not* clamp. But, for Chrome the clamping happens somewhere deeper down inside the chromium-specific audio back-end. It would be good if I could have a reproducible case.
(In reply to comment #7) > Thanks Jer, Jussi. You gave me enough material to add something to the > requirements document. Let's continue the discussion about whether/how to add > it to the spec in Bug 18539. I've added this to a Use Case / Requirement, see http://dvcs.w3.org/hg/audio/rev/2a6431dcb680
Seeing no objection, closing.