isoundplayer, looping sound leak t720 | developer.brewmp.com isoundplayer, looping sound leak t720 | developer.brewmp.com

Developer

isoundplayer, looping sound leak t720

Forums:

I was trying to loop a midi song while my application is running, creating theme music if you will. I've noticed that on the T720, this created a memory leak that running the same code on the VX4400 was not seen. In studying the API ref I see mention that:
"You need to issue a stop before you can call another ISOUNDPLAYER_Play()"
Is that true even during the registered soundplayer callback?

Basically, I set up my soundplayer with a callback registered and play a midi file. When the callback is invoked, I check to see if the status if AEE_SOUNDPLAYER_DONE. If so, I kick off the PLAY again. Do I need to put a stop in there before the play?

However in running on the T720 , after the song "loops" one time, if I exit my applet not all of the memory gets freed. If I exit the applet before the song reaches the end anc calls the registered callback, the memory is freed ok. On the vx4400, thing are fine in either case.

Any insight or pointer on using the SOUNDPLAYER are much appreciated.

Thanks.

After much mucking around, I got the best results by
stopping the playback (even though it was "done"), and
then restarting it. I wait a small amount of time between these
two actions, also, and that seemed to help.
The looping is not seemless, but its close enough for Jazz...
Sound seems to be one of the most inconsistently implemented APIs across the phones. If you search the archives here, you will find a number of work-arounds, though.
Good luck...
---jeff

After much mucking around, I got the best results by
stopping the playback (even though it was "done"), and
then restarting it. I wait a small amount of time between these
two actions, also, and that seemed to help.
The looping is not seemless, but its close enough for Jazz...
Sound seems to be one of the most inconsistently implemented APIs across the phones. If you search the archives here, you will find a number of work-arounds, though.
Good luck...
---jeff

you might want to try IRINGERMGR_PlayFile() (for a file) or IRINGERMGR_PlayEx() (for a stream), and give a value of 1 to the dwPause parameter, and see how well it "loops".. I have not used this personally, but it seems as though you dont have to deal with handling the looping yourself..
Of course this may be unstable on the device as well... If you try it, please post your results here.
-Tyndal

you might want to try IRINGERMGR_PlayFile() (for a file) or IRINGERMGR_PlayEx() (for a stream), and give a value of 1 to the dwPause parameter, and see how well it "loops".. I have not used this personally, but it seems as though you dont have to deal with handling the looping yourself..
Of course this may be unstable on the device as well... If you try it, please post your results here.
-Tyndal

I'm using ISOUNDPALYER on the t720 - as well as all other handsets - and I do not have any memory leaks, so I cannot confrim this problem. Maybe it's the way you use certain calls or something else in your program that is causing the leak.

I'm using ISOUNDPALYER on the t720 - as well as all other handsets - and I do not have any memory leaks, so I cannot confrim this problem. Maybe it's the way you use certain calls or something else in your program that is causing the leak.

You must call ISOUNDPLAYER_SetInfo(pISoundPlayer, NULL) before exiting the APP or before setting it to some other sound file...
In the manual you'll find this:
"Comments:
If pInfo is NULL, then a successful execution of this function causes ISoundPlayer to release
the memory (allocated by ISoundPlayer) for the previous audio source. It is app’s responsibility
to free the memory allocated for pData.
Side Effects:
If audio source is set successfully, then memory allocated (by ISoundPlayer) for previous
audio source is released. If input type is SDT_FILE, then ISoundPlayer copies the file name
from pData into its local buffer."
Though it says that setting it to a new sound the previous is released, I'd strongly recommend to SetInfo(..., NULL) before setting it to a new file given it doesn't release the memory in all the implementations (sanity action).
It'll solve the problem... in case the memomory leak problem is only related to the SOUNDPLAYER interface.
Rgds,

You must call ISOUNDPLAYER_SetInfo(pISoundPlayer, NULL) before exiting the APP or before setting it to some other sound file...
In the manual you'll find this:
"Comments:
If pInfo is NULL, then a successful execution of this function causes ISoundPlayer to release
the memory (allocated by ISoundPlayer) for the previous audio source. It is app’s responsibility
to free the memory allocated for pData.
Side Effects:
If audio source is set successfully, then memory allocated (by ISoundPlayer) for previous
audio source is released. If input type is SDT_FILE, then ISoundPlayer copies the file name
from pData into its local buffer."
Though it says that setting it to a new sound the previous is released, I'd strongly recommend to SetInfo(..., NULL) before setting it to a new file given it doesn't release the memory in all the implementations (sanity action).
It'll solve the problem... in case the memomory leak problem is only related to the SOUNDPLAYER interface.
Rgds,

I used to get a leak when I used ISOUNDPLAYER_Set() ... the leak went away when I switched over to ISOUNDPLAYER_SetInfo().
- Roshan

I used to get a leak when I used ISOUNDPLAYER_Set() ... the leak went away when I switched over to ISOUNDPLAYER_SetInfo().
- Roshan

Thanks for all the help, guys. I finally solved my problem by putting a delay between where the done notification is and re-playing the sound. Essentially, I moved the re-play out of the sound callback. This is related to some other observations that you cannot stop one track and immediately play another one. Well, it seems that you cannot stop a track and replay the same one either.
Thanks again.

Thanks for all the help, guys. I finally solved my problem by putting a delay between where the done notification is and re-playing the sound. Essentially, I moved the re-play out of the sound callback. This is related to some other observations that you cannot stop one track and immediately play another one. Well, it seems that you cannot stop a track and replay the same one either.
Thanks again.

That depends on the handset. Some of them are capable of restarting immediately, others, like the vx4400, need quite a delay in between, especially if you want to make sure there's no crackling etc.

That depends on the handset. Some of them are capable of restarting immediately, others, like the vx4400, need quite a delay in between, especially if you want to make sure there's no crackling etc.