Bug 204261 – iOS 13 html audio tag is totally broken: MediaPlayback entitlements error.

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Web Audio

I have a cordova game running a wkwebview on iPadOS 13.2.2 and I'm trying to play an html audio element that's connected to an AudioContext. However, the audio never plays at all. No javascript errors are thrown, and everything appears perfectly happy from the js side. I'm not trying to do background audio, this is just normal foreground audio. Here's the native error that's thrown:


2019-11-15 18:27:09.610800-0500 Orbus[9045:99562] [assertion] Error acquiring assertion: <NSError: 0x2811ddfe0; domain: RBSAssertionErrorDomain; code: 2; reason: "Client is missing required entitlement"> {
    userInfo = {
        RBSAssertionAttribute = <RBSLegacyAttribute: 0x111048cf0; requestedReason: MediaPlayback; reason: MediaPlayback; flags: PreventTaskSuspend | PreventTaskThrottleDown | WantsForegroundResourcePriority>;
    }
}
2019-11-15 18:27:09.610840-0500 Orbus[9045:99562] [ProcessSuspension]  0x108ee7138 - ProcessAssertion() PID 9045 Unable to acquire assertion for process with PID 9045
2019-11-15 18:27:09.610894-0500 Orbus[9045:99269] [ProcessSuspension] 0x108ee7138 - ProcessAssertion::processAssertionWasInvalidated()


My code checks for the state of the audio context and waits for a user interaction if necessary (which shouldn't be necessary in a webview anyways), but iOS tells the js that everything is fine. This used to work fine in iOS 12. Also, weirdly enough, the audio does play in an iPadOs 13.2.2 simulator even though the error is still thrown. However, when running on an identical real device, it doesn't play. Seems like just regular old audio playing shouldn't require any sort of special entitlement. Music is an important part of my app, so this is a pretty big deal to me. Any workarounds would also be welcome.

Also, I tried setting the "Audio, AirPlay, and Picture in Picture" and "Background processing" flags in the Background Modes tab of xcode, but it didn't help.

[Radar WebKit Bug Importer]

<rdar://problem/57257358>

[Jer Noble]

I know this is going to sound ridiculous, but we have to check the most basic problems first. WebAudio plays at the “ambient” audio session category. Which means it’s affected by the hardware mute switch. Can you verify that the mute switch in your test device is off?

[Jer Noble]

Also, what is the session.state value after calling resume() in a user gesture?

[Brent Fulgham]

Chris: Is the Process Assertion warning related to Bug 203633?

[Brent Fulgham]

Would it be possible to capture a sysdiagnose on the failing device? I wonder if you are hitting a sandbox violation that could explain the change in behavior? It's hard to tell without access to a logging.

You can open an Apple bug report if you are uncomfortable attaching a sysdiagnose to this Open Source bug.

Sure thing, so I'm testing on an iPad Pro 3rd gen, which doesn't have a hardware mute switch, and I've made sure the volume is turned on. 

The audio context actually starts in a state of "running". I've tried calling resume on it anyways after a user gesture, but it doesn't make any difference. After I try playing my audio, the context state is still "running". Also, the promise returned from calling "myAudio.play()" resolves, just like it's a success. The html Audio element's "paused" property is also false, like it believes that it actually is playing. When running in a simulator, the audio does play, so I know my nodes are connected correctly.

I forgot to mention, I can play audio successfully through the same context using BufferSourceNodes. However, these are only suitable for very short sounds, so I'm unable to use them for playing longer things like background music.

@Brent - Yeah, I'd rather not post a sysdiagnose here, but I just ran one after reproing the error and submitted it in on the Feedback Assistant portal. In the description, I referenced this issue and referenced the log lines where the error occurs.

[Ashley Gullen]

This is also affecting all Construct 3 (www.construct.net) content published to iOS. A user has reported it to us here: https://github.com/Scirra/Construct-3-bugs/issues/3477

This is going to be really painful for us if this update goes out to everybody.

Our testing indicates iOS 13.1 was not affected, suggesting this is a regression in iOS 13.2 that still affects the latest iOS 13.2.3.

[Brent Fulgham]

(In reply to distinctdan from comment #7)
> @Brent - Yeah, I'd rather not post a sysdiagnose here, but I just ran one
> after reproing the error and submitted it in on the Feedback Assistant
> portal. In the description, I referenced this issue and referenced the log
> lines where the error occurs.

For the record: This ended up being <rdar://problem/57303963>.

Thank you for taking the time to file that!

[Brent Fulgham]

Could be due to a sandbox violation, though I don't recall us changing this between 13.1 and 13.2.3.

[Brent Fulgham]

Sandbox: com.apple.WebKit(36278) deny(1) mach-lookup com.apple.audio.AudioQueueServer

[Brent Fulgham]

Confirmed WebContent sandbox is unchanged from 13.0 through 13.2.3.

[Ashley Gullen]

I'd add that in our case (for Construct-made content), we only ever use the Web Audio API and never use the <audio> tag, and it still seems to be affected in the same way as described in this issue. So it suggests it affects all audio playback regardless of the API.

[Ashley Gullen]

From our investigation it looks like setting silent mode on the device now blocks WKWebView, whereas normal web pages (and some other apps) can continue to play sound. This inconsistency appears to have caused the confusion here where it seems like WKWebView can't play sound.

I'm not sure what the intended behavior is for this but it could well be an unintentional regression.

[Per Arne Vollan]

Do you have a Xcode project where the issue can be reproduced?

[David Kilzer (:ddkilzer)]

Seems like a dupe of:  Bug 203435

[David Kilzer (:ddkilzer)]

*** This bug has been marked as a duplicate of bug 203435 ***