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/media/audio_renderer_impl.h | |
| 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/media/audio_renderer_impl.h')
| -rw-r--r-- | content/renderer/media/audio_renderer_impl.h | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/content/renderer/media/audio_renderer_impl.h b/content/renderer/media/audio_renderer_impl.h index 1c8ec6a..f555b11 100644 --- a/content/renderer/media/audio_renderer_impl.h +++ b/content/renderer/media/audio_renderer_impl.h @@ -75,9 +75,9 @@ class CONTENT_EXPORT AudioRendererImpl void DoSeek(); // AudioDevice::RenderCallback implementation. - virtual void Render(const std::vector<float*>& audio_data, - size_t number_of_frames, - size_t audio_delay_milliseconds) OVERRIDE; + virtual size_t Render(const std::vector<float*>& audio_data, + size_t number_of_frames, + size_t audio_delay_milliseconds) OVERRIDE; // Accessors used by tests. base::Time earliest_end_time() const { |
