Changeset 259644 in webkit


Ignore:
Timestamp:
Apr 7, 2020 10:26:40 AM (4 years ago)
Author:
jer.noble@apple.com
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):

Location:
trunk/Source/WebCore
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • trunk/Source/WebCore/ChangeLog

    r259643 r259644  
     12020-04-07  Jer Noble  <jer.noble@apple.com>
     2
     3        Make sure playback of remote audio tracks is stable even if pages are using webaudio
     4        https://bugs.webkit.org/show_bug.cgi?id=210052
     5
     6        Reviewed by Eric Carlson.
     7
     8        If a client requests data from AudioSampleDataSource, and the time requested happens to land
     9        precicely on the end of the AudioSampleDataSoure's CARingBuffer's range, the function will get
     10        into an inconsistent state where it believes both that not enough samples are available to
     11        fulfill the request, but also that the number of frames available is equal to the number of
     12        requested frames. This is due to an off-by-one error, where the end of the CARingBuffer's range
     13        is incorrectly treated as inclusive, rather than exclusive. All subsequent requests will start at
     14        sampleCount + timestamp, as if that data was returned correctly, rather than returning zeros,
     15        propogating the error to future requests.
     16
     17        Fix this state by correctly checking if timestamp is greater-than-or-equal-to endFrame. This will
     18        cause the method to return zero frames, and correctly apply an offset so the next request will start
     19        at the same effective timestamp.
     20
     21        * platform/audio/mac/AudioSampleDataSource.mm:
     22        (WebCore::AudioSampleDataSource::pullSamplesInternal):
     23
    1242020-04-07  Alicia Boya García  <aboya@igalia.com>
    225

  • trunk/Source/WebCore/platform/audio/mac/AudioSampleDataSource.mm

    r254446 r259644  
    268268    uint64_t framesAvailable = sampleCount;
    269269    if (timeStamp < startFrame || timeStamp + sampleCount > endFrame) {
    270         if (timeStamp + sampleCount < startFrame || timeStamp > endFrame)
     270        if (timeStamp + sampleCount < startFrame || timeStamp >= endFrame)
    271271            framesAvailable = 0;
    272272        else if (timeStamp < startFrame)
Note: See TracChangeset for help on using the changeset viewer.