Bug 17697 - Limit total volume
Summary: Limit total volume
Status: CLOSED FIXED
Alias: None
Product: AudioWG - OBSOLETE - Moved to Github
Classification: Unclassified
Component: Web Audio Processing: Use Cases and Requirements (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: TBD
Assignee: This bug has no owner yet - up for the taking
QA Contact: public-audio
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-05 14:24 UTC by Olivier Thereaux
Modified: 2012-09-10 10:19 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Olivier Thereaux 2012-07-05 14:24:21 UTC
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.
Comment 1 Olivier Thereaux 2012-07-11 15:49:28 UTC
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?
Comment 2 Philip Jägenstedt 2012-07-24 09:53:02 UTC
It seems to me that this, too, belongs at the operating system level, since multiple applications may be producing output.
Comment 3 Olivier Thereaux 2012-08-16 14:39:38 UTC
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.
Comment 4 Jer Noble 2012-08-16 17:03:09 UTC
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.
Comment 5 Jussi Kalliokoski 2012-08-16 17:18:56 UTC
(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
Comment 6 Chris Rogers 2012-08-16 18:55:25 UTC
(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.
Comment 7 Olivier Thereaux 2012-08-17 08:30:26 UTC
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.
Comment 8 Philip Jägenstedt 2012-08-17 08:36:04 UTC
(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]?
Comment 9 Chris Rogers 2012-08-17 17:24:33 UTC
(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.
Comment 10 Olivier Thereaux 2012-09-03 14:08:06 UTC
(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
Comment 11 Olivier Thereaux 2012-09-10 10:19:33 UTC
Seeing no objection, closing.