Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
@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
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
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
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
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:
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
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
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
... 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
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
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
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
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
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
Should be ok with -12-27.
Can you confirm?
Original comment by r3gis...@gmail.com
on 3 Sep 2010 at 9:32
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
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
* 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
> 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
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
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
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
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
-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
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
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
Original issue reported on code.google.com by
robert.b...@gmail.com
on 11 Jul 2010 at 4:36