[Webkit-unassigned] [Bug 76685] New: Fix ASSERT Fail within AudioBus::processWithGainFrom

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Thu Jan 19 22:43:57 PST 2012


https://bugs.webkit.org/show_bug.cgi?id=76685

           Summary: Fix ASSERT Fail within AudioBus::processWithGainFrom
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Web Audio
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: rgbbones at gmail.com
                CC: crogers at google.com


There are ASSERT Fail within AudioBus::processWithGainFrom when DelayNode connected to GainNode. If you try to load http://chromium.googlecode.com/svn/trunk/samples/audio/wavetable-synth.html  and then refresh it by F5, you will probably encounter this issue.

I spent a lot of time to investigate this issue, finnal I found this is actually related to a AudioBasicProcessorNode and GainNode.

When an node is connect to another node,  the input will be marked to dirty and thus the node who owns the input will be checked with checkNumberOfChannelsForInput (And the renderingOutput will be updated)
And GainNode use checkNumberOfChannelsForInput to reallocate it's output bus according to the input bus's channel count. And thus when it do pull, it will assume it's output bus's topology should be the same as it's input bus, which in the single connection case, will probably be its upstream node's outputbus's toplogy.

Usually, this is true. While for the case of AudioBasicProcessorNode , its output bus is set to 0 channel by default and will not be set to the correct value until itself is connected by an upstream node, usually this is also ok if you check it.

But then, the AudioNodeInput's numberOfChannels() will force 0 to 1 as the mini channel. So when delay node is connected to GainNode while itself not yet been connected to, it breaks AudioGainNode's assumption. And then lead to this issue. Since it depends on master thread and audio thread's running sequence, it happens randomly.

The fix to this issue, is either change AudioNodeInput's numberOfChannels() to return 0 when it do have connection but the connection's channel is really a 0, or set AudioBasicProcessorNode's default output bus's channel to 1. The later one seems more easy to solve this issue at present and seems to me not bring extra problems. The first approaching might influence other codes and in order to make it work fine, some logic might need to be taken care of. but I really do think it will help to reduce this kind of unsync issues in the future?

While anyway, I will upload the patch using the second approaching.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list