Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Documentation here,

http://www.qualcomm.com/brew/developer/resources/ds/kb/51.html

say to reset sound info when resuming.

I am using ISOUNDPLAYER. When I do this for ISOUNDPLAYER
in resume, as in:

int iSet = ISOUNDPLAYER_SetInfo(pMe->m_pISound, &pMe->m_spInfo);

I get an error, ISOUNDPLAYER Item Busy .

Now in suspend, I did this:

ISOUNDPLAYER_GetInfo(pMe->m_pISound, &pMe->m_spInfo);
ISOUNDPLAYER_Stop(pMe->m_pISound);
ISOUNDPLAYER_RegisterNotify(pMe->m_pISound, NULL, pMe);

although I dont really think I need to do a
get info, since I only use one setting.

Does the above web reference not apply when using
ISOUNDPLAYER ??

All you need to do upon receiving EVT_APP_SUSPEND is call ISOUNDPLAYER_Stop( pMe->m_pSoundPlayer ). There is no need to de-register and then re-register your SoundPlayer while the app is suspended, at least not that I have discovered.

All you need to do upon receiving EVT_APP_SUSPEND is call ISOUNDPLAYER_Stop( pMe->m_pSoundPlayer ). There is no need to de-register and then re-register your SoundPlayer while the app is suspended, at least not that I have discovered.

Here's what I do for resume and suspend. Very simple, really... and it works like a charm while also making sure the music continues exactly where it had left off before the suspend event.
void
SoundSuspend( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Pause( curApp->Sound );
}

void
SoundResume( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Resume( curApp->Sound );
}

Here's what I do for resume and suspend. Very simple, really... and it works like a charm while also making sure the music continues exactly where it had left off before the suspend event.
void
SoundSuspend( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Pause( curApp->Sound );
}

void
SoundResume( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Resume( curApp->Sound );
}

Quote:Originally posted by Dragon
Here's what I do for resume and suspend. Very simple, really... and it works like a charm while also making sure the music continues exactly where it had left off before the suspend event.
void
SoundSuspend( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Pause( curApp->Sound );
}

void
SoundResume( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Resume( curApp->Sound );
}

I am not having any performance problems, I am just
trying to do what the guidelines say for passing true brew.
Have you done the above (only) and passed?
thx

Quote:Originally posted by Dragon
Here's what I do for resume and suspend. Very simple, really... and it works like a charm while also making sure the music continues exactly where it had left off before the suspend event.
void
SoundSuspend( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Pause( curApp->Sound );
}

void
SoundResume( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Resume( curApp->Sound );
}

I am not having any performance problems, I am just
trying to do what the guidelines say for passing true brew.
Have you done the above (only) and passed?
thx

I don´t think pause works for all files, only for midi, don´t remember for sure, but that´s in the api doc

I don´t think pause works for all files, only for midi, don´t remember for sure, but that´s in the api doc

Well, MIDI is all I'm using so it's working fine for me. Also, if I remember correctly, you don't have to do anything, actually because Suspend puts the soundplayer on hold automatically and I just inserted these commands as a safety-net.

Well, MIDI is all I'm using so it's working fine for me. Also, if I remember correctly, you don't have to do anything, actually because Suspend puts the soundplayer on hold automatically and I just inserted these commands as a safety-net.

Well it seems that calling ISOUNDPLAYER_Stop in suspend
will eventually cause the T720 to reboot itself.
It took my a while to narrow it down, but thats the line
that is definately doing it.
To recreate, I had to suspend numerous times in the middle
of playing sounds.
Luckily, its fairly easy to test suspend/resume on the T720.
I will try the pause, and see if that is safe...
====update 2=====
Yup, thats the ticket..pause causes no problems.

Well it seems that calling ISOUNDPLAYER_Stop in suspend
will eventually cause the T720 to reboot itself.
It took my a while to narrow it down, but thats the line
that is definately doing it.
To recreate, I had to suspend numerous times in the middle
of playing sounds.
Luckily, its fairly easy to test suspend/resume on the T720.
I will try the pause, and see if that is safe...
====update 2=====
Yup, thats the ticket..pause causes no problems.

After much more testing, it appears that ISoundPlayer is
just not stable in suspend and resume situations.
Even trying just the ISSOUNDPLAYER_Pause and
ISOUNDPLAYER_resume can cause lockups,
and cause future ISOUNDPLAYER_SetInfo calls to fail.
The scenario goes like this:
Just after a call to ISOUNDPLAYER_Play, but before any
sound actually gets played, suspend the app with a phone
call. (You cannot do this with the ringer or it will not fail).
It takes a bit of perseverence to have the suspend happen right after the Play call --- but when it does, upon resuming, any
attempt by the app to do ANYTHING with ISoundPlayer will fail with a EITEMBUSY error code.
The problem is, at that point, there
is no way to get it to be Not busy. All future attempts
to use the sound interface will fail, and when you exit the
app you will be unable to re-enter the app.
Occasionally I will see a AEE_SOUNDPLAYER_ABORTED
message from the callback, but that is not required
to duplicate the problem. I cannot duplicate it on the
emulator.
My guess is that something is getting messed up with
ISOUNDINFO's data buffers because the buffer is queued
but never begins to play.
I should mention that my sounds are all very short, so Pause
and resume isn't really needed.
I've tried quite a few options including saving and
restoring the sound info, pause and resume, stop (stop is
the worst and will fail even when testing it with the ringer),
doing nothing, saving and restoring the callback. And all
manner and number of combinations of the aformentioned.
The only thing I have not been able to try is to somehow
wait until the sound is finished playing to yield under the
suspend message. Unfortunately, I don't see a way to do this.
Even a timer would require me to keep processing messages
and at that point the suspend is allready in effect.
Any ideas would be appreciated as, at this point, I am tempted
to just remove the sound completely.

