diff options
author | vitalybuka@chromium.org <vitalybuka@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-02-07 00:39:24 +0000 |
---|---|---|
committer | vitalybuka@chromium.org <vitalybuka@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2013-02-07 00:39:24 +0000 |
commit | a0ee5409dd81d5927feac26c4c1e353194bea875 (patch) | |
tree | d19cc674dc097fbd540755000088f50ec8fa9c7c /media/audio/audio_util.cc | |
parent | 50ea4940c20d18da1bf210b49e166a3e2062df9e (diff) | |
download | chromium_src-a0ee5409dd81d5927feac26c4c1e353194bea875.zip chromium_src-a0ee5409dd81d5927feac26c4c1e353194bea875.tar.gz chromium_src-a0ee5409dd81d5927feac26c4c1e353194bea875.tar.bz2 |
Revert 181105
Compialtion error:
media/audio/linux/alsa_output.cc: In member function 'snd_pcm_sframes_t media::AlsaPcmOutputStream::GetCurrentDelay()':
media/audio/linux/alsa_output.cc:600: error: no matching function for call to 'max(long int, long unsigned int)'
make: *** [out/Debug/obj.target/media/media/audio/linux/alsa_output.o] Error 1
> Reduce Linux low latency buffer size to 512.
>
> Since ALSA uses an internally large buffer that we fill piecemeal
> by our internal buffer size, we can reduce our internal size in
> exchange for more frequent callbacks. This change:
>
> - Removes kernel timeslice adjustment. Shouldn't be necessary on
> modern kernels.
> - Removes minimum callback time between OnMoreData() calls in favor
> of locking the shared memory (192kHz audio isn't possible otherwise).
> - Fixes jitter introduced by premature clipping of delay information.
> - Removes useless code paths.
> - Switches to using TimeDelta throughout for accuracy.
> - Initializes playback with silence to avoid 192kHz startup glitches.
>
> This resolves playback issues with 192kHz content and latency issues
> as noted by our performance tests. With the shared memory block in
> place we should not see any glitching from the new buffer size.
>
> I believe the benefits of a 512-frame buffer w/ blocking shared mem
> are worth it in comparison to a 2048-frame buffer w/o blocking.
>
> BUG=172030
> TEST=audio playback is smooth, doesn't glitch, latency tests show ~60ms
> which is inline with Windows/Mac.
>
>
> Review URL: https://chromiumcodereview.appspot.com/12051082
TBR=dalecurtis@chromium.org
Review URL: https://codereview.chromium.org/12217052
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@181117 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'media/audio/audio_util.cc')
-rw-r--r-- | media/audio/audio_util.cc | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/media/audio/audio_util.cc b/media/audio/audio_util.cc index fe7b7ec..c03f502 100644 --- a/media/audio/audio_util.cc +++ b/media/audio/audio_util.cc @@ -200,8 +200,6 @@ size_t GetAudioHardwareBufferSize() { HRESULT hr = CoreAudioUtil::GetPreferredAudioParameters(eRender, eConsole, ¶ms); return FAILED(hr) ? kFallbackBufferSize : params.frames_per_buffer(); -#elif defined(OS_LINUX) - return 512; #else return 2048; #endif |