Bug 211829 - WebRTC Audio fail to capture from lock screen in Safari
Summary: WebRTC Audio fail to capture from lock screen in Safari
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Safari 13
Hardware: iPhone / iPad iOS 13
: P2 Critical
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2020-05-12 22:25 PDT by Vicky Cen
Modified: 2022-02-12 21:46 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vicky Cen 2020-05-12 22:25:18 PDT
Steps to reproduce:

1. On an iPad, go to https://webrtc.github.io/samples/
2. Lock the screen manually and wait for 5 seconds
3. Unlock the screen and select sample "Audio-only getUserMedia() output to local audio element" from the tab.
4. Make a pop sound and you can't hear yourself.
5. Refreshing the page you can't still hear the sound. Only after you restart safari or manually open a new tab with "Audio-only getUserMedia() output to local audio element", the sound will work for you.

It's happening on iPad with IpadOs 13.2.2 and iPhone 6s with IOS13.3.1
Comment 1 Radar WebKit Bug Importer 2020-05-13 16:22:38 PDT
<rdar://problem/63205337>
Comment 2 Vicky Cen 2020-05-13 18:28:42 PDT
This is affecting our web application. When a 2-way webrtc call is established, if 1 party is using iPhone / iPad, and joins the call after unlock the screen and from an existing tab in safari, this party's audio is not sent, so the other party cannot hear iPhone / iPad user but video track works well. When this issue happens, checking peerconnection.getStats() for iPhone / iPad user, the audio.sent.bytessent is 0. 
Restart Safari or joins the call by opening a tab (clicking the "+" in safari to open a tab) can solve this problem. 

This is making an impact on our product as our customers don't understand the workaround and report it as a critical issue to us. 

Are there any other workaround / solutions before this is fixed? Or is there any timing for the fix?
Comment 3 Brent Fulgham 2022-02-12 21:44:29 PST
This is actually:
<rdar://60486776>
Comment 4 Brent Fulgham 2022-02-12 21:45:28 PST
This issue was fixed by Bug 209411 and Bug 209412.
Comment 5 Brent Fulgham 2022-02-12 21:46:06 PST
These fixes should be in shipping releases.