Title: [259644] trunk/Source/WebCore
- Revision
- 259644
- Author
- jer.no...@apple.com
- Date
- 2020-04-07 10:26:40 -0700 (Tue, 07 Apr 2020)
Log Message
Make sure playback of remote audio tracks is stable even if pages are using webaudio
https://bugs.webkit.org/show_bug.cgi?id=210052
Reviewed by Eric Carlson.
If a client requests data from AudioSampleDataSource, and the time requested happens to land
precicely on the end of the AudioSampleDataSoure's CARingBuffer's range, the function will get
into an inconsistent state where it believes both that not enough samples are available to
fulfill the request, but also that the number of frames available is equal to the number of
requested frames. This is due to an off-by-one error, where the end of the CARingBuffer's range
is incorrectly treated as inclusive, rather than exclusive. All subsequent requests will start at
sampleCount + timestamp, as if that data was returned correctly, rather than returning zeros,
propogating the error to future requests.
Fix this state by correctly checking if timestamp is greater-than-or-equal-to endFrame. This will
cause the method to return zero frames, and correctly apply an offset so the next request will start
at the same effective timestamp.
* platform/audio/mac/AudioSampleDataSource.mm:
(WebCore::AudioSampleDataSource::pullSamplesInternal):
Modified Paths
Diff
Modified: trunk/Source/WebCore/ChangeLog (259643 => 259644)
--- trunk/Source/WebCore/ChangeLog 2020-04-07 16:38:32 UTC (rev 259643)
+++ trunk/Source/WebCore/ChangeLog 2020-04-07 17:26:40 UTC (rev 259644)
@@ -1,3 +1,26 @@
+2020-04-07 Jer Noble <jer.no...@apple.com>
+
+ Make sure playback of remote audio tracks is stable even if pages are using webaudio
+ https://bugs.webkit.org/show_bug.cgi?id=210052
+
+ Reviewed by Eric Carlson.
+
+ If a client requests data from AudioSampleDataSource, and the time requested happens to land
+ precicely on the end of the AudioSampleDataSoure's CARingBuffer's range, the function will get
+ into an inconsistent state where it believes both that not enough samples are available to
+ fulfill the request, but also that the number of frames available is equal to the number of
+ requested frames. This is due to an off-by-one error, where the end of the CARingBuffer's range
+ is incorrectly treated as inclusive, rather than exclusive. All subsequent requests will start at
+ sampleCount + timestamp, as if that data was returned correctly, rather than returning zeros,
+ propogating the error to future requests.
+
+ Fix this state by correctly checking if timestamp is greater-than-or-equal-to endFrame. This will
+ cause the method to return zero frames, and correctly apply an offset so the next request will start
+ at the same effective timestamp.
+
+ * platform/audio/mac/AudioSampleDataSource.mm:
+ (WebCore::AudioSampleDataSource::pullSamplesInternal):
+
2020-04-07 Alicia Boya García <ab...@igalia.com>
[GStreamer] Log a warning if playbin is not found
Modified: trunk/Source/WebCore/platform/audio/mac/AudioSampleDataSource.mm (259643 => 259644)
--- trunk/Source/WebCore/platform/audio/mac/AudioSampleDataSource.mm 2020-04-07 16:38:32 UTC (rev 259643)
+++ trunk/Source/WebCore/platform/audio/mac/AudioSampleDataSource.mm 2020-04-07 17:26:40 UTC (rev 259644)
@@ -267,7 +267,7 @@
uint64_t framesAvailable = sampleCount;
if (timeStamp < startFrame || timeStamp + sampleCount > endFrame) {
- if (timeStamp + sampleCount < startFrame || timeStamp > endFrame)
+ if (timeStamp + sampleCount < startFrame || timeStamp >= endFrame)
framesAvailable = 0;
else if (timeStamp < startFrame)
framesAvailable = timeStamp + sampleCount - startFrame;
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
