Bug 319706 – getUserMedia audio permanently fails with NotAllowedError: No AVAudioSessionCaptureDevice after an audiomxd media‑services reset on iOS 26

• Status: RESOLVED
• Resolution: FIXED
• Component: WebRTC

[Jaya Allamsetty]

Summary

On iOS 26, when the system audio daemon (audiomxd) crashes and resets — emitting AVAudioSessionMediaServicesWereLostNotification followed by AVAudioSessionMediaServicesWereResetNotification — a Safari page that calls navigator.mediaDevices.getUserMedia({ audio: true, video: true }) permanently fails to obtain the microphone with:

NotAllowedError: No AVAudioSessionCaptureDevice device

Video capture succeeds; only audio fails. Retrying getUserMedia in the same page context continues to fail; only a full browser reload recovers, and only after audiomxd has restarted. WebKit does not appear to rebuild the WebRTC audio capture source in response to the media‑services reset, so the capture path is left with no input device even though the microphone hardware is present and permission has been granted.

Impact

Real‑world telehealth deployment (Jitsi / lib‑jitsi‑meet based WebRTC app). Across one day of production traffic on a single customer, ~20% of iPhone/iPad visits logged this microphone‑acquisition failure, and ~64% of those never recovered audio during the visit — i.e., the remote party heard silence for the entire call. The equivalent Android/Chrome population on the same service the same day showed 0 occurrences of this signature.

Environment

- iPhone, iOS 26.5.2, Mobile Safari 26.5.2 (WebKit 605.1.15).
- Reproduced on the same tenant/app across Safari 26.3, 26.4, 26.5, 26.5.2, and 26.6.
- WebRTC app: lib-jitsi-meet; standard getUserMedia constraints {"video":{"height":{"ideal":720},"width":{"ideal":1280},"frameRate":{"max":30},"facingMode":"user"},"audio":{"autoGainControl":true,"echoCancellation":true,"noiseSuppression":true}}.

Steps to reproduce

1. On an iPhone running iOS 26.x, grant microphone permission to a WebRTC site in Safari (permission is confirmed granted — enumerateDevices() returns a labeled iPhone Microphone).
2. Get the device into a media‑services‑reset state — audiomxd terminates and posts AVAudioSessionMediaServicesWereLost → …WereReset (observed in the wild after heavy concurrent audio‑session usage; see "Contributing factor"). This also fires for other running audio apps simultaneously.
3. Call getUserMedia({ audio: true, video: true }) from the Safari page during/after the reset.

Actual behavior

getUserMedia rejects audio while video succeeds. JavaScript console (page side):

[WARN] rtc:RTCUtils  Failed to get access to local media.
       NotAllowedError: No AVAudioSessionCaptureDevice device {"video":{…},"audio":{autoGainControl,echoCancellation,noiseSuppression}}
[ERROR] app:tracks   Failed to create local tracks ["audio","video"]
       gum.permission_denied: User denied permission to use device(s): audio, video
[INFO]  rtc:RTCUtils  onUserMediaSuccess          ← video track only
[ERROR] app:tracks   Audio track creation failed … No AVAudioSessionCaptureDevice

- Permission was granted (device labels are populated), so this is not a user denial — WebKit surfaces NotAllowedError/No AVAudioSessionCaptureDevice because no capture device could be obtained from AVAudioSession.
- Subsequent getUserMedia retries in the same page (observed ~26 s and ~40 s later) fail identically. Only a full reload, after audiomxd is back, restores audio.

Root cause (device‑side os_log, audiomxd)

The audio daemon crashes and resets around the failed capture; capture never re‑establishes for the WebKit page:

audiomxd  AVAudioSessionXPCServer  Session with ID 0x… was removed        (×~40, burst)
WhatsApp  AVAudioSessionDaemonsStateManager  Received death notification for service: audiomxd
WhatsApp  …  Posting AVAudioSessionMediaServicesWereLostNotification
Gmail     …  Posting AVAudioSessionMediaServicesWereLostNotification       ← system‑wide, multiple apps
audiomxd  AVAudioSessionXPCServer  New connection …                        ← audiomxd restarts
WhatsApp/Gmail  …  Posting AVAudioSessionMediaServicesWereResetNotification
error audiomxd  AVAudioSessionRemoteXPCClient createProxySession:reply: failed due to session lookup failure for SessionID 0x730a1
error WhatsApp  AVAudioSession_iOS  Creating proxy session failed … Error Domain=NSOSStatusErrorDomain Code=-50 "Session lookup failed"
cameracaptured  FigCaptureClientApplicationStateMonitor  <…[com.apple.WebKit.GPU]> Received: AVAudioSessionApplicationStateDidChange
…
MobileSafari (com.apple.mobilesafari)  Set audio app property: InputMute value:0; Success getting AS_DetailedActiveAudioRoute   ← only works on a fresh session, later

The com.apple.WebKit.GPU capture process receives the audio‑session state changes but the page's getUserMedia audio remains failed until reload. This indicates WebKit does not rebuild the WebRTC capture source on AVAudioSessionMediaServicesWereResetNotification.

