Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2458703002:
Changed mixing to be done at the minimal possible frequency. (Closed)
DescriptionChanged mixing to be done at the minimal possible frequency.
This change changes mixing to be done at the lowest possible
APM-native rate that does not lead to quality loss. An Audio
Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a
lower sampling rate and avoiding resampling can in many cases lead to
big efficiency improvements, as reported by experiments.
This CL also fixes a design issue with the AudioMixer: audio at
non-native rates is no longer fed to the APM instance which is the
limiter.
NOTRY=True
BUG=webrtc:6346
Committed: https://crrev.com/95611837087e57f59ece87f02b9479e58c6904e8
Cr-Commit-Position: refs/heads/master@{#14980}
Patch Set 1 : Changed name NeededFrequncy -> PreferredSampleRate to match upstream change #
Total comments: 3
Patch Set 2 : Shorter lambda expression. #
Total comments: 10
Patch Set 3 : pointer to const -> const reference, added comment in api. #
Total comments: 5
Patch Set 4 : Added test with multiple participants. #
Total comments: 5
Patch Set 5 : Static constexpr array. #
Messages
Total messages: 37 (16 generated)
Patchset #1 (id:1) has been deleted
Patchset #1 (id:20001) has been deleted
Description was changed from ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. BUG=webrtc:6346 ========== to ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. BUG=webrtc:6346 ==========
Patchset #1 (id:40001) has been deleted
Patchset #1 (id:60001) has been deleted
aleloi@webrtc.org changed reviewers: + ivoc@webrtc.org, solenberg@webrtc.org
Hi! Can you take a look at this? The code change is something like ~40 lines plus tests. I change mixing to mix at a native rate and update the tests. The mixer queries all participants for preferred rates, picks the maximal and rounds up to a native rate. The rounding could be avoided, but then a few tests (those using FakeAudioCaptureModule and maybe a few more) would need to change. More details and motivation are communicated offline. https://codereview.webrtc.org/2458703002/diff/80001/webrtc/modules/audio_mixe... File webrtc/modules/audio_mixer/audio_mixer_impl_unittest.cc (right): https://codereview.webrtc.org/2458703002/diff/80001/webrtc/modules/audio_mixe... webrtc/modules/audio_mixer/audio_mixer_impl_unittest.cc:199: The rationale behind the change of ParticipantSampleRate is as follows. Test 3 behaviors: * That there should be no resampling when all sources run on the same native rate (tested by checking that the sample rate argument of GetAudioWithInfo is the source's requested rate) * That the mixed result is at the same rate if all sources have the same native rate (tested by inspecting the mixed rate). * That non-native source rates are converted by the mixer to larger native rates.
Description was changed from ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. BUG=webrtc:6346 ========== to ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. TBR=solenberg@webrtc.org BUG=webrtc:6346 ==========
henrik.lundin@webrtc.org changed reviewers: + henrik.lundin@webrtc.org
https://codereview.webrtc.org/2458703002/diff/100001/webrtc/api/audio/audio_m... File webrtc/api/audio/audio_mixer.h (right): https://codereview.webrtc.org/2458703002/diff/100001/webrtc/api/audio/audio_m... webrtc/api/audio/audio_mixer.h:67: // updated. Will the implementation have to provide the mixed audio in any of the native rates (8, 16, 32, 48), or can it be any rate? https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:143: AudioMixerImpl::SourceStatusList* const audio_source_list) { Why not const reference? https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index != native_rates.end()); RTC_DCHECK_NE https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = [&]() { So, I assume you create this lambda to get around the construct: int sample_rate; // Undefined and non-const. { rtc::CritScope lock(&crit_); sample_rate = CalculateMixingFrequency(&audio_source_list_); } What I wonder is if the lambda is evaluated twice?
https://codereview.webrtc.org/2458703002/diff/100001/webrtc/api/audio/audio_m... File webrtc/api/audio/audio_mixer.h (right): https://codereview.webrtc.org/2458703002/diff/100001/webrtc/api/audio/audio_m... webrtc/api/audio/audio_mixer.h:67: // updated. On 2016/10/31 14:14:56, hlundin-webrtc wrote: > Will the implementation have to provide the mixed audio in any of the native > rates (8, 16, 32, 48), or can it be any rate? It must be a native rate, and it must be part of the interface. I've added it in the next ps. https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:143: AudioMixerImpl::SourceStatusList* const audio_source_list) { On 2016/10/31 14:14:56, hlundin-webrtc wrote: > Why not const reference? Now changed. https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index != native_rates.end()); On 2016/10/31 14:14:56, hlundin-webrtc wrote: > RTC_DCHECK_NE _NE tries to print its arguments, but in this case, the arguments are iterators, so it wouldn't compile. https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = [&]() { On 2016/10/31 14:14:56, hlundin-webrtc wrote: > So, I assume you create this lambda to get around the construct: > int sample_rate; // Undefined and non-const. > { > rtc::CritScope lock(&crit_); > sample_rate = CalculateMixingFrequency(&audio_source_list_); > } > > What I wonder is if the lambda is evaluated twice? Exactly! No, the function is only called once. To call it twice, one would have to store it in a variable and call operator() twice on it.
lgtm https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index != native_rates.end()); On 2016/10/31 14:35:57, aleloi wrote: > On 2016/10/31 14:14:56, hlundin-webrtc wrote: > > RTC_DCHECK_NE > > _NE tries to print its arguments, but in this case, the arguments are iterators, > so it wouldn't compile. Of course. Sloppy reviewer... https://codereview.webrtc.org/2458703002/diff/100001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = [&]() { On 2016/10/31 14:35:57, aleloi wrote: > On 2016/10/31 14:14:56, hlundin-webrtc wrote: > > So, I assume you create this lambda to get around the construct: > > int sample_rate; // Undefined and non-const. > > { > > rtc::CritScope lock(&crit_); > > sample_rate = CalculateMixingFrequency(&audio_source_list_); > > } > > > > What I wonder is if the lambda is evaluated twice? > > Exactly! No, the function is only called once. To call it twice, one would have > to store it in a variable and call operator() twice on it. OK. So this is evaluated here, essentially?
Nice work. I think it would be good to add a test that has multiple participants with different sample rates, to check that the mixer selects the right one, as I don't think that is currently tested (correct me if I'm wrong). https://codereview.webrtc.org/2458703002/diff/80001/webrtc/modules/audio_mixe... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/80001/webrtc/modules/audio_mixe... webrtc/modules/audio_mixer/audio_mixer_impl.cc:152: RTC_DCHECK_LE(APM::kSampleRate8kHz, source_needed_frequency); To get better error messages, I think the thing that is being checked should be the first argument. So this should be RTC_DCHECK_GE(source_needed_frequency, APM::kSampleRate8kHz).
https://codereview.webrtc.org/2458703002/diff/80001/webrtc/modules/audio_mixe... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/80001/webrtc/modules/audio_mixe... webrtc/modules/audio_mixer/audio_mixer_impl.cc:152: RTC_DCHECK_LE(APM::kSampleRate8kHz, source_needed_frequency); On 2016/10/31 15:39:34, ivoc wrote: > To get better error messages, I think the thing that is being checked should be > the first argument. So this should be RTC_DCHECK_GE(source_needed_frequency, > APM::kSampleRate8kHz). I'm sure this applies to gtest macros, like EXPECT_LT, because it prints out something like "expected X, got Y which is not X (duh)". But for the (D)CHECKS, I'm not so sure. I tend not to care with the (D)CHECKS.
lgtm % comments https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:153: RTC_DCHECK_LE(source_needed_frequency, APM::kSampleRate48kHz); nit: _GE and switch order makes for a nicer printout whenever the DCHECK hits (but I agree this is more readable...) https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = [&]() { I think this is a dubious use of a lambda. The need to make sample_rate const isn't that big IMO, and writing simple code is ALWAYS preferable to using advanced, new golden hammers. For this type of construct, this is a lot more common (and to most developers more straightforward): int sample_rate = 0; { rtc::CritScope lock(&crit_); sample_rate = CalculateMixingFrequency(audio_source_list_); }
https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:153: RTC_DCHECK_LE(source_needed_frequency, APM::kSampleRate48kHz); On 2016/11/01 08:51:29, the sun wrote: > nit: _GE and switch order makes for a nicer printout whenever the DCHECK hits > (but I agree this is more readable...) I challenge this, and provide supporting evidence. In a test program, I entered a failing DCHECK: RTC_DCHECK_GE(argc, 10); # Check failed: argc >= 10 (3 vs. 10) RTC_DCHECK_LE(10, argc); # Check failed: 10 <= argc (10 vs. 3) So, I see no reason to stick to either variant from a printout-readability point of view. https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = [&]() { On 2016/11/01 08:51:29, the sun wrote: > I think this is a dubious use of a lambda. The need to make sample_rate const > isn't that big IMO, and writing simple code is ALWAYS preferable to using > advanced, new golden hammers. For this type of construct, this is a lot more > common (and to most developers more straightforward): > > int sample_rate = 0; > { > rtc::CritScope lock(&crit_); > sample_rate = CalculateMixingFrequency(audio_source_list_); > } Acknowledged.
https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = [&]() { On 2016/11/01 08:51:29, the sun wrote: > I think this is a dubious use of a lambda. The need to make sample_rate const > isn't that big IMO, and writing simple code is ALWAYS preferable to using > advanced, new golden hammers. For this type of construct, this is a lot more > common (and to most developers more straightforward): > > int sample_rate = 0; > { > rtc::CritScope lock(&crit_); > sample_rate = CalculateMixingFrequency(audio_source_list_); > } I'd like to keep it unless reviewers insist otherwise. My argument is that the syntactical overhead isn't particularly big, that most devs are quite familiar with lambdas and that we already use exactly the same pattern in several other places in the code base (consistency :D). I did a grep on "}()" and found 4 more exact copies of this pattern and a few more places where a larger lambda was created and executed.
On 2016/11/01 10:29:00, aleloi wrote: > https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... > File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): > > https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... > webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = > [&]() { > On 2016/11/01 08:51:29, the sun wrote: > > I think this is a dubious use of a lambda. The need to make sample_rate const > > isn't that big IMO, and writing simple code is ALWAYS preferable to using > > advanced, new golden hammers. For this type of construct, this is a lot more > > common (and to most developers more straightforward): > > > > int sample_rate = 0; > > { > > rtc::CritScope lock(&crit_); > > sample_rate = CalculateMixingFrequency(audio_source_list_); > > } > > I'd like to keep it unless reviewers insist otherwise. My argument is that the > syntactical overhead isn't particularly big, that most devs are quite familiar > with lambdas and that we already use exactly the same pattern in several other > places in the code base (consistency :D). I did a grep on "}()" and found 4 more > exact copies of this pattern and a few more places where a larger lambda was > created and executed. Did you grep for the other pattern and compare the # hits?
On 2016/11/01 11:09:56, the sun wrote: > On 2016/11/01 10:29:00, aleloi wrote: > > > https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... > > File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): > > > > > https://codereview.webrtc.org/2458703002/diff/120001/webrtc/modules/audio_mix... > > webrtc/modules/audio_mixer/audio_mixer_impl.cc:220: const int sample_rate = > > [&]() { > > On 2016/11/01 08:51:29, the sun wrote: > > > I think this is a dubious use of a lambda. The need to make sample_rate > const > > > isn't that big IMO, and writing simple code is ALWAYS preferable to using > > > advanced, new golden hammers. For this type of construct, this is a lot more > > > common (and to most developers more straightforward): > > > > > > int sample_rate = 0; > > > { > > > rtc::CritScope lock(&crit_); > > > sample_rate = CalculateMixingFrequency(audio_source_list_); > > > } > > > > I'd like to keep it unless reviewers insist otherwise. My argument is that the > > syntactical overhead isn't particularly big, that most devs are quite familiar > > with lambdas and that we already use exactly the same pattern in several other > > places in the code base (consistency :D). I did a grep on "}()" and found 4 > more > > exact copies of this pattern and a few more places where a larger lambda was > > created and executed. > > Did you grep for the other pattern and compare the # hits? Well, no, so my consistency argument is not valid...
aleloi@webrtc.org changed reviewers: + kwiberg@webrtc.org
I realized I need a reviewer who owns webrtc/api. kwiberg@, can you look at the change in webrtc/api/audio/audio_mixer.h? To fix a sample rate issue, the mixer is now allowed to select a mixing rate by itself, subject to some constraints.
lgtm for webrtc/api/ https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:159: APM::kSampleRate48kHz}; Why is this a std::vector and not a (static constexpr) array? std::begin and std::end work with arrays... https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index != native_rates.end()); Or RTC_DCHECK_NE?
https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:159: APM::kSampleRate48kHz}; On 2016/11/08 12:34:03, kwiberg-webrtc wrote: > Why is this a std::vector and not a (static constexpr) array? std::begin and > std::end work with arrays... Done. https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index != native_rates.end()); On 2016/11/08 12:34:03, kwiberg-webrtc wrote: > Or RTC_DCHECK_NE? Can't use DCHECKs for iterator types.
lgtm https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index != native_rates.end()); On 2016/11/08 12:52:22, aleloi wrote: > On 2016/11/08 12:34:03, kwiberg-webrtc wrote: > > Or RTC_DCHECK_NE? > > Can't use DCHECKs for iterator types. Right, because we can't print them. Someone should fix that...
On 2016/11/08 13:18:07, kwiberg-webrtc wrote: > lgtm > > https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... > File webrtc/modules/audio_mixer/audio_mixer_impl.cc (right): > > https://codereview.webrtc.org/2458703002/diff/140001/webrtc/modules/audio_mix... > webrtc/modules/audio_mixer/audio_mixer_impl.cc:162: RTC_DCHECK(rounded_up_index > != native_rates.end()); > On 2016/11/08 12:52:22, aleloi wrote: > > On 2016/11/08 12:34:03, kwiberg-webrtc wrote: > > > Or RTC_DCHECK_NE? > > > > Can't use DCHECKs for iterator types. > > Right, because we can't print them. Someone should fix that... lgtm.
The CQ bit was checked by aleloi@webrtc.org
The patchset sent to the CQ was uploaded after l-g-t-m from solenberg@webrtc.org, henrik.lundin@webrtc.org Link to the patchset: https://codereview.webrtc.org/2458703002/#ps160001 (title: "Static constexpr array.")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: mac_baremetal on master.tryserver.webrtc (JOB_FAILED, http://build.chromium.org/p/tryserver.webrtc/builders/mac_baremetal/builds/15955)
Description was changed from ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. TBR=solenberg@webrtc.org BUG=webrtc:6346 ========== to ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. NOTRY=True BUG=webrtc:6346 ==========
The CQ bit was checked by aleloi@webrtc.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...
Message was sent while issue was closed.
Description was changed from ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. NOTRY=True BUG=webrtc:6346 ========== to ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. NOTRY=True BUG=webrtc:6346 ==========
Message was sent while issue was closed.
Committed patchset #5 (id:160001)
Message was sent while issue was closed.
Description was changed from ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. NOTRY=True BUG=webrtc:6346 ========== to ========== Changed mixing to be done at the minimal possible frequency. This change changes mixing to be done at the lowest possible APM-native rate that does not lead to quality loss. An Audio Processing-native rate is one of 8, 16, 32, or 48 kHz. Mixing at a lower sampling rate and avoiding resampling can in many cases lead to big efficiency improvements, as reported by experiments. This CL also fixes a design issue with the AudioMixer: audio at non-native rates is no longer fed to the APM instance which is the limiter. NOTRY=True BUG=webrtc:6346 Committed: https://crrev.com/95611837087e57f59ece87f02b9479e58c6904e8 Cr-Commit-Position: refs/heads/master@{#14980} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/95611837087e57f59ece87f02b9479e58c6904e8 Cr-Commit-Position: refs/heads/master@{#14980} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
