[SOLVED] isPlaying() returning false negative

shenjoku

05-01-2014 22:28:49

When calling isPlaying() on a streaming sound it will sometimes return false even though the sound is still playing. This is due to how streaming works in that it stops the sound temporarily when buffering in _updateAudioBuffers(). If you're using the multi-threaded functionality then it is possible call isPlaying() while it is temporarily stopped, which return false when it should still be true. isPlaying() needs be changed to work similarly to isStopped(), in that is needs to check the value of the mPlay flag in the return value at line 551. Currently it is:
return (state == AL_PLAYING);

And it should be:
return mPlay || (state == AL_PLAYING);

You can work around this problem by doing something like the following (to get something equivalent to checking isPlaying() == true):
if (mSound->isStopped() || mSound->getSource() == AL_NONE)

But this is pretty ugly to have to do.

stickymango

06-01-2014 17:20:51

Fixed in latest SVN.

shenjoku

06-01-2014 22:16:28

Just tested this and realized the fix doesn't work. Since I stopped using pause() due to the stuttering issues I didn't realize the mPlay flag is stil true when the sound is paused, so isPlaying() will still return true while paused. Is mPlay supposed to be true when the sound is paused? Should it be set to false? I guess I'm not 100% sure what the meaning of the flag is.

EDIT: Looked into it a bit more and I think I understand now. mPlay is set to true when playing the sound and turned off only when stopped. From what I can tell, this is to prevent isStopped() from returning true while paused. I assume this is because the source state is getting set to stopped while paused for some reason, although I'm not entirely sure when this would happen other than something to do with streaming maybe. So my proposed fix for checking mPlay is isPlaying() isn't going to work unless mPlay can be set to false when pausing a sound.

stickymango

06-01-2014 22:50:59

Hmmm, yes, there are a few caveats where this flag might cause problems, mainly where streaming sounds have been disabled due to missing an update, where the buffer runs out of data before being repopulated, or when the sound is kicked off the active list because the number of simultaneous sounds has been exceeded or the sounds distance is far away, both scenarios are transparent to the user which is why I decided it should report true even though behind the scenes its actually false. I think the whole sound state issue needs a rethink. :?

Maybe the mPlay flag needs to be an enum instead...

shenjoku

07-01-2014 01:44:21

Maybe the mPlay flag needs to be an enum instead...

So each sound would maintain its own state separate of what OpenAL thinks it's doing? Seems exactly like what is needed.

shenjoku

08-01-2014 02:47:32

Spent a little time and implemented a simple enum state system. Here's a patch with the changes. As far as I can tell this seems to all be working but feel free to change it however you need.

Hate to double post but I don't know if you'll see this otherwise.

stickymango

08-01-2014 11:27:36

Hi Shenjoku,

Thanks for all your work on this, haven't had time to really look into all the issues which is why my quick hack together resulted in more errors :roll:

Hopefully I'll get a bit of time this evening to have a look through and make the necessary changes, thanks for all the patches so far they've been very helpful! :)

shenjoku

08-01-2014 19:11:51

No problem :) We're working rather rapidly trying to get this game put together so I have to make this stuff work one way or another. Just par for the course I suppose haha.

stickymango

08-01-2014 23:05:08

Do post details when you can, thanks for using the lib and improving it!! :)

shenjoku

09-01-2014 00:27:20

This bug seems to be all fixed. As far as I can tell it's working.

stickymango

09-01-2014 09:58:04

Excellent.