The webclient seems to take forever to load .ogg files and refuses to play .wav files, on my computer. Firefox takes a shorter time to play the .ogg files, but lags more than Chrome does when trying to play the music before the music starts. That being said, the webclient both browsers lag considerably when trying to play music. Chrome even crashes sometimes now.
Also, the webclient seems to play the game before fully downloading resources as well.
ID:1930018
 Sep 3 2015, 1:23 pm
|
|||||||||||||
| |||||||||||||
I don't. But try any 3 minute ogg file if you can, or something like that. I can make a demo if you really want.
| |
Demos are always ideal; if you can put one together it saves me a lot of time.
| |
Here's the demo: http://files.byondhome.com/Kamuna/TestCases/ TestCaseSound_src.zip
| |
I'm in the middle of converting XG MIDI into .OGG right now, so I'll toss a couple into my game this second and see if I can reproduce the issue in the webclient as well.
You say 3+ minutes, do you know if the issue happens with anything shorter? | |
Here are my results testing:
BYOND Client Behavior: .OGG files take time to begin playing, but only the first time. Once all maps with unique .OGG files had at least one play of their respective music file, returning to any of them, and other maps that shared one of those .OGG files, would begin immediate playback. BYOND Webclient Behavior: (Chrome 45.0.2454.85) Went through the same set of maps with a unique .OGG in the same order, then tried to go to any map that shared those .OGG and already-visited maps. Music took their original times to load, never gaining any instant playback. | |
Well, generally speaking, at the same quality level and download speed, the shorter the time, the smaller the size, the lower the download time.
| |
But that music should already be included in the cache file by default. In fact, it is; my resource file that was required for download after compiling in .OGGs was larger by pretty much the amount of space the .OGG files consumed in total.
Which means the system already has them. There's a persistent hiccup with reading/decoding/preloading them somewhere in the webclient that isn't happening in the Windows client. I'm going to see if I can't trigger this with other files types. I've got some insanely-massive MIDI files (4-10+MB) I could use for testing. | |
It's possible the delay is on the browser's end. In that case there may be ways to overcome that, as I'm sure others have run across this.
| |
Well, if someone has a fix for this that is client-sided, it is very much appreciated if they could share it here.
| |
Perhaps a simple HTML5 <audio>preload=auto or something similar (I stopped around HTML 3.2) will do the trick?</audio>
| |
With further testing, in the BYOND Windows Client, it seems that over a timespan of a few minutes, the .OGG audio no longer resides in buffer, and so there's lag while the audio comes back. At least, that is the behavior I am noticing.
| |
Dream Seeker does do all kinds of things to release memory it doesn't need, so that sounds about right. I could probably extend that for sound files, since by their nature they may not be used that often but timeliness is helpful.
| |
Perhaps precache sounds under a given size for instant access, leaving larger ones for buffering? That would seem a reasonable trade-off. That way, small things like short-duration SFX and like victory jigs are instant-play, and smaller songs won't need to wait to play.
| |
The music thing probably stems from the library we use to handle music, but that's something I can look into and see if there's a way to preload the music files so that there's no delay.
As for refusal to play certain formats, that's a limitation based on the fact that all browsers have different audio support, and it's something I'd like to address if possible.