Expected behavior

After AVAudioSessionMediaServicesWereReset (and once audiomxd is available again), WebKit's capture stack should re‑create/re‑activate the AVAudioSession capture source so that a pending or subsequent getUserMedia({audio:true}) obtains the microphone — without requiring a page reload. At minimum, WebKit should retry capture‑device acquisition when the media‑services‑reset notification fires, rather than leaving the source with no capture device.

Contributing factor (hypothesis, not confirmed)

Immediately before the audiomxd death, the log shows ~40 AVAudioSession sessions torn down from a single process, and the page had issued dozens of HTMLMediaElement.setSinkId() calls (each NotAllowedError: A user gesture is required) during pre‑join. Heavy concurrent AVAudioSession churn from the WebKit media process may increase the likelihood of the audiomxd reset. This may be a second WebKit issue (excessive audio‑session creation for setSinkId/audio elements) worth investigating independently.

Scope / cross‑platform

- iOS Safari/WebKit only. Same app, same backend, same day: 0 occurrences on Android Chrome (149/150) across 86 conferences; the failure is absent on non‑WebKit engines that don't use AVAudioSession.
- Two WebKit surfaces of the same underlying cause were observed: No AVAudioSessionCaptureDevice (capture path, this report) and InvalidStateError: Failed to start the audio device (audio‑unit start / WebAudio path).

Frequency

Reproducible in production at meaningful scale (~1 in 5 iPhone sessions on the affected day). Deterministically observable on demand on an affected device.

Attachments (to include when filing)

- Full sysdiagnose from the affected iPhone captured at the time of failure (contains the audiomxd MediaServicesWereLost/Reset sequence and WebKit GPU process state).
- Safari Web Inspector JavaScript console log showing the getUserMedia No AVAudioSessionCaptureDevice rejection with labeled devices present.

Workarounds tried

- Retrying getUserMedia in‑page: does not recover.
- Full page reload doesn't fix it. Only when the safari browser is killed and restarted gUM works.
- Device restart: clears persistently‑wedged cases.

[Jaya Allamsetty]

Here is a link to the portal where the issue can be reproduced reliably the first time when the user requests mic access - patient login - https://www.google.com/url?q=https://healthcare.univago.com/api/meeting?api_username%3DbZUp_A%26data%3D1DhHSHPisk7t0YAacCHRHMJzqciUMgHTRBFE2tKngK%2B/mEI9HSI2sVxyyrrjpMg0VwOhYds981Nn393GZt4zEoNRI7ig4nw85k5aEuvSaRoB%2BkCC73zSBeIwUE8Ua2psFUjVnh7KEi1znY79LkXSuZwADGmChivcvK3CuClRV7MtcKfBRR237ovDItSswY52&source=gmail-imap&ust=1784920238000000&usg=AOvVaw22rjHOVRqx1F3KNOZCqhHW

Raising severity since capture process does not recover across a page reload or new tab; only a full Safari relaunch clears it.

[Radar WebKit Bug Importer]

<rdar://problem/183164001>

[Jaya Allamsetty]

The sysdiagnose files for this can be found here - https://drive.google.com/file/d/1eu97DgI4o1Ro09ATyrXn7VZGJIMLTPKR/view?ts=6a6c23ca

[youenn fablet]

I tried to reproduce the issue in https://webrtc.github.io/samples/src/content/getusermedia/audio/ by crashing audiomxd, manually or via https://developer.apple.com/library/content/qa/qa1749/_index.html.
I can see capture continuing though the audio rendering is much lower after the crash.
A reload of the page fixes the issue.
I am testing on iOS 27 beta though.

@Jaya, have you tested on iOS 27 beta using https://developer.apple.com/library/content/qa/qa1749/_index.html (settings -> dev -> reset settings).

I haven't tested yet on 26.x, it would be good also to confirm whether you can reproduce the issue via https://developer.apple.com/library/content/qa/qa1749/_index.html.

[youenn fablet]

Pull request: https://github.com/WebKit/WebKit/pull/70612

[Jaya Allamsetty]

@Youenn, I am not able to reproduce the issue on iOS 26.x by forcing a media services reset as mentioned in https://developer.apple.com/library/content/qa/qa1749/_index.html. The crash and subsequent gUM failures happened only once on my device, the first time the portal link was accessed. I tried clearing all the website data from settings->apps->Safari->advanced but no luck.

One thing that I however noticed was that when I tried to change microphone permission from ask->deny->ask, gUM failed some of the times.

[EWS]

Committed 318349@main (d2277d7a1837): <https://commits.webkit.org/318349@main>

Reviewed commits have been landed. Closing PR #70612 and removing active labels.

[Jaya Allamsetty]

Thanks for the quick turnaround. When can we expect the fix to be released? 
Will it make the cut for iOS 26.7? We would like to give a tentative date to our customer since it is affecting a big percentage of their users.