-
-
Notifications
You must be signed in to change notification settings - Fork 20.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stuttering audio on Chrome 89.0+ (upstream Chrome regression in ScriptProcessorNode) #47453
Comments
Might be useful for Godot users who can reproduce this issue to test Chrome Canary to see if https://bugs.chromium.org/p/chromium/issues/detail?id=1187016 is fixed for your test cases. It doesn't seem fixed for @3p0ch-NG's in my tests, but it might be for simpler test cases. To help upstream with debugging, it could also be useful to make a minimal reproduction project that they could run from Godot 3.2.3 or 3.3 RC 6 directly with one-click deploy, and/or provide a zipped export that they could self-host to reproduce the bug locally. |
I've uploaded the minimal project source here |
I also experience the same issue. To add, I found some leads in this reddit thread: It seems that even if we export by Threads, the new versions of Chrome and Firefox don't allow this due to some CORS headers. It will work fine if you're running locally, but if you're running it in a server (itch.io, etc.), it will require some headers to be present. I saw a workaround that involves updating the actual javascript file and manually adding-in the music. I haven't tried it yet but may be a good lead. |
I am working on a client project and have the problem with stuttering audio on their laptops with Chrome. However what I do not understand why, because we went the work-around route using Howler.js earlier during the project to avoid audio problems and stuttering. We are using this plugin: Does it make sense that I experience the same issues in Chrome on Windows? Also what is the possible timeframe to fix this issue? Basically we wait for Google to fix the Chrome regression? |
Hello, you guys have any info when this issue is going to fix? Its like 5 months and audio in html5 build still gone crazy. |
I'm not sure, but in the meantime you could try this workaround that worked for me: https://3p0ch.newgrounds.com/news/post/1148893 |
Is this still reproducible with 3.4 RC 2 or later, and in latest Chrome stable and canary? I tried https://www.newgrounds.com/portal/view/project/1594770 but it seems not to load anymore, it just shows a black screen and no sound. |
We are working on another client project for the browser at the moment, but we still have to integrate audio. I will be able to test it later this month. |
Sorry, the project originally made in 3.2.3 seems to have moved to |
That's great news! I can also confirm that the 3.2.3 project still stutters in latest Chromium for me, and the 3.4 RC 2 seems to work fine. Is the 3.4 RC 2 export done with a "regular" or "threads" build? |
The 3.4 RC 2 export was Regular. If I try to use a Threads export, it won't run (at least on NewGrounds) and the Developer Tools - Console window shows "Uncaught (in promise) ReferenceError: SharedArrayBuffer is not defined". That's even though NewGrounds gives an option to turn on "Uses SharedArrayBuffer/Cross Origin Isolation" -- it won't run regardless of whether I turn that on or off, although I admit I don't fully understand what it does under the hood. |
Just to clarify: We are currently using the WebAudioExternal addon and howler.js to avoid stuttering and performance issues. Has this workaround become obsolete? |
The test I did was to use 3.4 RC 2 and make a single AudioStreamPlayer node that autoplays an .ogg track (without setting up code myself to route through howler.js or anything) and exporting to HTML5, and at least that simple test case worked well. Audio for HTML5 exports from either Godot 3.2.3 or 3.3 using the same approach was glitchy in Chromium browsers. So it looks like Godot users can now have audio work well in Chromium without needing to do anything special on their end for HTML5 exporting if they're willing to use 3.4 RC 2 instead of 3.3. |
Just to understand this completely: does the 3.4 release generally solve stuttering audio (outside Chrome browser) in the browser described in this issue: It seem to be, because it was closed by this pull request: So basically, we can ditch the approach via howler.js now completely, right @akien-mga? |
That's my understanding yes, I'd just like to have a couple more reports that 3.4 works well so we can close this issue as resolved. |
Ah great, I will start integrating audio tomorrow in our current project and will make sure to report back here! |
@akien-mga Sorry, I could only send you the link to the project in private, because I can not make it public. |
Godot 3.5.stable I can not play .ogv video files on web export to ios safari without popping/crackling. I have tried increasing the buffer to the max 1000, and still have the issue. I really don't know what else to try? Enabling threads on the export results in continues loading to a spinning disk and never opens. Webm (both VP8 and VP9) do not play without issues, there is no way to play from a link or embed in iframe. At this point I just can't play videos... at least with good audio. Edit: Turns out it is somehow related to playing larger resolution video. Two video files of relatively same file size, frame rate, audio bitrate and audio sample rate. The larger 3840 X 2160 has popping/cracking, the lower resolution 1920 X 1080 does not. I also tried to make the tests even with making sure that the VideoPlayer Rect size matched the video resolutions, same results. both have same smooth video playback but the 4k video has static. My guess is either the encoder I used to convert from .mp4 to .ogv or the way it's being handled in Godot? Using shutter encoder which uses ffmpeg I converted 3 larger 3840 X 2160 videos all with popping/cracking on playback on is safari, 3 1920 X 1080 resolution videos showed no signs of popping/cracking? |
@ChildLearningClub This is an unrelated issue. 4K Theora decoding on iOS Safari (which goes through WebAssembly overhead) is very expensive, even on recent iOS devices. You don't benefit from viewing 4K videos on a mobile device anyway (due to the limited screen resolution and size), so stick to 1080p or even 720p 🙂 |
Any updates on this matter? |
So it has been a while since we built a mobile browser game, but we used Howler.js as a native sound engine and it worked very well. If you want to check the game, it is available here: |
I will, thank you. |
Godot version:
3.2.3 stable, 3.3 RC 6
Not a Godot regression, it's a Chrome update that triggered the issue for pre-existing builds which worked fine.
OS/device including version:
Windows 10 Home Build 19042
Mageia 9 x86_64 as of March 29
Affected browser versions:
Issue description:
Since Chrome 89.0.4389.90 (possibly older 89.0.x builds too), there's severe audio stuttering in most Godot web exports when playing music.
This appears to be a Chrome regression as the same exports were working fine prior to a recent update.
This is likely this upstream bug report: https://bugs.chromium.org/p/chromium/issues/detail?id=1187016
Which is the consequence of security fixes in ScriptProcessorNode.
The upstream bug report is supposed to have been fixed a few days ago in Chrome Canary, but I could still reproduce it with @3p0ch-NG's reproduction project. I'll report it upstream. Edit: Done: https://bugs.chromium.org/p/chromium/issues/detail?id=1187016#c66
Edit 2: New upstream issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1193494
(Moved this report from #43210 (comment) which is a different issue from what #43210 initially handled.
CC @rcbotCheeseh @CedLec @3p0ch-NG who initially commented on that other issue.)
Steps to reproduce:
There should be significant stuttering at the start and possibly throughout the whole playback (though I've also had times where it didn't stutter reliably).
Minimal reproduction project:
https://www.newgrounds.com/portal/view/project/1594770
The text was updated successfully, but these errors were encountered: