mumble-iphoneos
mumble-iphoneos copied to clipboard
mumble-voip
No more sound once application is interupted by a phone call.
When a phone recieves a phone call, and call is completed. Mumble application seems to be running just fine and is sending pings to server (seen in logs), but no audio is played.
I should also note that no more red status bar is displayed when you press the home button once the app is in this state.
No more red status bar would suggest that our audio session got yanked. Should be pretty easy to fix, but I don't have hardware capable of making calls (I only have an iPod Touch..)
I guess apps get a notification or get notified through UIApplicationDelegate?
Thats correct, the UIApplicatinDelete will get a "applicationWillResignActive:" call once the interruption begins, and will get a "applicationDidBecomeActive:" if the interuption is ignored the application will call "applicationDidBecomeActive:".
Hey,
I've tried to fix this in the latest BetaReleas. Can you please try it out and see if it works like you expect? It also disables audio if it's put into the inactive state and it's connected to a server.
Note that I don't have an iPhone, only an iPod, so I can't really test whether it works correctly when a call is received. Thanks!
Ok i tested this morning and here the test cases and results:
Case#1: App is launched, I am talking, received phone call, decline call. Result: Once phone rang, I can see the audio input/output was torn down. Once the call is declined, the application is back to the foreground, MKAudio was started (in 0.7seconds) and can received sounds. One small issue is that the lips were still red even though no sound was being transmitted. I had to tap on the push to talk button twice to start sending audio again. I assume the issue here is the button state isn't being reset when audio session is torn down/started.
Case#2: App is launched, I am talking, received phone call, answer call. Results: Same as case#1.
Case#3: App is launched, I am not talking, received phone call, decline call. Results: Pass. Working as expected.
Case#4: App is launched, I am not talking, received phone call, answer call. Results: Pass. Working as expected.
Case#5: App is in background, I am talking, received phone call, decline call. Results: Same as issue #1.
Case#6: App is in background, I am talking, received phone call, answer call. Results: When the call came, audio input/output was torn down. When the call ended, nothing happened, red status bar was gone and did not come back. Logs showed no audio session starting up. No pings were being sent. When I launched the app, it directly went back to server view (as expected), audio session started up (according to logs), the app began pinging, however the pings were failing. Logs showed a "MKConnection: write error".
Case#7: App is in background, I am not talking, received phone call, decline call. Results: Pass. Working as expected.
Case#8: App is in background, I am not talking, received phone call, answer call. Results: Same as #6.
Case#9: App is connected to server, go into background. Results: Pass. I see red status bar. Working as expected.
Case#10: App is not connected to server, go into background. Results: Pass. I can see the red status bar go away, as I go into home screen. Working as expected.
In summary, 2 issues remaining: -push to talk state is not being reset when audio session is stoped/started. (I think audio transmission state should be stoped, so lips should turn grey)
-Case #6. This is weird because this means iOS is calling the background application back only if the call is declined, not after it is answered. =/
In regards to cases #5, #6, #7, #8. The application delegate does NOT get a "applicationDidBecomeActive:" callback. When the call is declined, the audio session seems to start up again somehow, but this is not triggered from the AppDelegate.
Another thing to note is that in all cases where a phone call is declined, the audio session starts up automagically.
However in all cases when a phone call is answered, the audio session needs to be started up explicitly by the application. applicationDidBecomeActive: takes care of that when the application is in the foreground only.
One last thing to note is that when a call is answered while app is in background. Once the call completes, I see two pings occour, but no more pings after that. No audio, and no red status bar. Attached is logs with my comments.
2010-10-10 15:27:02.987 Mumble[1186:8423] MKConnection: Sent ping message. 2010-10-10 15:27:03.093 Mumble[1186:8423] UDP ping = 108364 usec 2010-10-10 15:27:03.146 Mumble[1186:8423] MKConnection: pingResponseFromServer 2010-10-10 15:27:07.987 Mumble[1186:8423] MKConnection: Sent ping message. 2010-10-10 15:27:08.083 Mumble[1186:8423] UDP ping = 98765 usec 2010-10-10 15:27:08.151 Mumble[1186:8423] MKConnection: pingResponseFromServer --------->> CALL RECEVIED <<------------------------- 2010-10-10 15:27:10.227 Mumble[1186:307] AudioInput: Teardown finished. 2010-10-10 15:27:10.230 Mumble[1186:307] AudioOuptut: Teardown finished. 2010-10-10 15:27:10.231 Mumble[1186:307] MKAudio: Audio route changed. --------->> CALL ANSWERED at 15:29:16 <<------------- --------->> CALL ENDED at 15:27:27 <<---------------- --------->> No Audio, no red status bar <<---------------- 2010-10-10 15:27:27.769 Mumble[1186:8423] MKConnection: Sent ping message. 2010-10-10 15:27:27.987 Mumble[1186:8423] MKConnection: Sent ping message. 2010-10-10 15:27:31.117 Mumble[1186:8423] UDP ping = 3348996 usec 2010-10-10 15:27:31.121 Mumble[1186:8423] MKConnection: pingResponseFromServer 2010-10-10 15:27:31.122 Mumble[1186:8423] UDP ping = 3137911 usec 2010-10-10 15:27:31.246 Mumble[1186:8423] MKConnection: pingResponseFromServer --------->> No Audio, no red status bar <<---------------- --------->> APPLICATON LAUNCHED FROM FAST-SWITCHING BAR <<------------- 2010-10-10 15:28:00.450 Mumble[1186:8423] MKConnection: Sent ping message. 2010-10-10 15:28:00.649 Mumble[1186:307] MumbleApplicationDelegate: MKAudio not running. Starting it. 2010-10-10 15:28:00.831 Mumble[1186:307] AudioInput: 24000 bits/s, 48000 Hz, 480 sample CELT 2010-10-10 15:28:00.845 Mumble[1186:307] AudioInput: initializeMixer -- iMicFreq=48000, iSampleRate=48000 2010-10-10 15:28:00.850 Mumble[1186:307] AudioInput: Initialized mixer for 1 channel 48000 Hz and 0 channel 0 Hz echo 2010-10-10 15:28:01.088 Mumble[1186:690b] AudioInput: No buffer allocated. warning: The VAD has been replaced by a hack pending a complete rewrite 2010-10-10 15:28:01.104 Mumble[1186:690b] MKAudioInput: udpMessageType changed to 0 2010-10-10 15:28:01.106 Mumble[1186:690b] AudioInput: Reset CELT state. 2010-10-10 15:28:01.137 Mumble[1186:307] AudioOutput: Output device currently configured as 48000Hz sample rate, 2 channels, 4 sample size 2010-10-10 15:28:01.335 Mumble[1186:307] MKAudio: Audio route changed. 2010-10-10 15:28:02.453 Mumble[1186:8423] MKConnection: pingResponseFromServer 2010-10-10 15:28:02.463 Mumble[1186:8423] UDP ping = 2013881 usec --------->> Everything is working as expected <<----------------
My guess is that the OS is putting the Mumble process in the inactive state in your case #6 example. Since we tear down all audio in the application, and because it's in the "audio" backgrounding class, the OS sees no reason for it to continue running...
One possibility, which you've also brought up is to use the VoIP backgrounding mode along with the audio one. I'm not sure this is the best solution.
The other solution is to simply request some time to finish our "task" via the iOS background task API.
WRT the applicationDidBecomeActive: callback and the AudioSession automatically being re-started, I think we're simply getting notified by the OS that the interruption of our AudioSession is over (but only if the call was declined.. See MKAudio_InterruptCallback in MKAudio.m of MumbleKit).
The lips not turning off is indeed a bug. It happens because we clean up our MKAudioOutputSpeech objects (they are the objects that handle decoding speech for users, but thhey also send out notifications when a user's talk state changes. Since we don't properly clean the objects up, the users will be stuck in the "talking" talk satte when we call -[MKAudio stop].
