Samsung SCH A650: Sound Midi Problem | developer.brewmp.com Samsung SCH A650: Sound Midi Problem | developer.brewmp.com

Developer

Samsung SCH A650: Sound Midi Problem

Forums:

Here is what we believe is a hardware problem on the Samsung SCH A650.

If the user press the volume button all the way down to the no volume/mute level. This causes the internal sound system to pause the music playing, BUT not stop the internal timer. So when the user increases the volume, the midi will play at high speed until it reaches that place it should have been had it not been paused. As far as I can tell this is a hardware issue.

We just ran into a problem on the a650 as well, which caused our app to fail TBT. Here's what's reportedly happening...
Error #1: Upon receiving an incoming voice call, while in the application, the handset will play the application's background music instead of the OEM's ringtone. (Test Case 3.4.14.1)
Steps to reproduce the error:
1. Audit ring-tone at OEM level.
2. Start the application. Note, sound must be "ON" under "Options" menu.
Call handset and note ring-tone. Application fails to use correct OEM ring-tone.
Can anyone comment on this? Did anyone see this before? I'm not even touching the phone's ringtones. All my MIDI playback is using the ISOUNDPLAYER interface only and yet, it seems to have this weird behavior.

We just ran into a problem on the a650 as well, which caused our app to fail TBT. Here's what's reportedly happening...
Error #1: Upon receiving an incoming voice call, while in the application, the handset will play the application's background music instead of the OEM's ringtone. (Test Case 3.4.14.1)
Steps to reproduce the error:
1. Audit ring-tone at OEM level.
2. Start the application. Note, sound must be "ON" under "Options" menu.
Call handset and note ring-tone. Application fails to use correct OEM ring-tone.
Can anyone comment on this? Did anyone see this before? I'm not even touching the phone's ringtones. All my MIDI playback is using the ISOUNDPLAYER interface only and yet, it seems to have this weird behavior.

Hi, Dragon,
I found that your code piece for playing sound has something wrong, look at your code for suspend sound:
// SoundSuspend
//--------------------------------------
// When an external call comes in we
// need to suspend the sound player.
//
void
SoundSuspend( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Stop( curApp->Sound );
}

when you stop the sound in your SoundLoopCallback, your callbak will receives a AEE_SOUNDPLAYER_DONE, AND SOUND WILL RESTART, see your code,
void
SoundLoopCallback( void *userData, AEESoundCmd cmd, AEESoundStatus status, uint32 para )
{
applet *curApp = (applet *)userData;
para = 0; // Just to avoid a WARNING C4100, unreferenced parameter
Assert( NULL != userData ); // Make sure we have a valid callback here
if ( AEE_SOUNDPLAYER_PLAY_CB == cmd )
{
if ( AEE_SOUNDPLAYER_DONE == status ) // If the sound is finished,
{
ISOUNDPLAYER_Stop( curApp->Sound ); // simply restart it
// Create a really short timer that will then
// trigger a restart of the MIDI track.
//
// Sadly we can't just STOP and START them - another BREW glitch. :-(
//
ISHELL_SetTimer( curApp->a.m_pIShell, 1, SoundTrigger, (void *)curApp );
}
}

I also found the problem, because I am using your sample code to play sound.
:-)

Hi, Dragon,
I found that your code piece for playing sound has something wrong, look at your code for suspend sound:
// SoundSuspend
//--------------------------------------
// When an external call comes in we
// need to suspend the sound player.
//
void
SoundSuspend( applet *curApp )
{
if ( NULL != curApp->Sound )
{
ISOUNDPLAYER_Stop( curApp->Sound );
}

when you stop the sound in your SoundLoopCallback, your callbak will receives a AEE_SOUNDPLAYER_DONE, AND SOUND WILL RESTART, see your code,
void
SoundLoopCallback( void *userData, AEESoundCmd cmd, AEESoundStatus status, uint32 para )
{
applet *curApp = (applet *)userData;
para = 0; // Just to avoid a WARNING C4100, unreferenced parameter
Assert( NULL != userData ); // Make sure we have a valid callback here
if ( AEE_SOUNDPLAYER_PLAY_CB == cmd )
{
if ( AEE_SOUNDPLAYER_DONE == status ) // If the sound is finished,
{
ISOUNDPLAYER_Stop( curApp->Sound ); // simply restart it
// Create a really short timer that will then
// trigger a restart of the MIDI track.
//
// Sadly we can't just STOP and START them - another BREW glitch. :-(
//
ISHELL_SetTimer( curApp->a.m_pIShell, 1, SoundTrigger, (void *)curApp );
}
}

I also found the problem, because I am using your sample code to play sound.
:-)

I have never had that problem, but yes, that's an outdated code version of my implementation. I have long since corrected this problem because a number of handsets had some issues stopping audio without having reset the callback first.
Still, thanks for pointing out the issue you've had with it. Like I said, it's just outdated code.

I have never had that problem, but yes, that's an outdated code version of my implementation. I have long since corrected this problem because a number of handsets had some issues stopping audio without having reset the callback first.
Still, thanks for pointing out the issue you've had with it. Like I said, it's just outdated code.