diff options
author | enal@chromium.org <enal@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-08-23 20:24:52 +0000 |
---|---|---|
committer | enal@chromium.org <enal@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-08-23 20:24:52 +0000 |
commit | 474c37af2d3afbc3d4bb78a0aac813f338fa7e5c (patch) | |
tree | 33d12ccbc7f679e98bba9bebe7b5e4b4603a353e /views/DEPS | |
parent | ec865268f9c9c9ef34f211a1257851b0482d1870 (diff) | |
download | chromium_src-474c37af2d3afbc3d4bb78a0aac813f338fa7e5c.zip chromium_src-474c37af2d3afbc3d4bb78a0aac813f338fa7e5c.tar.gz chromium_src-474c37af2d3afbc3d4bb78a0aac813f338fa7e5c.tar.bz2 |
Fix problem when 'ended' event was fired before stream really ended.
That caused impression that rewind does not work. With that
change small JS program
var a = new Audio("file:///home/enal/temp/click2/click2.wav");
var num_played = 0;
a.addEventListener('canplaythrough', function() {
a.play();
});
a.addEventListener('ended', function() {
num_played ++;
if (num_played < 10) {
a.currentTime = 0;
a.play();
}
});
works correctly, you hear 10 clicks one after another, and it takes
~1.5 seconds to play all 10 sounds (one click is 146ms). Current
Chrome plays only beginnings of the first 9 clicks and then entire
10th click -- 'ended' event fires too early, so rewind stops audio
playback for all clicks but last one.
With that fix you can easily create pool of audio objects -- on 'ended'
event just add audio object to the pool.
Fix consists of 2 parts:
1) When using low-latency code path renderer not only fills the buffer with
data, but also writes length of data at the end of buffer. That allows host
process to pass correct byte counts to renderer. Counter is written at the
endo of buffer, and by default it is set to buffer length, so no changes to
existing clients are necessary.
3) Renderer now keeps track of the earliest time playback can end based on the
number of rendered bytes, and will not call 'ended' callback till that time.
PS. After several comments I changed chrome code to make it much harder for
code to get buffer overrun. I was pointed that native client can write bogus
size of data into buffer, so function in chrome that reads size of data now
has extra argument -- max size of buffer, and returns min(max size of buffer,
size of data reported by client). This way min() is always called.
PPS. That is much scaled down version of the CL, it does not affect lot of
audio code paths...
BUG=http://code.google.com/p/chromium/issues/detail?id=78992
http://codereview.chromium.org/7328030
Review URL: http://codereview.chromium.org/7328030
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@97905 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'views/DEPS')
0 files changed, 0 insertions, 0 deletions