summaryrefslogtreecommitdiffstats
path: root/media
diff options
context:
space:
mode:
authordalecurtis@chromium.org <dalecurtis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-01-24 04:49:43 +0000
committerdalecurtis@chromium.org <dalecurtis@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2013-01-24 04:49:43 +0000
commit71d56063e53225d490540b23c0b80ab9bdc1ae29 (patch)
treec544ea9e448363649f1f7b5dfdaabc75873117cc /media
parentc0adcfd16fcc6fa3565be292b24368e9f79797c7 (diff)
downloadchromium_src-71d56063e53225d490540b23c0b80ab9bdc1ae29.zip
chromium_src-71d56063e53225d490540b23c0b80ab9bdc1ae29.tar.gz
chromium_src-71d56063e53225d490540b23c0b80ab9bdc1ae29.tar.bz2
Limit OnData() callbacks to every 5ms for mac audio input.
OSX doesn't like the audio data being retimed and we apparently can not have Flash use a larger buffer size... So this hack ensures each OnData() call has time to deliver audio data to the renderer without it being smashed by the next call. 5ms was chosen since we use the same value for a similar hack in AlsaPcmOutputStream. This is not ideal and instead Pepper input clients should be using at least a 4k buffer on OSX until switched to the low latency pipeline. There's no guarantee that the audio input stream won't drop out at a much later time, but in local testing it's much greater than the 1.5 minutes to dropout we have now. BUG=157613,168859 TEST=audio input doesn't drop out. longevity testing ongoing. Review URL: https://chromiumcodereview.appspot.com/12062002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@178517 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'media')
-rw-r--r--media/audio/mac/audio_input_mac.cc14
1 files changed, 6 insertions, 8 deletions
diff --git a/media/audio/mac/audio_input_mac.cc b/media/audio/mac/audio_input_mac.cc
index 69791cf..e741b29 100644
--- a/media/audio/mac/audio_input_mac.cc
+++ b/media/audio/mac/audio_input_mac.cc
@@ -197,17 +197,15 @@ void PCMQueueInAudioInputStream::HandleInputBuffer(
// back to back once that internal buffer is filled. When this happens the
// renderer client does not have enough time to read data back from the
// shared memory before the next write comes along. If HandleInputBuffer()
- // is called too frequently, Sleep() to simulate realtime input and ensure
- // the shared memory doesn't get trampled.
+ // is called too frequently, Sleep() at least 5ms to ensure the shared
+ // memory doesn't get trampled.
// TODO(dalecurtis): This is a HACK. Long term the AudioQueue path is going
// away in favor of the AudioUnit based AUAudioInputStream(). Tracked by
- // http://crbug.com/161383
+ // http://crbug.com/161383.
base::TimeDelta elapsed = base::Time::Now() - last_fill_;
- base::TimeDelta buffer_length = base::TimeDelta::FromMilliseconds(
- audio_buffer->mAudioDataByteSize * base::Time::kMillisecondsPerSecond /
- static_cast<float>(format_.mBytesPerFrame * format_.mSampleRate));
- if (elapsed < buffer_length)
- base::PlatformThread::Sleep(buffer_length - elapsed);
+ const base::TimeDelta kMinDelay = base::TimeDelta::FromMilliseconds(5);
+ if (elapsed < kMinDelay)
+ base::PlatformThread::Sleep(kMinDelay - elapsed);
callback_->OnData(this,
reinterpret_cast<const uint8*>(audio_buffer->mAudioData),