[Webkit-unassigned] [Bug 239996] New: Audio input and output are silent when joining WebRTC call and using AudioContext

[bugzilla-daemon at webkit.org]

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

            Bug ID: 239996
           Summary: Audio input and output are silent when joining WebRTC
                    call and using AudioContext
           Product: WebKit
           Version: Safari 15
          Hardware: iPhone / iPad
                OS: iOS 15
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: WebRTC
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: teodor.atroshenko at gmail.com
                CC: youennf at gmail.com

User joins a video call on their iPhone, either via WKWebView or via Safari. At least 80% of the time, there will be no audio coming *out* from the iPhone and there will be no audio coming *in* (server gets zeroed audio stream).

Usually, opening Control Center (swipe down) and changing "Mic Mode" instantly "unlocks" the stuck audio - server gets non-zeroed stream and the device starts playing incoming audio. Sometimes this doesn't have any effect and audio remains muted in both directions.

Sometimes, it is possible to break a working two-way audio by locking the screen and then unlocking it and refocusing the app. This *never* happens when putting Safari or WKWebView in background (minimizing) - refocusing the app instantly resumes playback. In both cases (locked screen and minimized) the AudioContext is suspended. In both cases an attempt to resume it is made. In case of locked screen it sometimes works and sometimes it does not. If no attempt to resume the AudioContext is made, then no audio will play in *both* cases (locked screen and minimized).

This bug is occurring on iOS 15.4 and 15.5 Beta 3, on iPhone 8 through iPhone 13, including iPhone XR, as well as iPads.

It is possibly caused by AudioContext not being resumed when requested. We create AudioContext when page loads - there is a lot of bootstrapping happening thanks to bug 230902 and other issues that need to be worked around on iOS (e.g., inability to obtain two instances of the microphone stream from different places in code). Once the microphone/camera permission is granted, AudioContext is resumed (or at least attempted to be resumed). I believe that there is either a race condition between microphone capture and AudioContext resuming, or there is some blocking condition, which requires reinitialization of the audio graph to get past it (by changing Mic Mode).

If it works upon page load, then it will almost certainly continue working until Safari/WKWebView are restarted, then you are back to 20/80 chances.

<WishfulThinking> It would be delightful if a clean rewrite of WebRTC/AudioContext audio stack materializes itself into iOS 16 </WishfulThinking>

Note: I can also still reproduce bug 230902 on iOS 15.4 in less than 5% of the tests - that issue is *not* fixed and may or may not be related to this one.

-- 
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/20220503/5acade5f/attachment.htm>