WebAudio - latency hints produce inconsistent baseLatency values on Android 8
Reported by
to...@helloeko.com,
Nov 28 2017
|
|||||
Issue descriptionSteps to reproduce the problem: On a device running Android 8, navigate to: https://s3.amazonaws.com/storage2.interlude.fm/dev_temp/tomer/baselatency.html What is the expected behavior? baseLatency values should correspond to the requested latencyHint. What went wrong? 1. All numeric latenctyHint values produce the lowest possible baseLatency, which result in bad playback (audible crackling). 2. "interactive" value is higher than "playback" 3. "balanced" value is lower than both "interactive" and "playback" Did this work before? N/A Chrome version: 62.0.3202.84 Channel: stable OS Version: 8.0.0 Flash Version:
,
Nov 29 2017
,
Nov 29 2017
Tested the issue in Android and could reproduce the issue. Observed the baseLatency values are not corresponded to the requested latencyHint. Steps Followed: 1. Launched Chrome Browser. 2. Navigated to https://s3.amazonaws.com/storage2.interlude.fm/dev_temp/tomer/baselatency.html 3. Observed the baseLatency values are not corresponded to the requested latencyHint Chrome versions tested: 62.0.3202.84, 64.0.3279.0 OS Android 8.0.0 Android Devices 8.0.0 Pixel XL Build/OPR1.170623.027 This seems to be a Non-Regression issue as same behavior is seen since M58. Untriaged for further input's on this issue. Note: 1. Somehow issue is seen in Desktop as well using #64.0.3279.0. 2. This issue is not observed using #62.0.3202.84 on Android SM-J710F Build/NRD90M. Please navigate to below link for log's and video-- go/chrome-androidlogs/789301 Thanks!!
,
Nov 29 2017
tomer@ Can you run Chrome canary with your test and use adb logcat to look at some logs. Search for audioHardwareBufferSize. I'm curious to see what value a Pixel returns for that. This issue isn't particular to Android 8. It affects all Android versions. On my Nexus 9 with Android 6.0, I get fairly similar results as shown in report, except that for numeric values, the min latency is 0.0026666. And from the report, it's pretty clear we're not handling numeric hint values correctly. For a hint of 0.02, I would expect a latency of 0.02 since that's the balanced value. Similarly, 0.1 should produce some value near 0.1. A large value of 0.25 should have been 0.0426 or higher.
,
Nov 29 2017
The results for a Pixel (as reported by tomer@) and a Pixel XL (as reported in c#3) seem really inconsistent. The lowest latency value for a Pixel XL is 0.04 s?!?! The Pixel goes to 0.004. I would have expected a Pixel XL to perform similarly to a Pixel. (But maybe the chipsets are different?)
,
Nov 29 2017
The reported audioHardwareBufferSize on my Pixel is 192: 11-29 11:26:20.262 23251 23267 I chromium: [INFO:audio_latency.cc(146)] audioHardwareBufferSize = 192 11-29 11:26:20.262 23251 23267 I chromium: [INFO:audio_latency.cc(151)] callbackBufferSize = 2048
,
Nov 29 2017
Thanks for the quick reply! 192 is interesting. Haven't seen that before. Anyway, we have some work to do to straighten this all out. I think the interactive value should be .004 (or maybe .008). The other values should be ok. BTW, it's pretty useful to include the context sample rate when displaying the latency values. It makes it easier to determine how many frames are used.
,
Nov 29 2017
Note that on my linux machine (with a sample rate of 44100), the interactive latency (0.0116 s = 512 frames) is higher than balanced (.01 s): latencyHint: undefined baseLatency: 0.011609977324263039 sampleRate: 44100 latencyHint: interactive baseLatency: 0.011609977324263039 sampleRate: 44100 latencyHint: balanced baseLatency: 0.01 sampleRate: 44100 latencyHint: playback baseLatency: 0.023219954648526078 sampleRate: 44100 latencyHint: 0.01 baseLatency: 0.011609977324263039 sampleRate: 44100 latencyHint: 0.02 baseLatency: 0.011609977324263039 sampleRate: 44100 latencyHint: 0.05 baseLatency: 0.011609977324263039 sampleRate: 44100 latencyHint: 0.1 baseLatency: 0.011609977324263039 sampleRate: 44100 latencyHint: 0.25 baseLatency: 0.011609977324263039 sampleRate: 44100
,
Nov 29 2017
OSX is much more consistent and the latency hint actually changes the latency: latencyHint: undefined baseLatency: 0.005333333333333333 sampleRate: 48000 latencyHint: interactive baseLatency: 0.005333333333333333 sampleRate: 48000 latencyHint: balanced baseLatency: 0.01 sampleRate: 48000 latencyHint: playback baseLatency: 0.021333333333333333 sampleRate: 48000 latencyHint: 0.01 baseLatency: 0.010666666666666666 sampleRate: 48000 latencyHint: 0.02 baseLatency: 0.021333333333333333 sampleRate: 48000 latencyHint: 0.05 baseLatency: 0.048 sampleRate: 48000 latencyHint: 0.1 baseLatency: 0.08533333333333333 sampleRate: 48000 latencyHint: 0.25 baseLatency: 0.08533333333333333 sampleRate: 48000
,
Nov 29 2017
For the record here is what win10 says: latencyHint: undefined baseLatency: 0.01 sampleRate: 48000 latencyHint: interactive baseLatency: 0.01 sampleRate: 48000 latencyHint: balanced baseLatency: 0.01 sampleRate: 48000 latencyHint: playback baseLatency: 0.02 sampleRate: 48000 latencyHint: 0.01 baseLatency: 0.01 sampleRate: 48000 latencyHint: 0.02 baseLatency: 0.01 sampleRate: 48000 latencyHint: 0.05 baseLatency: 0.01 sampleRate: 48000 latencyHint: 0.1 baseLatency: 0.01 sampleRate: 48000 latencyHint: 0.25 baseLatency: 0.01 sampleRate: 48000
,
Nov 29 2017
For the record, some additional information available at https://bugs.chromium.org/p/chromium/issues/detail?id=765367#c15
,
Nov 30 2017
rtoy@: Currently the "exact" latencyHint double value only works on OSX and ChromeOS, otherwise the hardware buffer size is used: https://cs.chromium.org/chromium/src/media/base/audio_latency.cc?q=audio_la&sq=package:chromium&l=163 This was based on discussion on the original CL as it wasn't clear which values to use when clamping the requested latency to known min and max values, since there isn't a guarantee that interactive size <= balanced <= playback on Android. It looks like GetInteractiveBufferSize does something different on Android to prevent very low buffer sizes so this probably either needs to be updated to allow them too, or else GetExactBufferSize should use this modified value rather than the hardware buffer size I think.
,
Dec 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a2bad0fd17c1f4977a76f6582882e22e2865020a commit a2bad0fd17c1f4977a76f6582882e22e2865020a Author: Andrew MacPherson <andrew.macpherson@soundtrap.com> Date: Thu Dec 21 09:30:45 2017 Use hardware buffer size on Android and honor latencyHint everywhere For Android devices, set the interactive latency to the hardware buffer size instead of clamping it to some random value. This makes (in many cases) the interactive latency less than balanced and playback as expected. UMA stats for Android show that hardware buffer sizes range from a low of 96 up to 87,360(!). Set a max web audio buffer size of 8192. (The stats say 8192 includes 99.1% of all devices, as of 2017/11/29.) Also honor the numeric latencyHint so that the actual buffer size does change as requested, within limits. The FIFO size for the AudioDestination also needs to be increased because the max buffer size is 8192 now for some platforms. Bug: 765367 , 789301 Change-Id: Ia953d7e6a5ca1ea7c4ef449744ff9f1b20b200c4 Reviewed-on: https://chromium-review.googlesource.com/805754 Reviewed-by: Chrome Cunningham <chcunningham@chromium.org> Reviewed-by: Olga Sharonova <olka@chromium.org> Reviewed-by: Raymond Toy <rtoy@chromium.org> Commit-Queue: Andrew MacPherson <andrew.macpherson@soundtrap.com> Cr-Commit-Position: refs/heads/master@{#525654} [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/content/renderer/media/audio_renderer_mixer_manager_unittest.cc [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/content/renderer/media/renderer_webaudiodevice_impl_unittest.cc [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/media/base/audio_latency.cc [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/media/base/audio_latency_unittest.cc [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/media/base/limits.h [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/media/base/mac/audio_latency_mac.cc [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/third_party/WebKit/LayoutTests/webaudio/AudioContext/audiocontextoptions.html [modify] https://crrev.com/a2bad0fd17c1f4977a76f6582882e22e2865020a/third_party/WebKit/Source/platform/audio/AudioDestination.cpp
,
Jan 5 2018
I believe this is fixed, mostly. On my Nexus 9 device with a sample rate of 48 kHz, interactive = 0.00266, balanced = 0.02, playback = 0.021333, so these are ordered consistently. And a hint of 0.01 gives 0.010666; .02 gives .021333; .05 gives .050666; 0.1 gives 0.101333; and 0.25 gives 0.170666. Android (somewhat arbitrarily) has an upper limit of 8192 frames or .170666 sec. Linux is also (almost) consistent (44.1 kHz on my machine). The only issue is interactive is 0.0116 vs balanced of 0.01. This is an artifact of the fact that WebAudio works at 512 frames by default (0.0116), which is slightly more than 10 ms. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by pnangunoori@chromium.org
, Nov 29 2017