Note that I'm not including sample code, which I'm happy to do if asked, but I'll explain this below. The issue in a nutshell is that ALL my WebAudio projects over the past 11 years have exhibited this same frustrating bug, in Safari and Chrome, which is that if the page is backgrounded for X amount of time, when I return, audio is all silent, despite my code continuing to run with no errors or warnings. When this happens, I can look from the console and see that the WA context is still "running", it's currentTime is still advancing and plausibly still correct. But if I for instance make a call to create an AudioBufferSourceNode and play it (meaning, call my playSound() function that was working just fine before), I see whatever logging indicating my function is still running, but there is just no sound. The reasons for not including any sample code here: 1) This has happened on ALL my WebAudio projects since I first started using WA in 2013. Also, most such apps are doing just the most trivial things identical to MDN docs or typical tutorials -- load a sound into a buffer, have a function create a buffer source node, a gain node, hook them up to WA.destination and call node.start(). My point being, I am not doing anything even slightly unusual. 2) The problem persists about 90% of the time if I reload or super-reload the page. Audio will still be silent unless I close the tab and open the page in a new tab, and suddenly the audio works again. Obviously if the problem persists past my completely reloading my own code and re-initializing, then it is a bug in the browser, not in my code. 3) If my code is doing anything fishy, I have no idea what that is. And since the bug often takes over an hour to manifest -- that is, usually if I background the page for say 10 minutes (with no audio being sent to destination in that time either), and return to the page, the audio is still working. SOMETIMES the bug happens within a minute or two of backgrounding, but on other occasions, audio has still worked even hours later, even when my laptop was suspended and resumed. Point being, I have no way to easily reproduce the bug to determine what, if anything, my code has to do with it. I would suggest that ANY WA code that loads an audio buffer, and has a playSound() function like every example you can find online, would show this bug, but it is hard to reproduce as it can take a while to manifest. In my code, typically, I am not doing anything to attempt to deal with the page being backgrounded. I'm not responding to visibility changes and suspending the WA context to resume when the page is made active. My reason for this is that the apps I'm working on are all musical apps that would ideally be able to keep playing in background. I will do some experiments with trying to explicitly suspend/resume the context on backgrounding, and even try re-creating the context and reloading all my audio samples (my current app loads one 1 second sample, only), to see if the bug stops happening. I am VERY HAPPY to provide any code or assist with this bug as needed. I'm nostly concerned that such a bug could exist for over a decade and not only not be fixed but apparently never even reported, as honestly it is the ONLY show-stopper for my ever trying to release an app using WebAudio. If the user can suddenly lose all sound AND cannot fix the issue even with a page refresh, and it's not logging anything at all, I can't work around that and it's not acceptable end-user behavior for the type of music-creation tools I'm working on.
Is this on macOS only, not iOS? There's lots of reports of this on iOS right now, which apply to my app too, but I am not seeing any issues regularly on macOS. Though I did have one user report something like it when they left Safari idle for >45 minutes.
Yes, please add a test case and detailed steps to reproduce.
<rdar://problem/132352181>
Well, I can now confirm that this issue goes away completely for me if I add a listener for visibilitychange and suspend/resume the context. So, AGAIN, the steps to reproduce are: 1) Create a WebAudio context 2) Create ANY method that plays sounds, using either a loaded audio buffer or an oscillator 3) DO NOT suspend/resume the context when backgrounded Expected behavior: The context should either remain active indefinitely OR should change its state to "suspended" if the browser is releasing the OS audio resources. Additionally something should be logged to the console to let the developer know the browser had to release the context's resources. Actual behavior: After an indeterminant amount of time, if backgrounded (either going to another browser tab or another app), the context claims it is still "running" and its currentTime is still incrementing, but no sound comes out of the speakers. RELOADING THE PAGE DOES NOT RESOLVE. Are you still insisting on sample code for the above? It's literally DO ANYTHING WITH WEBAUDIO. As long as the code does not suspend the context, the issue always occurs for me, though sometimes in minutes, other times in hours.
If you would like me to help in any way, please provide a test case. I will not be making one based on a textual description. Otherwise, we can wait for someone else to take a look. Which may be OK anyway, as I won't be actually fixing the issue, just helping prioritize.
There is an issue with web audio cutting out in Safari on iOS. Here are steps to reproduce in Safari on iOS 17.5.1 AND iOS 17.6 RC: 1) Start with a freshly opened Safari (force quit and open), with no tabs. Go to https://www.macguffinandshemp.com/iOS17test/ 2) Press "Audio sprite loop" (bottom-left), and you will hear the noise on a loop. 3) In a 2nd Safari tab, go to the same site (https://www.macguffinandshemp.com/iOS17test/). You will still hear some choppy sound from the first tab in the background. Press "Audio sprite single play" on the TOP RIGHT of the 2nd tab to play a single, white noise sound. 4) After the sound is completely done playing, close the 2nd tab. 5) Upon returning to the original Safari tab, the audio sprite loop is continuing to play, but can no longer be heard. The audio context state (createjs.WebAudioPlugin.context.state) is still "running" but currentTime is NOT increasing (check the console). 6) Calling createjs.WebAudioPlugin.context.suspend() followed by createjs.WebAudioPlugin.context.resume() brings back the audio. 7) Repeat steps 1-5, but after step 5, press on the top-right "Audio sprite single play" in the first tab. 8) Now, the audio context cannot be resumed, even by suspending and resuming, yet is still in the "running" state. This is affecting our apps because we have multiple games in WKWebViews with sounds. When audio from one game plays, the audio from the second game cuts out. We must manually suspend/resume on visibility change, even when the context is set to "running," which I believe is a bug. Even suspending and resuming the context doesn't work in all cases, as shown in step 7.
Thank you. I can reproduce that the audio in first frame fades out when closing the second tab, and is not heard again. I used iOS 18 beta. "Backgrounded for a while" could be a bit confusing, I would expect more like 30-60 seconds from that description. Re-titled to hopefully be more clear, but someone will need to figure out the root cause to know the exact circumstances.
@Matthew, do you see this in 17.6.1 ? I could not reproduce it following those steps. Though the background tab seems to get quieter when the new foreground tab plays the "audio sprite single play" and take some time to return to full volume, like some AGC is going on.