what is “release” supposed to do. I didn’t find “release” in combination with Sounds but the “release-approach” sounds as it could be worth to try.
And yes - I plan to load a reference to all files when opening the Mobile.Screen and play them, when the “user/customer” presses an “Play-Button”
Do you refer with “load + play + release” to “sound.Clone” ?
Arnauld - thanks for your reply - I had the same idea - but the event App.LowMemoryWarning() doesn’t ever fire. I also tried various devices and simulators (with different amount of memory). The behavior not to play more than 40 sounds stayed the same.
How would you search for a memory leak?
Emile, I have to describe better. Every sound is supposed to be played alone. Before sound(x) starts I stopp sound(y).
Actually I don’t reference the files by opening s = s.Open(f) … s.Play but I refer directly to the sound(names) I dropped into a folder on the left XOJO IDE column.
Therefore it might take me some time to do the changes you suppose… I’ll be back later
The memory leak may have nothing to do with the RAM. Inside operating systems, there are limits of various things, either explicit or not. For example, the exception StackOverflow is about the memory stack (a limited stack given to processes). Also, each Unix process has a limit of how many files it can keep open at the same time (though that value can be changed). On Windows, graphics handles are limited too (you can’t draw in more than 256 (IIRC) pictures at the same time in a given process, whatever amount of RAM you have). Plenty of other examples exist.
Ten years ago, my Mac once showed a weird behaviour: suddenly, I couldn’t launch any app by any means. The Finder, the dock, Terminal, Xojo’s launch command and any LaunchService call all returned an error -10810 and wouldn’t launch any app. Checking the meaning of the error code wasn’t that helpful: “-1080: Launch Services Unknown error”. Eventually, I found that once I quitted one app (whichever), I could open another one (but not two). I discovered there’s a number of processes a Mac can run simultaneously (IIRC, because of its Unix grounds), which was 255 at that time, and I had reached that limit. I could have more RAM, the behaviour would’ve been the same.
Speaking about sounds, a recent experience showed that you should free playing sounds on Mac. E.g. if you keep the sounds that are being played in an array, even when those have finished playing, your app will start to play next sounds scattered, more and more, until being catastrophic. Yet another limit on a process’ space.
And I know that. I just wanted to know if the problem was related to something about the rest of the process (quantity of play invocations + more something being done) and not to the quantity of resources (sounds) used.
If at some point, like 40, it stopped, your sample included in the report would need just one sound file. If with one sound file played 200 times emulating being 200, your app works ok, but with 200 it doesn’t, the issue may be tied to the contents and/or the quantity of those resources.
I suspect that when playing a sound, Xojo keeps the sound file in memory and never releases it.
Exactly the same as referencing a project image (open issue)
It might be better to open each sound by referencing the folderitem from the project’s resources.
I’ll change the project towards loading each file via referencing via filename. I’ll keep you informed, if it succeeds (or not )
Thank you for you tips so far!
Ok - here I’m back again - thank you all for your replies. Referencing via filename works.
Therefore the Sound Files have to be copied via “Build Settings > Build Step > Copy files” an NOT via Drag&Drop into the left column of the XOJO IDE.
Looking into the .apk-File in the res-folder, it seems to me that In case of Drag&Drop XOJO changes the filenames to something like AA.mp2 …