W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17697] Limit total volume

From: <bugzilla@jessica.w3.org>
Date: Fri, 17 Aug 2012 17:24:33 +0000
Message-Id: <E1T2QHh-00044k-Qi@jessica.w3.org>
To: public-audio@w3.org

--- Comment #9 from Chris Rogers <crogers@google.com> 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.

Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 17 August 2012 17:24:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 17 August 2012 17:24:37 GMT