Tips for aviding ISoundPlayer crashes | developer.brewmp.com Tips for aviding ISoundPlayer crashes | developer.brewmp.com

Developer

Tips for aviding ISoundPlayer crashes

Forums:

Hi,

I had a weird problem with the ISoundPlayer on the T720, which I eventually fixed after 2 days. I'm still not sure what the problem is...maybe if some of you have experienced the same thing, you could throw some light on this.

I am developing a game in which a background music is continuously playing. When a plane crashes, I have to stop this sound and play a crash sound. After the crash sound has finished playing, I restart the background sound. What was happening was that during the crash sequence, if I continuously pressed a key, the phone weould reset. I noticed that the reset was happening just as I was trying to restart the background music.

In my soundplayer callbacks(by ISOUNDPLAYER_RegisterNotify), I was setting a variable to indicate that the sound had successfully stopped. In my timer I was checking this variable and playing(ISOUNDPLAYER_SetInfo and ISOUNDPLAYER_Play) the appropriate sound according to the situation. This could be playing the background sound if the sound had finished playing once, starting the crash sound if a crash had occurred and the background sound had successfully stopped or restarting the background sound if the crash sequence was over. I was also explicitly stopping the crash sound in my game loop once I calculated that the crash sequence was over rather than let the crash sound run to its completion(since the crash sound was not too big anyway). Now, I detected that the phone was resetting when I called ISOUNDPLAYER_SetInfo to set the sound to the background sound. Later I detected that the phone would reset at any ISOUNDPLAYER_* function after a call to ISOUNDPLAYER_Stop on the crash sound. The sequence of events was as follows:
Enter Timer callback
detect plane crash
ISoundPlayer_Stop
do stuff
Leaving Timer callback
Enter SoundPlayer Callback
sound successfully stopped
set variable
Leaving SoundPlayer Callback
Enter Timer callback
ISoundPlayer_SetInfo(crash sound)
ISoundPlayer_Play
Leaving Timer callback
Enter Timer callback
detect end of crash sequence
ISoundPlayer_Stop
do stuff
Leaving Timer callback
Entered SoundPlayer Callback
sound successfully stopped
set variable
Leaving SoundPlayer Callback
Enter Timer callback
ISoundPlayer_SetInfo(background music) // phone resets here or on
// any other ISoundPlayer_* method
ISoundPlayer_Play
Leaving Timer callback

Also, note that this would happen only if keys were continuously pressed during this instant.

So, I assumed that it was a watchdog problem probably because of the number of sound callbacks and key events. Finally after trying out everything for 2 days I somehow arrived upon a solution that worked.

I decided not to register a callback for the crash sound. Further, I decided not to call ISOUNDPLAYER_Stop oon the crash sound. I now detect if the crash sound has run to its completion by checking
ISOUNDPLAYER_GetInfo(m_sndPlayer, NULL) == EIDLE
For whatever reason, this worked.

A couple of other points:
This problem occurred for both SDT_FILE and SDT_BUFFER
The crash sound was very small(160 bytes), while the background music was quite huge(13KB). I will try to reduce the size of the background music.

Anyway, I'm glad that it worked. I guess that days like this make programming such a worthwhile task...days of struggle followed by sweet success :-)

Regards,
Roshan

roshweb, your post helped me out a lot. Thanks.
I'm still fighting this one but I've made some progress. Initially my symptoms were almost identical to the ones you've described, but I've managed to mostly get it working without abandoning ISOUNDPLAYER_RegisterNotify().
For clarity, I'm leaving ISOUNDPLAYER_ and AEE_SOUNDPLAYER off of my identifiers for the rest of this post.
Since I don't yet have a completely clean solution, so here's just a few of my working hypotheses.
- The phone reset is related to the watchdog. Even when I'm totally thrashing the ISoundPlayer and trying to call SetInfo() too early and so forth, the phone doesn't actually reset unless I'm also DBGPRINTF-ing every event and API return value.
- When you call Stop(), most phones like to send your callback (STATUS_CB, SUCCESS) then, later, (PLAY_CB, DONE). The T720 likes to send you (PLAY_CB, ABORTED) then later (STATUS_CB, SUCCESS). You need to wait until the latter of these pairs to post your user event to start your next sound.
- If you call SetInfo(), etc., too soon after Stop(), or call Stop() too soon after Stop(), the T720 is vulnerable to reporting (STATUS_CB, FAILURE). Once this happens you're hosed. Even releasing the ISoundPlayer interface and reacquiring it later it won't play any more sounds.
I'm not 100% sure about all of this but it is coming together for me. Does this "ring any bells" for anybody?
-Jesse

