17697 2012-07-05 14:24:21 +0000 Limit total volume 2012-09-10 10:19:33 +0000 1 1 1 Unclassified AudioWG Web Audio Processing: Use Cases and Requirements unspecified PC All CLOSED FIXED P2 normal TBD 1 olivier.thereaux dave.null cooper crogers jer.noble jussi.kalliokoski philipj public-audio oldest_to_newest 69650 0 olivier.thereaux 2012-07-05 14:24:21 +0000 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. 69836 1 olivier.thereaux 2012-07-11 15:49:28 +0000 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? 71366 2 philipj 2012-07-24 09:53:02 +0000 It seems to me that this, too, belongs at the operating system level, since multiple applications may be producing output. 72284 3 olivier.thereaux 2012-08-16 14:39:38 +0000 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. 72297 4 jer.noble 2012-08-16 17:03:09 +0000 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. 72298 5 jussi.kalliokoski 2012-08-16 17:18:56 +0000 (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 72315 6 crogers 2012-08-16 18:55:25 +0000 (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. 72344 7 olivier.thereaux 2012-08-17 08:30:26 +0000 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. 72346 8 philipj 2012-08-17 08:36:04 +0000 (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]? 72362 9 crogers 2012-08-17 17:24:33 +0000 (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. 73166 10 olivier.thereaux 2012-09-03 14:08:06 +0000 (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 73534 11 olivier.thereaux 2012-09-10 10:19:33 +0000 Seeing no objection, closing.