- From: <bugzilla@jessica.w3.org>
- Date: Fri, 17 Aug 2012 17:24:33 +0000
- To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17697 --- 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 UTC