Jump to content

Loading audio crashes IOS 8


efusien
 Share

Recommended Posts

Hi,

 

I'm working with Phaser 2.2.1

In the preloader state I preload 150 mp3 files. Total of 12Mb. It's quite big.

game.load.audio("mySound", "mySound.mp3");

On IOS8 the page loads all the sounds, but after a quick delay the page breaks and refresh itself.

Is there a limitation on IOS8?

 

Maybe a better way should be to lazy load my audio files and then unload them?

Is it possible to unload audio file from memory?

Link to comment
Share on other sites

The mp3s might be 12mb on disk but you need to consider the size of the uncompressed audio data in memory. If your audio files are stereo then one quick way to halve the total uncompressed size would be to convert them all to mono.

Link to comment
Share on other sites

Does the code below removes the sound from memory?

game.cache.removeSound("test");

I guess not.

A quick test with a 15K mp3 file, loaded 2000 times and removed on the fly:

for (var i = 0 ; i < 2000 ; i++) {    game.load.audio("test_" + i, "test.mp3");    game.cache.removeSound("test_" + i);}

This test fail on small IOS devices: the web page refresh itself again and again.

Link to comment
Share on other sites

Well don't forget that loading is generally asynchronous so your test might not be doing what you think it is, I'd need to check the Phaser source code to be sure but it's possible that even if you remove the sound from the cache it may still continue to load if it has not completed doing so when you call 'removeSound'. A better test would be to only call removeSound once you are sure the mp3 is loaded, decompressed and ready to use.

Link to comment
Share on other sites

It takes a little time for something to load into the cache, so your 'removeSound' will trigger before the sound is even loaded. I've found that Phaser doesn't generate an error if you try to remove something from the cache that isn't there, which is why you're probably not getting any errors. I'd suggest using the 'onLoadComplete' signal:

var myKey = "test";var myAudio = game.load.audio(myKey);myAudio.onLoadComplete.add(function() {   game.cache.removeSound(myKey);}

Hope this helps.

Link to comment
Share on other sites

Yep, my mistake.

I'have tried with the onLoadComplete, but the result is the same. Page crashes.

 

The best option seems to set only a little set of sounds and overwrite them with new ones on next states.

Looks like the best choice for now, but it doesn't solve the problem of destroying sounds in memory.

 

Phaser call destroy function on state shutdown, right?

So if I load only sounds for the current state, and if destroy clear the memory usage, we shoud be in business. Need to confirm.

 

As alex_h said, I didn't try with sound.onDecoded event.

Maybe we have to wait until the sound is decoded before destroying it?

Link to comment
Share on other sites

  • 2 weeks later...

Try loading .m4a files for iOS. Mp3 files take a long time to decode and this usually results in crashes.

 

You can do this specifically for iOS (although I find m4a works quite well on Chrome and Safari desktop as well as Android):

if(game.device.iOS) {   game.load.audio("mySound", "mySound.m4a");} else {   game.load.audio("mySound", "mySound.mp3");}
Link to comment
Share on other sites

  • 4 weeks later...

Hi Efusien! 

 

Did you have any luck with this?

 

I'm having a similar problem, in our case the game crashes randomly when restarting states (ie. it crashes only when restarting a state, but not always at the same point/state), in the same way it crashes for you, and wondering whether we're just skirting the memory limit with our audio file. 

Did you obtain any good result with loading only the files you need and then destroying them, for each scene? (that wouldn't be ideal for us, as we use a single big audiosprite, but well, we might probably be fine making two versions of it or something so). 

 

Also, thanks for the tip re m4a Nick, the guy working with me would have been really quite better off had he known some time ago :D 

Link to comment
Share on other sites

Hi @vorrin,

I tried some different ways but I don't really know if it's a great improvement.

 

The last one is to load a sound only when needed, in a specific var. Then replace this var with a new sound if needed (destroying the old sound on the fly).

So we only have 1 var for a group of sounds, with lazy loading.

 

An other way is to load all sounds you need for a state in a specific array with keys pairing sounds ids.

 

On a Cordova App, I use the plugin nativeaudio. But you need to have a Cordova app.

Link to comment
Share on other sites

efusien, so , basically you are actually downloading audio files just as you need them, and making sure you call destroy on the previous ones?

 

By the way, this is probably only slightly related to this, and is focusing on images breaking safari's memory management, but I reckon the underlying problem is the same, and useful tools and ways to debug are mentioned, so maybe it could somewhat help you: http://www.html5gamedevs.com/topic/11591-ios8-memory-issuestwo-caches/page-2?hl=+safari%20+phaser 

 

And mwatt, not quite sure, but it looks to me like removeSound actually deletes a sound from the cache (ie. theoretically ,really should remove it from memory (though possibly doesn't cause of apple's magical optimizations, which cause crashes)), whilst destroy  just destroys an instance of a sound. That is after a brief look at the source code, so please doublecheck and apologies if I am talking nonsense :) 

Link to comment
Share on other sites

Nope ( see here )! We use mp3 with it, and m4a, which might have been the better format to go (but we understood that late :D ) , also works, but does not affect the crashes we're getting in the least, apparently.

 

For context, we use a single big (well, 2mb) audiosprite file, and ios safari just blows up with 'A problem occurred with this web page so it was reloaded' when loading a new level, or well, fundamentally calling state.restart() (usually happens after having played a few before). I currently reckon this is memory related, and has got more to do with images than audio, but not quite sure what in the world could be causing it.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...