[SOLVED]Audio stops after a few hundred consecutive calls

[Antidote]

I've been stress testing my engine for a few hours now and have about 1000 entities in one map that call the same sound when they are collided with by the player, after calling this sound about 400 to 500 times the whole sound backend dies with no error, just no sound, period.

Any ideas?

EDIT:
I know that this is a pretty extreme corner case, but I CAN see where this could become an issue down the line.

[Laurent]

There's a maximum number of sounds (probably 512 on your machine), and if you don't properly release or reuse finished sounds then you won't be able to create new sounds once you reach this number.

[Antidote]

Really? That makes sense, I'll modify my code to ensure it gets deleted, for some reason I was under the impression that SFML's resource manager handled that and using delete was a no no.

I'll just change it to a reference and have it free itself when it goes out of scope.

[Laurent]

for some reason I was under the impression that SFML's resource manager handled that and using delete was a no no

There's no resource manager in SFML. And if you don't release your resources, SFML cannot magically do it for you

[Antidote]

Ah so you're right, that's what i get for reading the source at 2AM XD
Anyway, thanks for the help. That was indeed the problem.

[Nexus]

If you're using new -- or even worse, new[] -- then stop using it. Manual memory management is error-prone, replace it with RAII.

Simply take a STL container such as std::vector. To store sounds, a std::queue is quite useful, as you can pop the front elements as long as they've finished playing.

[Antidote]

For my purposes RAII isn't the answer, otherwise I would use it.

[Daddi]

Could you show us these purposes? I'm interested in cases where RAII can't or shouldn't be used

[Antidote]

Implementing RAII in C isn't exactly the easiest thing to do ;P

I'm also attempting to port sfml-audio to wii using libogc, with moderate success, sfml-system still has a long way to go, and sfml-window is non-existent right now.

[Nexus]

Next time, tell us you're using C from the beginning

For C, there are also libraries for containers and data structures, even if they're more cumbersome to use than in C++. I don't know if those dependencies are okay for your project, but they might be interesting nevertheless.

[Antidote]

It all depends on the memory footprint. But usually containers on the Wii aren't a bad idea so I'll definitely look into it.

The nice thing about libogc, is that it implements semaphores in the threading module, which will makes things a little less painful.