diff options
author | enal@chromium.org <enal@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-12-21 01:27:03 +0000 |
---|---|---|
committer | enal@chromium.org <enal@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-12-21 01:27:03 +0000 |
commit | 3c99d2c8a26c5b2297f36900c3e277360c1f120a (patch) | |
tree | 04071b030e99ad7df94d83447d6b68fc3fda1f09 /content/renderer/renderer_webaudiodevice_impl.cc | |
parent | 024bba94451a673bcaa61394e2130e4bdc0ac0df (diff) | |
download | chromium_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.cc | 7 |
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; } |