After much more testing, it appears that ISoundPlayer is
just not stable in suspend and resume situations.
Even trying just the ISSOUNDPLAYER_Pause and
ISOUNDPLAYER_resume can cause lockups,
and cause future ISOUNDPLAYER_SetInfo calls to fail.
The scenario goes like this:
Just after a call to ISOUNDPLAYER_Play, but before any
sound actually gets played, suspend the app with a phone
call. (You cannot do this with the ringer or it will not fail).
It takes a bit of perseverence to have the suspend happen right after the Play call --- but when it does, upon resuming, any
attempt by the app to do ANYTHING with ISoundPlayer will fail with a EITEMBUSY error code.
The problem is, at that point, there
is no way to get it to be Not busy. All future attempts
to use the sound interface will fail, and when you exit the
app you will be unable to re-enter the app.
Occasionally I will see a AEE_SOUNDPLAYER_ABORTED
message from the callback, but that is not required
to duplicate the problem. I cannot duplicate it on the
emulator.
My guess is that something is getting messed up with
ISOUNDINFO's data buffers because the buffer is queued
but never begins to play.
I should mention that my sounds are all very short, so Pause
and resume isn't really needed.
I've tried quite a few options including saving and
restoring the sound info, pause and resume, stop (stop is
the worst and will fail even when testing it with the ringer),
doing nothing, saving and restoring the callback. And all
manner and number of combinations of the aformentioned.
The only thing I have not been able to try is to somehow
wait until the sound is finished playing to yield under the
suspend message. Unfortunately, I don't see a way to do this.
Even a timer would require me to keep processing messages
and at that point the suspend is allready in effect.
Any ideas would be appreciated as, at this point, I am tempted
to just remove the sound completely.

I am trying ISOUNDPLAYER_Pause( pMe->m_pISoundPlayer );/ISOUNDPLAYER_Resume() on Motorola T720 with brew 1.1. It does not seem to work on the handset. FYI I am using midi files.

I am trying ISOUNDPLAYER_Pause( pMe->m_pISoundPlayer );/ISOUNDPLAYER_Resume() on Motorola T720 with brew 1.1. It does not seem to work on the handset. FYI I am using midi files.

It worked fine for me on that handset and all others that I have encountered so far, using the code I posted above. Strange that it wouldn't work on yours...

It worked fine for me on that handset and all others that I have encountered so far, using the code I posted above. Strange that it wouldn't work on yours...

Quote:Originally posted by Dragon
It worked fine for me on that handset and all others that I have encountered so far, using the code I posted above. Strange that it wouldn't work on yours...
The bug is really hard to duplicate. We went ahead and released the interface and then re-acquired it when resuming --- and that worked fine. We passed.

Quote:Originally posted by Dragon
It worked fine for me on that handset and all others that I have encountered so far, using the code I posted above. Strange that it wouldn't work on yours...
The bug is really hard to duplicate. We went ahead and released the interface and then re-acquired it when resuming --- and that worked fine. We passed.

Can you tell me the detail?
I alse released the interface but the sound still be played!!!

Can you tell me the detail?
I alse released the interface but the sound still be played!!!

regit wrote:Can you tell me the detail?
I alse released the interface but the sound still be played!!!
Releasing the interfae is not the way to stop the sound.
Go ahead and stop it normally. I chose to release the interface
also, and then reacquire it because there is a timing bug with
suspend resume (as described above).

regit wrote:Can you tell me the detail?
I alse released the interface but the sound still be played!!!
Releasing the interfae is not the way to stop the sound.
Go ahead and stop it normally. I chose to release the interface
also, and then reacquire it because there is a timing bug with
suspend resume (as described above).

I found with my first game on the T720 that the ISoundPlayer would sometimes die--and would lead to crashes.
What I did to fix it was to monitor the status callback for:
if (eCBType == AEE_SOUNDPLAYER_STATUS_CB &&
eSPStatus == AEE_SOUNDPLAYER_FAILURE)
and release the ISoundPlayer immediately (within the callback) if that occured.
The Release in this case consists of:
ISOUNDPLAYER_RegisterNotify(pPlayer, NULL, NULL );
ISOUNDPLAYER_SetInfo(pPlayer, NULL );
ISOUNDPLAYER_Release(pPlayer);
This solved all of the crashes and sound dropouts that I had on the T720.
Also, the VX6000 had some problems where the soundplayer would just go to sleep. My fix for that was to monitor the Status callback for the 1-second heartbeat and basically do a 3-second watchdog timer in my main code. If the heartbeat hadn't happened in 3 seconds, I'd kill the SoundPlayer (as above) and recreate it...

I found with my first game on the T720 that the ISoundPlayer would sometimes die--and would lead to crashes.
What I did to fix it was to monitor the status callback for:
if (eCBType == AEE_SOUNDPLAYER_STATUS_CB &&
eSPStatus == AEE_SOUNDPLAYER_FAILURE)
and release the ISoundPlayer immediately (within the callback) if that occured.
The Release in this case consists of:
ISOUNDPLAYER_RegisterNotify(pPlayer, NULL, NULL );
ISOUNDPLAYER_SetInfo(pPlayer, NULL );
ISOUNDPLAYER_Release(pPlayer);
This solved all of the crashes and sound dropouts that I had on the T720.
Also, the VX6000 had some problems where the soundplayer would just go to sleep. My fix for that was to monitor the Status callback for the 1-second heartbeat and basically do a 3-second watchdog timer in my main code. If the heartbeat hadn't happened in 3 seconds, I'd kill the SoundPlayer (as above) and recreate it...