roshweb, your post helped me out a lot. Thanks.
I'm still fighting this one but I've made some progress. Initially my symptoms were almost identical to the ones you've described, but I've managed to mostly get it working without abandoning ISOUNDPLAYER_RegisterNotify().
For clarity, I'm leaving ISOUNDPLAYER_ and AEE_SOUNDPLAYER off of my identifiers for the rest of this post.
Since I don't yet have a completely clean solution, so here's just a few of my working hypotheses.
- The phone reset is related to the watchdog. Even when I'm totally thrashing the ISoundPlayer and trying to call SetInfo() too early and so forth, the phone doesn't actually reset unless I'm also DBGPRINTF-ing every event and API return value.
- When you call Stop(), most phones like to send your callback (STATUS_CB, SUCCESS) then, later, (PLAY_CB, DONE). The T720 likes to send you (PLAY_CB, ABORTED) then later (STATUS_CB, SUCCESS). You need to wait until the latter of these pairs to post your user event to start your next sound.
- If you call SetInfo(), etc., too soon after Stop(), or call Stop() too soon after Stop(), the T720 is vulnerable to reporting (STATUS_CB, FAILURE). Once this happens you're hosed. Even releasing the ISoundPlayer interface and reacquiring it later it won't play any more sounds.
I'm not 100% sure about all of this but it is coming together for me. Does this "ring any bells" for anybody?
-Jesse

OK, my mistake. You *can* recover from AEE_SOUNDPLAYER_STATUS_CB/AEE_SOUNDPLAYER_FAILURE. When I reacquired the ISoundPlayer interface I was forgetting to reregister my notification callback.
When you get STATUS_CB/FAILURE you want to immdiately release the ISoundPlayer interface and post yourself a special-purpose event (to get out of the callback). The phones don't seem to mind releasing the interface from within the callback, but you need to make sure you don't call anything else on the interface. The phones don't like reacquiring the interface from the callback. When your special-purpose event comes in you reacquire the ISoundPlayer *and* reregister your notification callback, and you're set.
-Jesse

OK, my mistake. You *can* recover from AEE_SOUNDPLAYER_STATUS_CB/AEE_SOUNDPLAYER_FAILURE. When I reacquired the ISoundPlayer interface I was forgetting to reregister my notification callback.
When you get STATUS_CB/FAILURE you want to immdiately release the ISoundPlayer interface and post yourself a special-purpose event (to get out of the callback). The phones don't seem to mind releasing the interface from within the callback, but you need to make sure you don't call anything else on the interface. The phones don't like reacquiring the interface from the callback. When your special-purpose event comes in you reacquire the ISoundPlayer *and* reregister your notification callback, and you're set.
-Jesse

I'm starting to get sound crashes on my new T720 app--this new game is slightly more sound intensive than my previous one. So I'm getting a seemingly random crash when playing sounds after other sounds. Usually related to pressing a key at the same time--as previously described in this thread.
Ok so basically you always have a nofitication callback on your sound interface? (I usually only used one for looping sounds)
And what you're saying is that if your notification callback gets a STATUS_CB or FAILURE message then any subsequent calls to SetInfo or Stop will hang/watchdog the phone?
So the solution is to release the interface in a status_cb/failuire situation and then reacquire it in another event...and everything will be keen--eh?
Has any new info come to light about this particular T720 bug?

I'm starting to get sound crashes on my new T720 app--this new game is slightly more sound intensive than my previous one. So I'm getting a seemingly random crash when playing sounds after other sounds. Usually related to pressing a key at the same time--as previously described in this thread.
Ok so basically you always have a nofitication callback on your sound interface? (I usually only used one for looping sounds)
And what you're saying is that if your notification callback gets a STATUS_CB or FAILURE message then any subsequent calls to SetInfo or Stop will hang/watchdog the phone?
So the solution is to release the interface in a status_cb/failuire situation and then reacquire it in another event...and everything will be keen--eh?
Has any new info come to light about this particular T720 bug?

