| 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. |