Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
<variant name="PannerNode"/>
[PannerNode](https://crsrc.org/c/third_party/blink/renderer/modules/webaudio/panner_handler.cc) has a custom ProcessIfNecessary, we probably need to add code there too.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[PannerNode](https://crsrc.org/c/third_party/blink/renderer/modules/webaudio/panner_handler.cc) has a custom ProcessIfNecessary, we probably need to add code there too.
Thanks for pointing this out, I added the same logic to `PannerHandler::ProcessIfNecessary`.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
uint32_t total_process_frames_ = 0;
I'm not sure if this is important, but I think that at 48000 samples per second this would roll over after about 1 day (2^32 / (48000 * 60 * 60 * 24)). Probably longer than most AudioContexts survive, but not impossible to see. We may want to do uint64_t instead.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
uint32_t total_process_frames_ = 0;
I'm not sure if this is important, but I think that at 48000 samples per second this would roll over after about 1 day (2^32 / (48000 * 60 * 60 * 24)). Probably longer than most AudioContexts survive, but not impossible to see. We may want to do uint64_t instead.
Thanks for bringing attention to this. Currently from what we are planning, we will reset `total_process_frames_` to `0` in `AddProcessDuration` after every `kReportingInterval` calls. (currently set as 1000).
Local test shows that `total_process_frames_` usually reach `128000` (or less). (Because the render quantum is now always be 128). I assume this may change once the configurable render quantum feature is landed. And possibly the `total_process_frames_` can reach `512000` (if support up to 512 render quantum) after 1000 `Process` calls. In that case `uint32_t` should still be sufficient to hold the max `total_process_frames_`.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
uint32_t total_process_frames_ = 0;
Alvin JiI'm not sure if this is important, but I think that at 48000 samples per second this would roll over after about 1 day (2^32 / (48000 * 60 * 60 * 24)). Probably longer than most AudioContexts survive, but not impossible to see. We may want to do uint64_t instead.
Thanks for bringing attention to this. Currently from what we are planning, we will reset `total_process_frames_` to `0` in `AddProcessDuration` after every `kReportingInterval` calls. (currently set as 1000).
Local test shows that `total_process_frames_` usually reach `128000` (or less). (Because the render quantum is now always be 128). I assume this may change once the configurable render quantum feature is landed. And possibly the `total_process_frames_` can reach `512000` (if support up to 512 render quantum) after 1000 `Process` calls. In that case `uint32_t` should still be sufficient to hold the max `total_process_frames_`.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
WebAudio: Add UMA for AudioHandler Process Time Ratio
Adds a UMA metric, `WebAudio.AudioNode.ProcessTimeRatio.{NodeTag}`, to
monitor the performance of AudioHandler subclasses.
This metric reports the percentage of the allocated time budget used by an
AudioHandler's Process() method, averaged over 1000 calls. The {Type}
suffix denotes the specific AudioNode type (e.g., GainNode).
This data will help identify performance characteristics and potential
bottlenecks in different audio nodes.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |