summaryrefslogtreecommitdiffstats
path: root/media/audio/audio_util.cc
diff options
context:
space:
mode:
authorvitalybuka@chromium.org <vitalybuka@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-02-07 00:39:24 +0000
committervitalybuka@chromium.org <vitalybuka@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-02-07 00:39:24 +0000
commita0ee5409dd81d5927feac26c4c1e353194bea875 (patch)
treed19cc674dc097fbd540755000088f50ec8fa9c7c /media/audio/audio_util.cc
parent50ea4940c20d18da1bf210b49e166a3e2062df9e (diff)
downloadchromium_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.cc2
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,
&params);
return FAILED(hr) ? kFallbackBufferSize : params.frames_per_buffer();
-#elif defined(OS_LINUX)
- return 512;
#else
return 2048;
#endif