Quote:Originally posted by flarb
I'm starting to get sound crashes on my new T720 app--this new game is slightly more sound intensive than my previous one. So I'm getting a seemingly random crash when playing sounds after other sounds. Usually related to pressing a key at the same time--as previously described in this thread.
Ok so basically you always have a nofitication callback on your sound interface? (I usually only used one for looping sounds)
What I am doing now, is having 3 states for the sound system - wait, free and busy. When a sound has started, the status is set to busy... in the callback when i detect the sound has stopped (could because i called stop or the sound has succesfully run to completion), i set the status to wait.
All my sounds are played from within my timer callback. In my timer callback, I play a sound only if the status is free... if the status is wait, i set it to free so that, the sound to be played will be played in the next timer cycle... this is just to add some delay between calls to _Play. Further, before playing, I check that ISOUNDPLAYER_GetInfo returns EIDLE. Also, if the sounds are very small, I dont set a callback for them and dont call stop on them. Rather, I let them run to it's completion.
Doing this seems to work for me. I am not sure whether all of these steps are actually necessary, but I have left them in any way as they dont seem to do much harm.
Quote:
Has any new info come to light about this particular T720 bug? Also, you will have to release the ISoundPlayer interface on Suspend and reacquire it in resume. See this: http://brewforums.qualcomm.com/showthread.php?s=&threadid=1414&highlight...
Regards,
Roshan

Quote:Originally posted by flarb
I'm starting to get sound crashes on my new T720 app--this new game is slightly more sound intensive than my previous one. So I'm getting a seemingly random crash when playing sounds after other sounds. Usually related to pressing a key at the same time--as previously described in this thread.
Ok so basically you always have a nofitication callback on your sound interface? (I usually only used one for looping sounds)
What I am doing now, is having 3 states for the sound system - wait, free and busy. When a sound has started, the status is set to busy... in the callback when i detect the sound has stopped (could because i called stop or the sound has succesfully run to completion), i set the status to wait.
All my sounds are played from within my timer callback. In my timer callback, I play a sound only if the status is free... if the status is wait, i set it to free so that, the sound to be played will be played in the next timer cycle... this is just to add some delay between calls to _Play. Further, before playing, I check that ISOUNDPLAYER_GetInfo returns EIDLE. Also, if the sounds are very small, I dont set a callback for them and dont call stop on them. Rather, I let them run to it's completion.
Doing this seems to work for me. I am not sure whether all of these steps are actually necessary, but I have left them in any way as they dont seem to do much harm.
Quote:
Has any new info come to light about this particular T720 bug? Also, you will have to release the ISoundPlayer interface on Suspend and reacquire it in resume. See this: http://brewforums.qualcomm.com/showthread.php?s=&threadid=1414&highlight...
Regards,
Roshan

Quote:Originally posted by flarb
I'm starting to get sound crashes on my new T720 app--this new game is slightly more sound intensive than my previous one. So I'm getting a seemingly random crash when playing sounds after other sounds. Usually related to pressing a key at the same time--as previously described in this thread.
Ok so basically you always have a nofitication callback on your sound interface? (I usually only used one for looping sounds)
My sound-intensive app had the same buggy behavior, so I always have a notification callback. I think the only way you can avoid having a callback is if you always only play one sound to completion, then (maybe) play another: and even this can have better latency if you're using a callback.
Quote:
And what you're saying is that if your notification callback gets a STATUS_CB or FAILURE message then any subsequent calls to SetInfo or Stop will hang/watchdog the phone?
Yes.
Quote:
So the solution is to release the interface in a status_cb/failuire situation and then reacquire it in another event...and everything will be keen--eh?
That's what I arrived at and it worked. There may be a more elegant solution, but considering that the ISoundPlayer interface (at least on the T720) isn't reentrance-safe, I doubt it.
-Jesse

