I am trying to stop sound when user exits the application by pressing Hang up key in Series 60. But the application goes to background and the sound still plays.
I want to stop the sound when user clicks the Hang up key of the device. I called the stop() method of Player. I also called the stop() method at hidNotify();
{
Player p;
p.start();
p.stop();
}
The AMS calls (or should call) the destroyApp() method of the MIDlet when the user exits.
Try putting your p.stop() command in there. (And other clean-up code too).
Related
I am facing issue with multiple calls when start using CallKit in my VOIP application.
When there is one to one VOIP call, sound is working fine. But once one party gets another VOIP call, and choose to Hold and Accept option; First call is put on hold successfully and second call is answered; But sound gets closed now. Even swapping between calls also does not work. and Dropping one call also does not work.
I am using RTP for voice.
I tried to put breakpoints and check if the AVAudioSession's category and mode are correct.
In the console I can check at my end that the device which has more than one calls, stop sending sound packets.
I am enabling VOIP just before reportNewIncomingCallWithUUID and CXStartCallAction of Provider.
Same case with GSM call. If there is one to one VOIP call with sound is ok and GSM call is received at one side and user choose to Hold and Accept option, sound in GSM call is working fine. But if user makes VOIP call as active and put GSM call on hold by swapping calls, there is no sound in VOIP call. Swapping calls and making GSM call active, sound again works fine. But no sound for VOIP call.
In this case, we are getting AVAudioSessionInterruptionTypeBegan but AVAudioSessionInterruptionTypeEnded is never called. Even after the GSM call is ended.
Has anyone run into similar issues?
Had the same issue. If I have 1 active call, then new calls is incoming, I tap hold&accept. New call works, but after using Swap in CallKit audio stopped working.
After long debug found the spot where actually audio is deactivating/activating for Swap calls via CallKit native interface - that is provider:performSetHeldCallAction: method from CXProviderDelegate protocol.
In my case I used the [audioController deactivateAudioSession] method for the call was putting in OnHold.
But I found that the same method provider:performSetHeldCallAction: was fired for other call that is being put active (from OnHold state), when tap Swap button via CallKit.
So in my case I first toggle hold for call (it put call either on hold or put it active out of hold).
Then I check what is call condition (whether hold or not) and then deactivate or activate audio respectively.
In common way it looks this way:
- (void)provider:(CXProvider *)provider performSetHeldCallAction:(CXSetHeldCallAction *)action {
SomeCallClass *call = [self.callManager callWithUUID:action.callUUID];
if (!call) {
[action fail];
return;
}
NSError *holdError;
[call toggleHold:&holdError];
if (holdError) {
[action fail];
} else {
if (call.onHold)
[self.audioController deactivateAudioSession];
else
[self.audioController activateAudioSession];
[action fulfill];
}
}
This code should be in the class that works as a CallKit provider delegate.
I am developing an WP8 app witch uses background audio agent. i have taken the background audio players sample. i have added the following method to audioplayer.cs
public static void playTrackAtIndex(int index)
{
currentTrackNumber = index;
BackgroundAudioPlayer.Instance.Track = _playList[currentTrackNumber];
}
after it is called the song at the specified index (let's say 5) will play, but when i pres skipnext in my ap or in the UVC currentTrackNumber is 0!. Please, any help is apreciated
it turns out you don't have any control over the lifecycle of the background audio agent, so at any time it may be killed and then instanced by the foreground app or the Background audio player. So the only whey to make the agent work is to design it as it will always be killed and instanced (use sql lite or files with a lock, or always check what backgoundaudioplayer is playing when your agent is called, so your agent will "remember" where it was before getting killed
i`m using mediaElement to play background music in my app. And that works just fine.
Problem is when the user minimize the application. When the application resume there is no sound... I can play other sounds in my application but cant play that background music any more.
First i have this code to stop all background music at first time app open:
if (Microsoft.Xna.Framework.Media.MediaPlayer.State == MediaState.Playing)
{
Microsoft.Xna.Framework.Media.MediaPlayer.Pause();
FrameworkDispatcher.Update();
}
xaml code of that mediaElement
<MediaElement AutoPlay="True" Source="/Dodaci/pozadina.mp3" x:Name="muzika_pozadina" MediaEnded="pustiPonovo" Loaded="pustiPonovo" />
and the cs code
private void pustiPonovo(object sender, RoutedEventArgs e)
{
muzika_pozadina.Play();
}
sound is about 300kb size.
So, how can i resume that sound playing after the user resume the application?
When your App is put into Dormant State (when you hit Start buton for example), the MediaElement is stopped. Then after you return to your App (and it wasn't Tombstoned), the Page is not Initialized once again, which means that your MediaElement is not loaded once again, so your Music doesn't start once again.
It depends on your purpose and code how it can be returned. In very simple example when you don't need to remember music last position you can just set source of your MediaElement once again in OnNavigatedTo() event:
protected override void OnNavigatedTo(NavigationEventArgs e)
{
base.OnNavigatedTo(e);
if (e.NavigationMode == NavigationMode.Back)
muzika_pozadina.Source = new Uri("/Dodaci/pozadina.mp3", UriKind.RelativeOrAbsolute);
}
As you have set your MediaElement.AutoPlay to true - it should start automatically (because of that you probably also don't need your Loaded event pustiPonovo).
In more complicated cases you can take an advantage of Activation and Deactivation events of your App - returning to MediaElement from Dormant/Tombstoned case is well explained here in the article.
You should also read about Fast App Resume in case User decides to return to your App by Tile instead of Launchers-Choosers.
I haven't tried above code, but hopefully it will do the job.
I am working on a J2ME application.
I am using Nokia 6131 NFC phone. I am using NetBeans IDE.
I have 4 forms and I am playing some notification sounds for the user while filling the form.
The problem is sound goes off suddenly after 3 to 4 min and the only solution is to exit the application and again open it.
My Code
public void playSoundOK()
{
try
{
InputStream is = getClass().getResourceAsStream("/OK.wav");
Player player = Manager.createPlayer(is,"audio/X-wav");
player.realize();
player.prefetch();
player.start();
}
catch(Exception e)
{
e.printStackTrace();
}
}
Exception
at com.nokia.mid.impl.isa.mmedia.audio.AudioOutImpl.openSession(AudioOutImpl.java:206)
at com.nokia.mid.impl.isa.mmedia.MediaOut.openDataSession(MediaOut.java:282)
at com.nokia.mid.impl.isa.mmedia.MediaPlayer.doPrefetch(MediaPlayer.java:155)
at com.nokia.mid.impl.isa.amms.audio.AdvancedSampledPlayer.doPrefetch(+4)
at com.nokia.mid.impl.isa.mmedia.BasicPlayer.prefetch(BasicPlayer.java:409)
at org.ird.epi.ui.UtilityClass.playSoundOK(UtilityClass.java:139)
at org.ird.epi.ui.EnrollmentForm.targetDetected(+695)
at javax.microedition.contactless.DiscoveryManager.notifyTargetListeners(DiscoveryManager.java : 700)
at javax.microedition.contactless.DiscoveryManager.access$1200(DiscoveryManager.java:103)
at javax.microedition.contactless.DiscoveryManager$Discoverer.notifyIndication(DiscoveryManager.java:882)
at com.nokia.mid.impl.isa.io.protocol.external.nfc.isi.NFCConnectionHandler$IndicationNotifier.run(+67) javax.microedition.media.MediaException: AUD
I would advise you to split NFC and audio playback into 2 different threads.
It is typically a bad idea to call a method that should take some time to complete (like prefetch) from inside an API callback (like targetDetected) because it makes you rely on a particularly robust kind of internal threading model that may not actually exist in your phone's implementation of MIDP.
You should have one thread whose sole purpose is to play the sounds that your application can emit. Use the NFC callback to send a non-blocking command to play a sound (typically using synchronized access to a queue of commands). The audio playback thread can decide to ignore commands if they were issued at a time when it was busy playing a sound (no point in notifying the users of multiple simultaneous NFC contacts)
You should close your player. Add the following code to your method:
PlayerListener listener = new PlayerListener() {
public void playerUpdate(Player player, String event, Object eventData) {
if (PlayerListener.END_OF_MEDIA.equals(event)) {
player.close();
}
}
};
player.addPlayerListener(listener);
Im streaming video to my MIDLET. And while it is playing it, after 20 seconds (depends on a system setting) display on the phone goes to stand-by mode.
How can I prevent this so I can watch the video for 5 minutes for example without having to tap something to wakeup the display?
Yeeeey I figured it out!!! But its a little hack and not the actual "Dont-Go-To-Stand-By" functionality... nevertheless it works PERFECT!!!! =D
Ok so the idea is to define the timeout that the display needs to be woken up. I let the user define this in the "Settings" screen and I write that in RMS so I can read it later...
Next, I define the TimerTask that calls getDisplay().flashBacklight(100); method every time that the defined timeout expires. And, this works like a charm!!! =D
Here is the concept code. First on the VideoCanvas (screen for drawing video) I define the TimerTask:
private class WakeTask extends TimerTask
{
public void run()
{
display.flashBacklight(100);
}
}
Next in the VideoCanvas constructor I start the timer and pass it the timeout, for example 10 seconds... and thats it:
***
timer = new Timer();
timer.schedule(new WakeTask(), 0, 10000);
***
So if the display goes to stand by after 15 seconds, and the timer runs every 10 seconds, it will never go to stand by, and will stay waken until you stop the timer. And if it goes to stand by in 5 seconds, timer will wake it up every time it runs just like you do when you tap something on the phone to wake it up. =)))
Yaaaay... =)))
P.S. Tested on NOKIA N96.