Playback of more than 40 sound files in succession seems not to work

I am working on an App for Android that contains about 200+ sound files that are stored in an array mySound(0)…mySound(200).

mySound(0).Play - works
mySound(1).Play - works

mySound(40).Play - works

But at some point, around call 40:
mySound(41).Play - does not work, sound won’t be played
mySound(42).Play - does not work, sound won’t be played

e.g. mySound(40).Play - works for any sound (0…40) that has been played beforehand.

Incidentally, the order in which the sounds are called up is irrelevant.
Does anyone have any idea what the problem could be?

All loaded, then played… ?

Can’t you “load + play + release” them one at a time ?

Hi Emile,

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” ?

Open an Issue report and include a sample project zip with it.

Having just one mp3 file reused in 200 slots of the array causes the stop at the 40th?

If yes, this may be a simple and small sample.

I guess each sound leaks memory until there’s no more available.

Hi Rick, there are 200+ different sound files - not only one to be played many times

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?

By release, I meant .Close the reference of the loaded file.

But you add interesting information in your last statement (1 minute ago): you wan to play more than 40 sound at the same time.

Try to do that with a Desktop project (it will work if this is not a memory constraint)… you already have the code to do that.

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 :wink:

What I do not know is if doing so, the sounds are loaded into memory, then played (loaded into memory a second time).

How many memory (RAM) your computer have ?

Are-you sure you can do that in an Andoid machine ?

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 :wink: )
Thank you for you tips so far!

1 Like

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 …

1 Like