#85 Phone calls do not pause media

[Anonymous]

Originally created by: robert.b...@gmail.com
Originally owned by: r3gis...@gmail.com

What steps will reproduce the problem?
1. Play some music (tested with TuneWiki and Stock Player)
2. Receive a phone call.
3. Music and call come out earpiece.

What is the expected output? What do you see instead?
The music should pause. Instead, it continues playing.

What version of the product are you using? On what operating system?
CSipSimple 12, installed 07/11/2010 from the Market. Android 2.1, MyTouch 3G Slide.

Please provide any additional information below.

[Anonymous]

Originally posted by: dc3de...@gmail.com

This fix should be done with care. While it is not good for music to be heard, I would very much like to hear navigation instructions!

[Anonymous]

Originally posted by: robert.b...@gmail.com

I've been doing a small bit of research on this. There is an app called 'Shake2PlayNext' that can change the playing music on a number of players by sending a command that tells the phone the 'Next' media button was pushed from the headset (if I understand it correctly). Maybe on an incoming call, the same trick can be used to tell it to pause the music. I think this would stop the music, but would still allow Navigation to work.

[Anonymous]

Originally posted by: r3gis...@gmail.com

I already experimented the function that should solve this issue :
http://developer.android.com/intl/fr/reference/android/media/AudioManager.html#setStreamSolo%28int,%20boolean%29

The problem is that on some devices it seems to introduce problems. It was maybe linked to the combined use of another method and should be tested again.

Another way could be to use the new audio_focus method but this one is not available on all android versions.

Status: Accepted

[Anonymous]

Originally posted by: egcros...@gmail.com

With 0.00-12-01, playing media is not paused but muted. Which is better than nothing because you can at least talk now. However, media playback is not unmuted when the call ends and I just hear silence when I try to play any audio files. When I "Force quit" csipsimple from "Manage applications" menu media playback returns to norm.

[Anonymous]

Originally posted by: r3gis...@gmail.com

