Dynamically create ofSoundPlayer and destroy after playing (OpenAL)

advanced
#1

I’m getting really desperate. I already made a thread with the same background goal here: Issue with loading new sound into existing ofSoundPlayer object (RPi)

tldr; I want to load a list of audio files that changes based on the user but is fixed at app runtime.
I can NOT create and load a player object for each file, I have extremly limited RAM (Raspberry Pi) and the lenght of the file list is theoretically unlimited.

It seems there isn’t anyone who knows a solution to my old issue.
So I tried to create ofSoundPlayer object dynamically by using:

ofSoundPlayer* audio = new ofSoundPlayer();

and then pushing that object into a vector <ofSoundPlayer*> that I declared publicly in ofApp.h

audioPlayers.push_back(audio);

Then I load and play an audio file (all this happens in update()).

In draw() I check if its playing and if its done playing I advance by doing:

audioPlayers[0]->unloadSound();
delete audioPlayers[0];
audioPlayers.erase(audioPlayers.begin());

and then I try to do the same thing over again.

ofSoundPlayer* audio = new ofSoundPlayer();
audioPlayers.push_back(audio);

etc.
The issue is the same as in my other thread, I get a AL_INVALID_OPERATION on the second audio file and every other file coming after it and the if I come back to the first I get AL_INVALID_NAME. It also seems that unloadSound() has no effect when using pointers. Atleast in my old code I could get rid of AL_INVALID_NAME by using unloadSound() right before loading the file again.

How would you guys do this? I feel like this is a really common thing to do and I’m just doing it horribly wrong.
I really don’t care how its done in the end, just that it can be done.

#2

Couple of things to try:

  • does the same code work fine on your dev computer?
  • if you start off with 2 or 3 ofSoundPlayers, do they all work?
  • try shared_ptr instead of raw pointers. A vector of raw pointers can be pretty error prone when dealing with removal / cleanup
  • try a std::list instead of a std::vector. Lists are designed around arbitrarily adding and removing stuff from anywhere within the collection, and so are a little less error prone. A std::queue would also be a decent option since it sounds like you’re working with a queue of sound players anyway.
#3

Thanks! I will try this.
@2 Yes, if I just create a ofSoundPlayer for each audio file and never try to unload them everything works just fine.
@3 What exactly makes the difference between shared_ptr and ptr, do I have to use them in a different way?

#4

You use it pretty much the same way (as in with the -> operator and such). The difference is that it will handle cleaning up the object automatically when it gets removed from your vector/list/queue. So, you don’t have to call delete basically, though it also means you protect yourself from a whole genre of bugs in the process.

#5

I had to use a hotifx for now due to a tight deadline and just launch an cli mp3 player but I would like to continue on this soon as the app will be re-used a lot and the cli player solution is absolute crap.
What irritated me very much was how much RAM(~280MB) is being used by the app when a music piece was loaded. See this GitHub issue for more details: https://github.com/openframeworks/openFrameworks/issues/3288

Maybe that is causing the issues I had so far, I have only about 28MB free RAM left.