Phone calls do not pause media

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by robert.b...@gmail.com on 11 Jul 2010 at 4:36

[GoogleCodeExporter]

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!

Original comment by dc3de...@gmail.com on 14 Jul 2010 at 1:24

[GoogleCodeExporter]

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. 

Original comment by robert.b...@gmail.com on 14 Jul 2010 at 1:48

[GoogleCodeExporter]

I already experimented the function that should solve this issue :
http://developer.android.com/intl/fr/reference/android/media/AudioManager.html#s
etStreamSolo%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.

Original comment by r3gis...@gmail.com on 14 Jul 2010 at 9:23

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by egcros...@gmail.com on 18 Jul 2010 at 5:06

[GoogleCodeExporter]

@egcrosser : sounds that there is something that prevent the unsetAudio method 
(see 
http://code.google.com/p/csipsimple/source/browse/trunk/CSipSimple/src/com/csips
imple/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 :
http://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.

Original comment by r3gis...@gmail.com on 18 Jul 2010 at 5:24

[GoogleCodeExporter]

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.

Original comment by robert.b...@gmail.com on 18 Jul 2010 at 5:32

[GoogleCodeExporter]

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#requestAu
dioFocus%28android.media.AudioManager.OnAudioFocusChangeListener,%20int,%20int%2
9
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(...).

Original comment by egcros...@gmail.com on 18 Jul 2010 at 5:40

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 18 Jul 2010 at 5:52

[GoogleCodeExporter]

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.

Original comment by egcros...@gmail.com on 18 Jul 2010 at 5:52

Attachments:

• csipsimple.txt

[GoogleCodeExporter]

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...

Original comment by egcros...@gmail.com on 18 Jul 2010 at 6:00

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 18 Jul 2010 at 6:45

[GoogleCodeExporter]

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.

Original comment by egcros...@gmail.com on 19 Jul 2010 at 4:29

[GoogleCodeExporter]

... 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

Original comment by egcros...@gmail.com on 19 Jul 2010 at 5:33

[GoogleCodeExporter]

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)

Original comment by r3gis...@gmail.com on 19 Jul 2010 at 7:05

[GoogleCodeExporter]

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

http://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 :(

Original comment by r3gis...@gmail.com on 21 Jul 2010 at 3:07

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 9 Aug 2010 at 3:44

• Changed state: Fixed

[GoogleCodeExporter]

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.

Original comment by egcros...@gmail.com on 2 Sep 2010 at 2:14

[GoogleCodeExporter]

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

Original comment by r3gis...@gmail.com on 2 Sep 2010 at 4:40

• Changed state: Accepted

[GoogleCodeExporter]

Should be ok with -12-27. 

Can you confirm?

Original comment by r3gis...@gmail.com on 3 Sep 2010 at 9:32

[GoogleCodeExporter]

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

Original comment by egcros...@gmail.com on 3 Sep 2010 at 9:51

[GoogleCodeExporter]

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?

Original comment by r3gis...@gmail.com on 4 Sep 2010 at 9:15

[GoogleCodeExporter]

* 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.

Original comment by egcros...@gmail.com on 4 Sep 2010 at 11:44

[GoogleCodeExporter]

> 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.

Original comment by egcros...@gmail.com on 4 Sep 2010 at 11:52

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 4 Sep 2010 at 3:07

[GoogleCodeExporter]

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.

Original comment by r3gis...@gmail.com on 4 Sep 2010 at 4:04

[GoogleCodeExporter]

r3gis.3R, this is not strictly related to pausing media, but I stumbled upon it 
and I thought that you might be interested. This is a technique of dynamically 
using different APIs depending on their availability. I don't know the value of 
this advice, the whole java thing just makes me dizzy ;-) Anyway, this is the 
article:
http://devtcg.blogspot.com/2009/12/gracefully-supporting-multiple-android.html

Original comment by egcros...@gmail.com on 6 Sep 2010 at 2:30

[GoogleCodeExporter]

Thanks for the link.
But don't worry I'm really confident with backward compatibility stuff ;). 
There is already a lot of things in CSipSimple that use different levels of API 
and fallback to degraded feature when running on 1.5 (for example tab bar on 
1.5 doesn't look like the same ;) ).
There is two techniques to do so. Both are well described in the android blog : 
http://android-developers.blogspot.com/2009/04/backward-compatibility-for-androi
d.html
If you are interested to have the full view of both method that can be used.

The only thing I risk is forget to check when I use a method whether it is 
available in android 1.5 ;). But if so, users will immediately report it since 
app will directly force close at loading time ! 

For this issue, I've something functional. Need to commit and build it. (It 
will be in next dev release, but I'll try to not forget to update this issue 
when it will be released).

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 3:42

[GoogleCodeExporter]

-12-29 now support the 2.2 api for audio focus. 
Works properly on my Nexus One 2.2. But it's with official music application. 
Let me know if it's fine with HTC Music player too. (I hope that they have also 
implemented the 2.2 audio focus support....)

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 8:42

[GoogleCodeExporter]

Yes, the player stops now!
It does not restart playing when the call is over, but it sometimes does not 
restart after mobile call either (sometimes it does. go figure.)
Anyway I call it testing success :) Thanks!

Original comment by egcros...@gmail.com on 6 Sep 2010 at 9:15

[GoogleCodeExporter]

Ok great.
In fact, audio focus announce that it is a "transient" gain (see : 
http://developer.android.com/reference/android/media/AudioManager.html#AUDIOFOCU
S_GAIN_TRANSIENT) . Regarding code of the official music app, if the focus gain 
is is transient, then it will restart playing : They save the loss type as flag 
that is used to know if restart should be done after the focus is gain again.
As I use this type of audiofocus, I should be restarted after... unless music 
audio manager receiver is freed (can be the case if android ask for RAM memory 
- or because of a bug in the HTC Music app).
It could explain what you observe. Maybe in csipsimple you'll get the same 
random behavior than the one you have for mobile calls. The only way to be sure 
would be to have the HTC music app source code :).

Original comment by r3gis...@gmail.com on 6 Sep 2010 at 9:39

• Changed state: NextRelease