[Webkit-unassigned] [Bug 224874] New: Stuttering audio from WebRTC in iOS 14.4.2

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=224874

            Bug ID: 224874
           Summary: Stuttering audio from WebRTC in iOS 14.4.2
           Product: WebKit
           Version: Safari 14
          Hardware: iPhone / iPad
                OS: iOS 14
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jeremy.noring at gmail.com
                CC: youennf at gmail.com

Created attachment 426698

  --> https://bugs.webkit.org/attachment.cgi?id=426698&action=review

Here's an extreme example of how bad it sounds.  I'd love for people to confirm this is what they're hearing.

A (likely very related) defect:

https://bugs.webkit.org/show_bug.cgi?id=218762

We have an application that can leverage both opentok and twilio backends to create video conferences via WebRTC.  In safari, on iOS, and mostly on 14.4 and up, our users are suffering from severe audio issues (I'd describe the output as "choppy", "robotic" or "stutter-y"; I'm happy to post an example of what it sounds like).  We've had a very hard time pinning down a reliable set of reproduction steps; the running theories include A) it may be more likely to reproduce on low-powered devices, devices in low-power mode, or devices where the page javascript is CPU intensive, B) it may have something to do with adverse network conditions (jitter, most likely), or C) ???.

I've reproduced this on opentok's demo page, in our own app using opentok (multiple versions, ranging from 2.19.0 up to 2.19.3), on mediasoup's test page, and even on appr.tc (reproduces less commonly). Some coworkers of mine have more difficulty reproducing it.

Here's the best set of reproduction steps I've seen thus far:

1. Visit opentok's demo page: https://opentokdemo.tokbox.com/ on an iOS device running 14.4.2 (I use an iPhone X)
2. Have another user join the same page via Chrome Desktop (our users are typically on Windows, but I've reproduced on macOS)
3. Both should be able to see and hear one another.  Duration of the discussion may matter.
4. The simplest way I've seen to reproduce the issue at this point is to pull down the control center menu on the iPhone (swipe down from the upper right corner), and/or background the safari tab.  Duration of the conference may matter, whether or not the phone is in low-power mode may matter, and network may matter, but... for some percentage of users, the audio ranges from static-y, to completely unusable.

Referring back to https://bugs.webkit.org/show_bug.cgi?id=218762 for a moment... I believe that jsfiddle posted by juberti is fixed, but there's something else at play here.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210421/9192708b/attachment.htm>