In the iOS examples there is small app called GameBuzzer. It’s a simple app that plays a different sound file depending on which of the two buttons you press. However, if you press either the buttons rapidly at least 250+ times the app will crash.
There seems to be a major issue with the way Xojo is handling sounds with iOSsound. What other alternatives do we have to play sound files in rapid succession (think drum machine)?
The demo project seems to be leaking memory, but very slowly. I clicked much more than 400 times on a button and activity monitor shows me about 80 MB memory usage. Long way until it will run out of memory. Do you have a crash log you could share? And if it proves to be a memory leak, this would be a case for a feedback report.
So why does the forum indicate there have been two or more replies to this since the one Ulrich posted, yet they don’t appear?
Thats for you too, Dave? Yes, something strange here. If Gavin had deleted his replies this should be shown at least
HI Ulrich, thanks for responding. I do have a crash log for GameBuzzer (see below). I am working on a similar app and keep encountering crashes when a sound is played continuously. I tested GameBuzzer to see if would do the same, which it does. In my app I have put the sound playing function into a thread. The app no longer crashes, however, the sounds stop playing after a certain number of iterations. There is a counter to track the number of times the touch is invoked. It still increments after the sounds have stopped so I know the touch events are triggering. I have found that that stopping the sound prior to playing it will prevent the crash, however, that introduces an unwanted click sound.
Crash Log:
https://www.dropbox.com/s/7k9yfjctwkacct7/GameBuzzer_Crashlog.rtf?dl=0
I had a bit of trouble posting that last message. Browser got caught up in a loop. Might explain the unseen massages.
Funny: I write here and your reply appeared, although I received it a while ago as mail notification.
Anyway: Did you close the view before the crash appeared? Looks to me like the delegate sends a touch notification to a view that doesnt exist anymore. Although that shouldn’t occur, the delegate should become Nil when the view is closed. But maybe Im wrong.
Be it as it may: When you send the sound into endless repeats, the app crashes quite fast when its memory consumption goes over the device limits. I made an instruments leak check and will file a bug report.
EDIT: Yes, from time to time the forum has hickups with certain threads.
Heres the report: <https://xojo.com/issue/42106>
Thanks Ulrich for looking into this! I appreciate your help.
I’m guessing the sound issue (memory/buffer overrun) causes the View to close, and the delegate sending a touch notification to a closed View is causing the actual crash. Just a thought.
In my app, although no crash occurs now, when the sounds stop working the background images in the app disappear too.
I tried it with an AVAudioPlayer from iOSLib. Besides the minor problem that no sound can be heard (must have made a mistake somewhere), its the same: When I play the sound endlessly repeated, memory usage goes up fast and after some time I have a “silent crash” the program exits as if it were quit normally. Nothing in console. Im a bit clueless right now.
I’ve run into this and found that if you have a sound file in your app and you repeatedly call .play directly from the sound file, that’s the cause of the memory leak. If you instead save an iOSSound object somewhere in memory and assign the sound file to it, and then call that sound’s .play, the crashing no longer occurs.
The problem here is you can’t play the same sound multiple times simultaneously. So you’ll have to check if it’s playing, and then decide what to do.
A secondary problem is that if you call iOSSound.Stop, it apparently takes a bit of processing power because it very briefly stalls the app. Wouldn’t matter much unless you’re making a game (which is usually why people use repeated sound effects like this…)