Chromium Code Reviews| OLD | NEW |
|---|---|
| (Empty) | |
| 1 // Copyright 2016 The Chromium Authors. All rights reserved. | |
| 2 // Use of this source code is governed by a BSD-style license that can be | |
| 3 // found in the LICENSE file. | |
| 4 | |
| 5 #include "media/base/audio_latency.h" | |
| 6 | |
| 7 #include <stdint.h> | |
| 8 | |
| 9 #include "base/logging.h" | |
| 10 #include "build/build_config.h" | |
| 11 | |
| 12 namespace media { | |
| 13 | |
| 14 namespace { | |
| 15 #if !defined(OS_WIN) | |
| 16 // Taken from "Bit Twiddling Hacks" | |
| 17 // http://graphics.stanford.edu/~seander/bithacks.html#RoundUpPowerOf2 | |
| 18 uint32_t RoundUpToPowerOfTwo(uint32_t v) { | |
| 19 v--; | |
| 20 v |= v >> 1; | |
| 21 v |= v >> 2; | |
| 22 v |= v >> 4; | |
| 23 v |= v >> 8; | |
| 24 v |= v >> 16; | |
| 25 v++; | |
| 26 return v; | |
| 27 } | |
| 28 #endif | |
| 29 } // namespace | |
| 30 | |
| 31 // static | |
| 32 int AudioLatency::GetHighLatencyBufferSize(int sample_rate, | |
| 33 int preferred_buffer_size) { | |
| 34 // Empirically, we consider 20ms of samples to be high latency. | |
| 35 const double twenty_ms_size = 2.0 * sample_rate / 100; | |
| 36 | |
| 37 #if defined(OS_WIN) | |
| 38 preferred_buffer_size = std::max(preferred_buffer_size, 1); | |
| 39 | |
| 40 // Windows doesn't use power of two buffer sizes, so we should always round up | |
| 41 // to the nearest multiple of the output buffer size. | |
| 42 const int high_latency_buffer_size = | |
| 43 std::ceil(twenty_ms_size / preferred_buffer_size) * preferred_buffer_size; | |
| 44 #else | |
| 45 // On other platforms use the nearest higher power of two buffer size. For a | |
| 46 // given sample rate, this works out to: | |
| 47 // | |
| 48 // <= 3200 : 64 | |
| 49 // <= 6400 : 128 | |
| 50 // <= 12800 : 256 | |
| 51 // <= 25600 : 512 | |
| 52 // <= 51200 : 1024 | |
| 53 // <= 102400 : 2048 | |
| 54 // <= 204800 : 4096 | |
| 55 // | |
| 56 // On Linux, the minimum hardware buffer size is 512, so the lower calculated | |
| 57 // values are unused. OSX may have a value as low as 128. | |
| 58 const int high_latency_buffer_size = RoundUpToPowerOfTwo(twenty_ms_size); | |
| 59 #endif // defined(OS_WIN) | |
| 60 | |
| 61 #if defined(OS_CHROMEOS) | |
| 62 return high_latency_buffer_size; // No preference. | |
| 63 #else | |
| 64 return std::max(preferred_buffer_size, high_latency_buffer_size); | |
| 65 #endif // defined(OS_CHROMEOS) | |
| 66 } | |
| 67 | |
| 68 // static | |
| 69 int AudioLatency::GetRtcBufferSize(int sample_rate, int hardware_buffer_size) { | |
| 70 int frames_per_10ms = sample_rate / 100; | |
| 71 // Default values to be used if no |hardware_buffer_size| is specified. | |
| 72 int frames_per_buffer = frames_per_10ms; | |
| 73 | |
| 74 #if defined(OS_WIN) | |
| 75 // On Windows, we strive to open up using this native hardware buffer size | |
| 76 // to achieve best possible performance and to ensure that no FIFO is needed | |
| 77 // on the browser side to match the client request. | |
| 78 if (hardware_buffer_size) | |
| 79 frames_per_buffer = hardware_buffer_size; | |
| 80 #elif defined(OS_LINUX) || defined(OS_MACOSX) | |
| 81 // On Linux and MacOS, the low level IO implementations on the browser side | |
| 82 // supports all buffer size the clients want. We use the native peer | |
| 83 // connection buffer size (10ms) to achieve best possible performance. | |
| 84 #elif defined(OS_ANDROID) | |
| 85 // TODO(henrika): Keep tuning this scheme and espcicially for low-latency | |
|
henrika (OOO until Aug 14)
2016/06/28 13:26:25
nit, especially, and perhaps a good time to remove
o1ka
2016/06/29 10:11:26
Modified TODO. I'm not gonna touch those old setti
| |
| 86 // cases. Might not be possible to come up with the perfect solution using | |
| 87 // the render side only. | |
| 88 if (hardware_buffer_size) { | |
| 89 frames_per_buffer = hardware_buffer_size; | |
| 90 if (frames_per_buffer < 2 * frames_per_10ms) { | |
| 91 // Examples of low-latency frame sizes and the resulting |buffer_size|: | |
| 92 // Nexus 7 : 240 audio frames => 2*480 = 960 | |
| 93 // Nexus 10 : 256 => 2*441 = 882 | |
| 94 // Galaxy Nexus: 144 => 2*441 = 882 | |
| 95 frames_per_buffer = 2 * frames_per_10ms; | |
| 96 DVLOG(1) << "Low-latency output detected on Android"; | |
| 97 } | |
| 98 } | |
| 99 #endif | |
| 100 | |
| 101 DVLOG(1) << "Using sink output buffer size: " << frames_per_buffer; | |
| 102 return frames_per_buffer; | |
| 103 } | |
| 104 | |
| 105 // static | |
| 106 int AudioLatency::GetInteractiveBufferSize(int hardware_buffer_size) { | |
| 107 #if defined(OS_ANDROID) | |
| 108 // The optimum low-latency hardware buffer size is usually too small on | |
| 109 // Android for WebAudio to render without glitching. So, if it is small, use | |
| 110 // a larger size. | |
| 111 // | |
| 112 // Since WebAudio renders in 128-frame blocks, the small buffer sizes (144 for | |
| 113 // a Galaxy Nexus), cause significant processing jitter. Sometimes multiple | |
| 114 // blocks will processed, but other times will not be since the WebAudio can't | |
| 115 // satisfy the request. By using a larger render buffer size, we smooth out | |
| 116 // the jitter. | |
| 117 const int kSmallBufferSize = 1024; | |
| 118 const int kDefaultCallbackBufferSize = 2048; | |
| 119 if (hardware_buffer_size <= kSmallBufferSize) | |
| 120 return kDefaultCallbackBufferSize; | |
| 121 #endif | |
| 122 | |
| 123 return hardware_buffer_size; | |
| 124 } | |
| 125 | |
| 126 } // namespace media | |
| OLD | NEW |