ScriptProcessorNode default buffer size inconsistent with context buffer size. |
|||
Issue descriptionThe default size for the buffer size of a ScriptProcessorNode is computed as four times the HW buffer size. But the AudioContext size on Android has a lower limit of 1024 or so. For a device like an N9, the HW size is 128, so the script processor size is 512. But this makes it not work well when the AudioContext size is 1024. The default size needs to be consistent.
,
Dec 16 2016
Here's why this is bad. Using the N9 as an example, the callback buffer size is actually 2048. This means that the destination will pull on the graph 16 times (2048/128), back-to-back. Since the ScriptProcessor size is 512, this means that after 4 calls, the ScriptProcessor will fire the event. However, the destination will continue to pull the graph many more times as fast as possible. This means in a very short time, ScriptProcessor will have 512 frames ready to go and fire the event AGAIN, leaving very little time for the first event to process the data. Hence, data is messed up. So, at the very least the ScriptProcessor buffer size needs to be at least the size of the callback size. Probably twice as large for double buffering in the ScriptProcessor.
,
Dec 20 2016
,
Dec 20 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/94c37e9181e0619415e8f4d2be3f631b44fe2e64 commit 94c37e9181e0619415e8f4d2be3f631b44fe2e64 Author: rtoy <rtoy@chromium.org> Date: Tue Dec 20 23:37:10 2016 ScriptProcessor buffer size should be consistent with callback size When selecting a buffer size for a ScriptProcessorNode (when constructed using a requested size of 0), the selected size needs to be consistent with the actuall callback buffer size of the AudioContext. Previously, the value was based on the audio hardware size, which could be very small (128 or 256) on some Android devices, but the actual callback size is much larger (1024 or 2048). This causes glitching because we will fire the process event back-to-back because of the multiple calls ot process() to satisfy the callback buffer size. Thus, add appropriate interfaces so that an AudioContext (and BaseAudioContext) can get the callback buffer size from the AudioDestination. Also, for an offline context, we can just always return a value of 256 (the smallest) for the buffer size. There is no constraint here because the offline context waits for the ScriptProcessor to finish before continuing. BUG= 673854 TEST= Review-Url: https://codereview.chromium.org/2582443004 Cr-Commit-Position: refs/heads/master@{#439927} [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/AudioDestinationNode.h [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/AudioNode.h [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/BaseAudioContext.h [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/DefaultAudioDestinationNode.cpp [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/DefaultAudioDestinationNode.h [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/OfflineAudioDestinationNode.cpp [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/OfflineAudioDestinationNode.h [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/modules/webaudio/ScriptProcessorNode.cpp [modify] https://crrev.com/94c37e9181e0619415e8f4d2be3f631b44fe2e64/third_party/WebKit/Source/platform/audio/AudioDestination.h
,
Dec 22 2016
|
|||
►
Sign in to add a comment |
|||
Comment 1 by rtoy@chromium.org
, Dec 16 2016Status: Started (was: Available)