Bug 211394 - createMediaElementSource not working
Summary: createMediaElementSource not working
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Audio (show other bugs)
Version: WebKit Nightly Build
Hardware: iPhone / iPad iOS 13
: P2 Major
Assignee: Brent Fulgham
Keywords: InRadar
Depends on:
Reported: 2020-05-04 13:23 PDT by Luigi Pulcini
Modified: 2020-05-19 20:41 PDT (History)
17 users (show)

See Also:

Patch (3.72 KB, patch)
2020-05-18 17:09 PDT, Brent Fulgham
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luigi Pulcini 2020-05-04 13:23:52 PDT
This bug seems to be related to the previous bug #203435, which is currently reported as RESOLVED FIXED.

We asked every user we could get in touch with to test the following player on their iOS devices. Not a single one of the visitors using a device with iOS 13, including the ones who upgraded to the recent iOS 13.4.1, managed to see the player playing back the audio track. The player is stuck as soon as the user hits the play button. No warnings or errors are reported in the browser console.

The player uses the `createMediaElementSource` WebAudio function to connect an HTML5 Audio Element as a source for an Analyzer Node so that the audio file can be analyzed and a waveform animated using the Frequency Data coming from the source can be rendered in the player canvas.

Currently, the only alternative we could find is a fallback to the regular Audio Element for all the iOS 13 visitors. A solution that excludes them from seeing the waveform animations.

Please note that this has been working just fine on any other recent versions of iOS until iOS 13 came out.

If needed, I can provide further details about the player.

Comment 1 Radar WebKit Bug Importer 2020-05-04 16:04:48 PDT
Comment 2 Adam McAmis 2020-05-06 09:03:16 PDT
Luigi's experience with this bug matches up directly with mine. I'm also using `createMediaElementSource` to analyze audio for https://saturn.fm.
Comment 3 dataexcess 2020-05-06 10:21:24 PDT
Same for me. Using audio with createMediaElementSource used in a there's positional audio environment. Not working.
Comment 4 dataexcess 2020-05-06 10:22:08 PDT
three-js positional audio environment*
Comment 5 David 2020-05-12 14:50:21 PDT
Have the same experience as outlined above. Please fix asap. User experience is ruined on iOS devices for my audio visualizer app.
Comment 6 Dries Cleymans 2020-05-13 13:32:47 PDT
We have the same issue. Our app works fine for all users, only those with an iPhone or iPad with iOS 13 or up can't play sound. 

No error occurs. The audio element associated with the node fires the 'play' event but no playback starts. We don't receive any 'timeupdate' from the audio element. When we don't use the 'createMediaElementSource' function on the audio element, the sound plays without a problem.
Comment 7 Eugene M. Joseph 2020-05-14 17:16:07 PDT
Same for me. This functionality is broken. createMediaElementSource is not working and thus analyzer nodes and visualizing audio are not working either. Everything was working fine till iOS 13 was released. It's been over half a year since this bug was first reported. Please bump this up/make this a priority.
Comment 8 Abe Shakim 2020-05-18 08:56:04 PDT
Verifying what all the others have described. This is still an issue. The `createMediaElementSource `WebAudio function is broken. Please fix asap. It's really ruining our customer experience on iOS devices. Works perfectly fine on Android phones and on desktops.
Comment 9 Brent Fulgham 2020-05-18 17:09:42 PDT
Created attachment 399684 [details]
Comment 10 Per Arne Vollan 2020-05-18 18:24:30 PDT
Comment on attachment 399684 [details]

Comment 11 EWS 2020-05-19 09:21:43 PDT
Committed r261865: <https://trac.webkit.org/changeset/261865>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 399684 [details].
Comment 12 Eugene M. Joseph 2020-05-19 10:19:32 PDT
Do we have a sense for when the fixes will land on iOS?
Comment 13 Eugene M. Joseph 2020-05-19 10:19:54 PDT
Also thanks for much for the prompt handling of this!
Comment 14 Adam McAmis 2020-05-19 10:37:46 PDT
+1 for the quick response, thank you Brent & Per! 🙌
Comment 15 Luigi Pulcini 2020-05-19 20:41:47 PDT
I agree with Adam McAmis: this was very fast compared to the previous report of the same issue.

Any word on the possible timeframe this patch will make it to the public would be very appreciated. The list of complaining users is growing quite fast and if we can expect this to be out soon, it doesn't make sense that we think of a fallback in the meantime.