@egcrosser : sounds that there is something that prevent the unsetAudio method
(see https://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csipsimple/service/UAStateReceiver.java#483)

It can explains your issues with this latest version :
* The fact the stream doesn't come back to not solo mode
* The fact that you stay whith the SCREEN_DIM lock active.

So, I would be really interested if you can send me some traces using logcat.

Besides, I've just made a new build :
https://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-02.apk
If you are already using -12-01, reinstall is not needed.

There is several minor improvements in this one ( custom screen lock while in call, the disable codec feature on long clic on a codec ).

For the initial issue of this thread, I think that using streamsolo is the best and cleaner way to solve the issue.
But in addition of this solution, it's possible that in the future I look in the android MusicPlayer API to see what are the command to pause music. It will probably work only for the official music player but it's a cool feature.

Owner: r3gis.3R

[Anonymous]

Originally posted by: robert.b...@gmail.com

I played around with 0.00-12-01, and it worked just fine for me. Music muted when a call came in, and started back up when the call finished. For me, at least, this is an acceptable state. Thank you for your work, CSipSimple is an amazing system.

[Anonymous]

Originally posted by: egcros...@gmail.com

I will install the new build and produce a log for you shortly.

As to pausing the player, do you think that this is the right interface for the job?
http://developer.android.com/reference/android/media/AudioManager.html#requestAudioFocus%28android.media.AudioManager.OnAudioFocusChangeListener,%20int,%20int%29
Looks like (any sensible) audio player is supposed to register an onAudioFocusChange callback and if someone requests AUDIO_FOCUS, pause itself. If the theory is true, then all you need to do is requestAudioFocus(..., ..., AUDIOFOCUS_GAIN) and all other players will be advised to pause. Which they hopefully will do. After the call completes, abandonAudioFocus(...).

[Anonymous]

Originally posted by: r3gis...@gmail.com

Audio focus is use to almost mute another steam and make your more important than others. It was recently added in android and is not backward compatible with 1.5 devices.

For example it can be use by a GPS turn by turn applications that don't want to stop music but talk louder than music during a couple of seconds.

In the case of SIP application, I think is that music should be paused or at least totally muted (that's the current behavior since I added the streamSolo feature).

But this can be done only using an undocumented API from the Music application.
The android Music application is opensource (I recently contributed one line of code to this application in the android git :D ). So, it's quietly easy to find the private APIs. In fact it is probably undocumented private intents and these intents probably allow other apps to play/pause/stop music.

[Anonymous]

Originally posted by: egcros...@gmail.com

Installed 12-2 build; forced the running app (just to be sure), started "adb logcat", started the app, dialed '100', let the call complete, went to media player widget, hit 'play', watched the interface showing playback progress but heard no sound, stopped playback, stopped adb. Resulting log attached.

[Anonymous]

Originally posted by: egcros...@gmail.com

Re. audio focus: I am by no means expert or even developer for android, but the documentation says that AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK is supposed to "almost mute" the other playback, while AUDIOFOCUS_GAIN and AUDIO_FOCUS_GAIN_TRANSIENT are supposed to pause it. I may be misreading it, or people may not be using it as the documentation says, so don't take my words too seriously...

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok,

Thanks a lot for the logcat !

Seems the unsetAudio method well invoked but the setAudio is called twice. It can be the cause of our issues.

Just for my information, do you reproduce the screen lock issue with this version?

I added a test to lock only if not yet locked.
As SIP calls with an Asterisk server seems to make setAudio be called twice, it's really possible that previous version acquired the screenLock twice but released it only one time.
This version (12-02) should acquire the lock only one time. So hopefully release of the lock do his job now.

Besides the documentation specify that setStreamSolo calls are cumulative. So if called twice and unSolo only once... :). I should probably test force setAudio to be done only once. (Or at least setStreamSolo and wake locks).

P.S. : I've removed the logcat file from your comment : it's better to not let theses things be referenced by google - it contains your IPs addresses and your sip address.

[Anonymous]

Originally posted by: egcros...@gmail.com

I realized that AUDIOFOCUS_* concept is FroYo only :-(
Otherwise, it is probably the right tool here, according to http://docs.huihoo.com/google/io/2010/android-audio-techniques.pdf

I wonder if it is possible for the SIP app to "pretend to be a telephone" (it really is, isn't it?) and broadcast the same (DBUS?) messages that are received by PhoneStateListener  http://developer.android.com/reference/android/telephony/PhoneStateListener.html because presumably most media players are listening on onCallStateChange and pause themselves when they get notification of a call being in progress.

[Anonymous]

Originally posted by: egcros...@gmail.com

... which can be done by creating an Intent and sendBroadcast-ing it. Sipdroid does this (or tires to do, at least) in the function broadcastCallStateChanged in http://sipdroid.googlecode.com/svn/trunk/src/org/sipdroid/sipua/ui/Receiver.java

[Anonymous]

Originally posted by: r3gis...@gmail.com

Yes, that's true.
It's also probably the good way to solve parts of the issues 62 and 70.

I've just noticed : they also send intents to the music private api to perform pause
'final static String PAUSE_ACTION = "com.android.music.musicservicecommand.pause";'
(This one was the one I previously mentioned as undocumented music api)

[Anonymous]

Originally posted by: r3gis...@gmail.com

Thanks to sipdroid guys.... :D I was too lazy to find the intent myself but if given by the code that egcrosser underline ...

https://code.google.com/p/csipsimple/downloads/detail?name=CSipSimple_0.00-12-04.apk

Now pause the android Music application while in call. And then when sip call is finished, the android Music application is asked to continue to play.
The only annoying thing is that, as I supposed, other music application doesn't handle properly theses intents.

For example with the really nice cube media player it doesn't work at all and when call is finished, android music application start to play while was not playing and cube continues to play his track that was never stopped.
To solve this issue I'll add an option to disable android music player integration. But feature is nice :).

This revision also include a refactoring of how audio his tear up/down. Seems it improves things for many device but not enough stable yet :(

[Anonymous]

Originally posted by: r3gis...@gmail.com

Marked as fixed. SVN revision : [r191] . (will be bundle with 0.00-13)
Should be ok with the "official" music application. (Pause and restart after call).
Added an "integrate with music app" option for users with custom application (will just mute the stream). Since this app doesn't provide any way to manage play/pause music intents... an issue can be opened into these app trackers to ask them to support the same intents than the android official application.

Status: Fixed

[Anonymous]

Originally posted by: egcros...@gmail.com

There is a nitpick still: music player should be paused at the moment when incoming call arrives and ringtone starts to play. Right now, incoming ringtone overlays the player output, and the player is only paused when the call is answered.

This may be a minor issue for people who listen music, but I listen audiobooks, and having even only a few seconds of narration jammed is quite annoying.

[Anonymous]

Originally posted by: r3gis...@gmail.com

Ok, I'll try to move the code that stop music player from the begin of the call to the begin of the ringing. => Issue reopen

Status: Accepted

[Anonymous]

Originally posted by: r3gis...@gmail.com

Should be ok with -12-27.

Can you confirm?

[Anonymous]

Originally posted by: egcros...@gmail.com

Nope, same behavior (comment 17) with 12-27-bis from the download area

[Anonymous]

Originally posted by: r3gis...@gmail.com

Strange,

So two questions :
* While ringing you have still the player's icon in the notification bar? (on my N1, once it rings, music is paused and I can see that's done since there is not the play icon anymore in the notification bar)
* Are you using the "official" android music player or an alternate one?

[Anonymous]

Originally posted by: egcros...@gmail.com

* While ringing you have still the player's icon in the notification bar? (on my N1, once it rings, music is paused and I can see that's done since there is not the play icon anymore in the notification bar)

yes the icon is there. Now that I rechecked it, I realized that the player was not paused when I answered the call, but only muted. Which BTW I think should happen right when the ringtone starts, too.

* Are you using the "official" android music player or an alternate one?

No, HTC music player. (And, it *is* paused by mobile calls). I think that I don't have Android player at all on my device.

Are you currently sendBroadcast()-ing the "RINGING" and "OFFHOOK" and "IDLE" events? I understand that these should work for any (well-behaving) media player.

[Anonymous]

Originally posted by: egcros...@gmail.com

> Are you currently sendBroadcast()-ing the "RINGING" and "OFFHOOK" and "IDLE" events?
> I understand that these should work for any (well-behaving) media player.

On a second thought, it is *possible* (not checked!) that in 2.2 the HTC player no longer listens for ACTION_PHONE_STATE_CHANGED events, and instead relies on the new AUDIOFOCUS interface. Presumably, standard phone application uses it too so they cooperate properly.

[Anonymous]

Originally posted by: r3gis...@gmail.com

I properly sent these broadcasts. But you're right, from 2.2 (at least the android music player), they prefer to use the audio focus api.
However I didn't choose this solution previously since backward compatibility is not easy to do in a first time.
But I'll try to do so now keeping the old method if < 2.2.

[Anonymous]

Originally posted by: r3gis...@gmail.com

And besides, re - read older android source code, they previously relied on "onCallStateChanged" which is not triggered by the intent but at the same time of the intent I send).
I've just implemented the audio focus method. Works with android music app too so it will be included in next release to allow you to test it.