Summary: | iOS 13 html audio tag is totally broken: MediaPlayback entitlements error. | ||
---|---|---|---|
Product: | WebKit | Reporter: | distinctdan |
Component: | Web Audio | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Critical | CC: | ashley, bfulgham, brian+webkitbugzilla, cdumez, ddkilzer, eric.carlson, jer.noble, pvollan, webkit-bug-importer, youennf |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 13 | ||
Hardware: | iPhone / iPad | ||
OS: | iOS 13 |
Description
distinctdan
2019-11-15 16:12:31 PST
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. 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? Also, what is the session.state value after calling resume() in a user gesture? Chris: Is the Process Assertion warning related to Bug 203633? 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. 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. (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! Could be due to a sandbox violation, though I don't recall us changing this between 13.1 and 13.2.3. Sandbox: com.apple.WebKit(36278) deny(1) mach-lookup com.apple.audio.AudioQueueServer Confirmed WebContent sandbox is unchanged from 13.0 through 13.2.3. 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. 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. Do you have a Xcode project where the issue can be reproduced? Seems like a dupe of: Bug 203435 *** This bug has been marked as a duplicate of bug 203435 *** |