I have a couple of audio files that loop for background music. In the editor, they play correctly. But once uploaded to the web as a webgl build, they only play about halfway and then start over again. I have tried both wav and ogg files and several different music files, but they all seem to run into this problem. They play fine if looping is not selected and the build is uploaded (they play through and then stop at the end like expected). Both firefox and chrome experience the odd half-loop problem. Also, if it helps, this is a facebook canvas game. Does anybody have an idea of what might be causing this or a possible fix? Thank you for any help provided.
can you reproduce it locally ? what version of Unity ? would you mind submitting a bug report with a project we can use to reproduce it ?
Not sure if it's a bug or just by design. We discovered that if the audio is at 22k hz, it wasn't looping properly. Setting it to 44k hz allowed it to loop properly.
Yes, there is currently a bug (fixed in 5.5) with audio clips not imported at 44kHz. Web Audio resamples everything to 44Khz anyways, so for now, just set up your clip to be resamples to 44kHz in the editor, and you should be good.
This didn't seem to work for us. We have a WAV file downloaded via assetbundle and per the suggestion here, set "Override Sample Rate" and forced it to 44.1khz. It still does not loop properly in the WebGL build. Did I miss something?
FYI the workaround doesn't work 100% (version 5.4.2). It loops at the correct place, but there is a small audible "tick" when it does, while in the editor and standalone/mobile builds it is seamless. You can hear an example of this in this game (New game --> Choose Avatar --> Skip Tutorial): http://www.mohawkironworkers.com/rivetrampage/ It helps to lower the SFX volume in the pause menu to hear the tick better. Anyway, it's not a huge deal, but I do remember it working seamlessly in an earlier engine version. Maybe version 5.5 will fix it. Cheers!
Any upcoming fix for one shots in Chrome only playing through the right-hand speaker? Also these one shots seems to cackle in Chrome as well.
Have you built on Windows? It would be good to try Mac since we have a different audio asset import pipeline.
I don't know how the webgl audio pipeline is "in general" on Windows, but if you use mono audio files, you should only ever build on a mac. Currently there's a bug with Unity and webgl on windows where it will convert your mono files to stereo (greatly reducing the quality). We only build webgl on the mac for this reason. Bonus points if you use the cache server in which case building on a mac is not good enough (a Windows computer could have polluted the cache), in this situation you need to reimport audio every time you build (or build asset bundles in our case)! And to be a little more on topic: I'm pretty sure this is the same bug but with 48khz (non-44.1khz?) audio files setting the time from script does not function correctly. In webgl it will always set the time slightly off (having unity resample the audio files to 44.1khz fixes the issue).
The files I am having the issue with are not in mono. That's the thing. I've re-exported them from Studio One and they are certainly not mono. And yes I've tried saving them at different sample rates, and it doesn't make a difference. Why this only happens on Chrome I have no idea, all other browsers are fine.
I know this thread is a bit old but this is still an issue for us in 5.3.7p3. If it's fixed in 5.5, that's great, but we're not in a position to upgrade at the moment. Can I still submit a bug report?
As far as I can tell all 5.5 does is disallow you from setting the sample rate (forces 44.1khz). Forcing 44.1khz fixed our audio timing issues in 5.4.x. My only suggestion would be is ensure your asset bundles were actually updated after you forced 44.1khz (or maybe try a simple test without asset bundles).
This is without assetbundles altogether. Just a blank scene with 2 audio sources each with a clip that loops. One works great, the other doesnt (both sound fine in the editor). (edit) Both are forced to 44.1khz also.
I still have this in Unity 5.5.1f1 I activate my GameObject with the AudioSource via script. But the audio then is only played once and doesn't loop at all.
i still have the same problem in Unity 1019.2.21f https://drive.google.com/file/d/1ou7cjdLMoAsGFWSFHS7effqBnULRynRI/view?usp=sharing
@adam05jazz We've been fixing a lot of audio bugs and backporting them to 2020.3, could you try upgrading to the latest 2020.3 and seeing if you're still seeing this problem?
Hello, I just tested with Unity 2022.1.2 and there is always the looping problem with WebGL. I can upload my test case if you want: there is no script, only an audio source and a sample. Regards
@BachmannT a test case would be great! I'll also forward this to our engineer working on the audio bugs.
Hello, wonderful! Bellow a link to download the package: https://1drv.ms/u/s!Ao-u2_LaRuYimcsoq6ZplfxDQ4_MTw?e=pIYdjw There is two samples the original and the same but resampled at 44.1 khz with wavosaur. The two samples have the same behavior: loop start and loop end are correctly taken into account when playing in Unity editor (and Windows or MacOS app) but not when playing in a WebGL app. The sound always loops at the start of the sample. Tested with 2022.1.2. Thanks Regards
Ruba -- Upvote for the urgency of fixing this bug. I'm developing interactive components for online music education courseware using Thierry's Maestro MIDI Toolkit, and this bug kills my components. So long as this bug isn't fixed, I can't share my Web-based prototypes to get feedback on them...and I really need that feedback! Thanks for your attention to fixing this bug! Respectfully, Jim Plamondon
Hi, I looked into this issue and was able to reproduce it. I created bug ticket for it here: https://issuetracker.unity3d.com/is...han-in-the-editor-slash-native-desktop-player. As you said the issue might be that the loop start and loop end points are not used. Best wishes Marcel
Hello Marcel, We got a good rate vote for this issue and now it’s active. Good news! If you want, I could help or support your team in charge of this issue. We are really awaiting for a solution ! Unity Web application is a genuine discrimination in comparison with other platforms. Thanks a lot. Thierry
Hi The status is now: In Progress in 2023.2.X https://issuetracker.unity3d.com/is...han-in-the-editor-slash-native-desktop-player So, a good news could be expected? Please, we really need this fix!
Hi sir! I do have good news in fact! My fix has been approved this week, it should land in the latest version and be backported after that. I can't provide datea, but know that some latency was added in the mix because we've been migration the audio engine versioning system. We should be up to speed pretty soon. Cheers!