Quote:Originally posted by flarb
I'm starting to get sound crashes on my new T720 app--this new game is slightly more sound intensive than my previous one. So I'm getting a seemingly random crash when playing sounds after other sounds. Usually related to pressing a key at the same time--as previously described in this thread.
Ok so basically you always have a nofitication callback on your sound interface? (I usually only used one for looping sounds)
My sound-intensive app had the same buggy behavior, so I always have a notification callback. I think the only way you can avoid having a callback is if you always only play one sound to completion, then (maybe) play another: and even this can have better latency if you're using a callback.
Quote:
And what you're saying is that if your notification callback gets a STATUS_CB or FAILURE message then any subsequent calls to SetInfo or Stop will hang/watchdog the phone?
Yes.
Quote:
So the solution is to release the interface in a status_cb/failuire situation and then reacquire it in another event...and everything will be keen--eh?
That's what I arrived at and it worked. There may be a more elegant solution, but considering that the ISoundPlayer interface (at least on the T720) isn't reentrance-safe, I doubt it.
-Jesse

I've noticed that I get this AEE_SOUNDPLAYER_FAILURE message if I try to stop playing music when nothing is currently playing. I've got a lot of calls to Stop() that may not necessarily be called when something is playing.
Can I safely ignore these messages--assuming that the failure message when I'm trying to PLAY a tune is the one I want to destroy and recreate the sound interface on?

I've noticed that I get this AEE_SOUNDPLAYER_FAILURE message if I try to stop playing music when nothing is currently playing. I've got a lot of calls to Stop() that may not necessarily be called when something is playing.
Can I safely ignore these messages--assuming that the failure message when I'm trying to PLAY a tune is the one I want to destroy and recreate the sound interface on?

I haven't tried that; I don't know.

I haven't tried that; I don't know.

Seems to work ok so far. (*fingers crossed*) :)
I just disable the callback before all calls to stop and then reenable them after.

Seems to work ok so far. (*fingers crossed*) :)
I just disable the callback before all calls to stop and then reenable them after.

I have found that
ISOUNDPLAYER_GetInfo() does not work on the actual handsets. It always returns true once a sound has been started. So your code (and mine) will think the sound is always busy and must stop the sound before playing any additional sound.
My question is there any way to tell if the sound is really finished so I do not waste time stopping already completed sounds?

I have found that
ISOUNDPLAYER_GetInfo() does not work on the actual handsets. It always returns true once a sound has been started. So your code (and mine) will think the sound is always busy and must stop the sound before playing any additional sound.
My question is there any way to tell if the sound is really finished so I do not waste time stopping already completed sounds?

jhw wrote:
- If you call SetInfo(), etc., too soon after Stop(), or call Stop() too soon after Stop(), the T720 is vulnerable to reporting (STATUS_CB, FAILURE). Once this happens you're hosed. Even releasing the ISoundPlayer interface and reacquiring it later it won't play any more sounds.
I'm not 100% sure about all of this but it is coming together for me. Does this "ring any bells" for anybody?
Oh yeah... this is definitely looking to be an issue. The first symptom we noticed with an app was that upon quitting it, we're unable to load _any_ BREW apps on the T720.
Upon further experimenting, I noticed that sometimes sounds would completely stop working in my app. Then I noticed that the "can't load BREW apps" issue only seemed to happen when the sound died in my app.
So, ISOUNDPLAYER on the T720 is definitely wonky, and I'm going to have to rethink my brilliant sound management code. ;)
-bill!

jhw wrote:
- If you call SetInfo(), etc., too soon after Stop(), or call Stop() too soon after Stop(), the T720 is vulnerable to reporting (STATUS_CB, FAILURE). Once this happens you're hosed. Even releasing the ISoundPlayer interface and reacquiring it later it won't play any more sounds.
I'm not 100% sure about all of this but it is coming together for me. Does this "ring any bells" for anybody?
Oh yeah... this is definitely looking to be an issue. The first symptom we noticed with an app was that upon quitting it, we're unable to load _any_ BREW apps on the T720.
Upon further experimenting, I noticed that sometimes sounds would completely stop working in my app. Then I noticed that the "can't load BREW apps" issue only seemed to happen when the sound died in my app.
So, ISOUNDPLAYER on the T720 is definitely wonky, and I'm going to have to rethink my brilliant sound management code. ;)
-bill!