This bug is a request for discussion with a link to a simple fix.
Admittedly, iOS Safari and audio "autoplay" are a bit of a dark art. Any number of things can prevent a page from playing.
In #270 , a code patch was merged to resume the audio context on click, touchstart and touchend. In my testing, this works on Chrome and Safari desktop, but fails on iOS mobile unless I use an actual mouse click via trackpad or similar.
Removing touchstart from miniaudio.unlock_event_types makes it work, as the criteria for autoplay is met only when the first finger is removed from the screen. I have done that in this commit: frogtoss@efd5432 .
The current best practice is to have a "tap to start" button on a webpage, to get the necessary event that allows for the audio context to resume. For me, this raises a point: what works for resuming audio is going to change over time, as browsers update. Ideally, miniaudio would offer an event or promise to hook to when the audio is sucessfully resumed to start the actual app, rather than monitor a set of events on that "tap to start" button that attempt to ape what Miniaudio is doing.
Would a code patch to hook into successful audio context resumption be of interest, and if so, what would this code patch look like in your eyes?
This bug is a request for discussion with a link to a simple fix.
Admittedly, iOS Safari and audio "autoplay" are a bit of a dark art. Any number of things can prevent a page from playing.
In #270 , a code patch was merged to resume the audio context on
click,touchstartandtouchend. In my testing, this works on Chrome and Safari desktop, but fails on iOS mobile unless I use an actual mouse click via trackpad or similar.Removing
touchstartfromminiaudio.unlock_event_typesmakes it work, as the criteria for autoplay is met only when the first finger is removed from the screen. I have done that in this commit: frogtoss@efd5432 .The current best practice is to have a "tap to start" button on a webpage, to get the necessary event that allows for the audio context to resume. For me, this raises a point: what works for resuming audio is going to change over time, as browsers update. Ideally, miniaudio would offer an event or promise to hook to when the audio is sucessfully resumed to start the actual app, rather than monitor a set of events on that "tap to start" button that attempt to ape what Miniaudio is doing.
Would a code patch to hook into successful audio context resumption be of interest, and if so, what would this code patch look like in your eyes?