summaryrefslogtreecommitdiffstats
path: root/content/renderer/renderer_webaudiodevice_impl.cc
diff options
context:
space:
mode:
authorenal@chromium.org <enal@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-12-21 01:27:03 +0000
committerenal@chromium.org <enal@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2011-12-21 01:27:03 +0000
commit3c99d2c8a26c5b2297f36900c3e277360c1f120a (patch)
tree04071b030e99ad7df94d83447d6b68fc3fda1f09 /content/renderer/renderer_webaudiodevice_impl.cc
parent024bba94451a673bcaa61394e2130e4bdc0ac0df (diff)
downloadchromium_src-3c99d2c8a26c5b2297f36900c3e277360c1f120a.zip
chromium_src-3c99d2c8a26c5b2297f36900c3e277360c1f120a.tar.gz
chromium_src-3c99d2c8a26c5b2297f36900c3e277360c1f120a.tar.bz2
Fix start/stop of html5 audio stream and race condition when pausing.
(a) Update earliest time when html5 audio can end, thus fixing problem when the stream was being truncated too early, (b) Set length of data in buffer, so polling code used for several first buffers can stop waiting the moment data is ready, (c) Fix zeroing out end of buffer in partially filled buffer -- code was zeroing correct number of bytes, but at the beginning of buffer, not at the end. Lot of thanks to Shijing for identifying the issue, I heard that something is wrong but could not figure out exact cause. (d) Zero length of data in buffer when AudioDevice receives 'pause' command, thus work around race condition when one thread pausing the playback and other simultaneously asks for more data -- depending on exact timing buffer could be left in the unpredictable state, resulting in the next call for data getting extra buffer of silence (not fatal, but very noticeable when repeatedly playing short audio stream). (e) Remove pre-rendering of first buffer, it is not necessary for <audio>, WebAudio (confirmed by Chris), and WebRTC (confirmed by Shijing). WebRTC/WebAudio changes are actually no-op, as their renderers now just return 'I've filled the entire buffer'. Note: that CL fixes html5 audio playback of short streams. It is possible to further improve the code and maybe get rid of storing length of data in the buffer by changing the way AudioRendererBase::FillBuffer() signals end of playback. Right now it is synchronous, done only when host asks for more data, we probably can make it asynchronous, by issuing delayed task into the child process IO message loop, but that should be separate CL. TEST=Please load the page http://www.corp.google.com/~tommi/average.html and listen. TEST=I'll add layout test that verifies that timing is reasonable, but it will take TEST=some time to add. Review URL: http://codereview.chromium.org/8909006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@115253 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'content/renderer/renderer_webaudiodevice_impl.cc')
-rw-r--r--content/renderer/renderer_webaudiodevice_impl.cc7
1 files changed, 4 insertions, 3 deletions
diff --git a/content/renderer/renderer_webaudiodevice_impl.cc b/content/renderer/renderer_webaudiodevice_impl.cc
index c678a7b..77c6ba37 100644
--- a/content/renderer/renderer_webaudiodevice_impl.cc
+++ b/content/renderer/renderer_webaudiodevice_impl.cc
@@ -36,9 +36,9 @@ double RendererWebAudioDeviceImpl::sampleRate() {
return 44100.0;
}
-void RendererWebAudioDeviceImpl::Render(const std::vector<float*>& audio_data,
- size_t number_of_frames,
- size_t audio_delay_milliseconds) {
+size_t RendererWebAudioDeviceImpl::Render(const std::vector<float*>& audio_data,
+ size_t number_of_frames,
+ size_t audio_delay_milliseconds) {
// Make the client callback to get rendered audio.
DCHECK(client_callback_);
if (client_callback_) {
@@ -49,4 +49,5 @@ void RendererWebAudioDeviceImpl::Render(const std::vector<float*>& audio_data,
client_callback_->render(web_audio_data, number_of_frames);
}
+ return number_of_frames;
}