Closed mialex closed 4 years ago
After doing more research I found out that indeed the issue was caused by the Default audio device received AVAudioSessionInterruptionTypeBegan. Af far as the session was interrupted and never got back I've decided to deactivate the session manually. Luckily that helped.
func participantDidDisconnect(room: Room, participant: RemoteParticipant) {
let session = AVAudioSession.sharedInstance()
do {
try session.setActive(false )
} catch let error as NSError {
print("Unable to activate audio session: \(error.localizedDescription)")
}
...
}
Maybe you have some better options or suggestions on how to deal with that or if this fix will be included in the next releases?
Hi @mialex,
Thanks or writing in. I looked at the Room Sid you provided and I am not sure why the AVAudioSessionInterruptionTypeBegan
is not coupled with an AVAudioSessionInterruptionTypeEnded
.
EmbeddedMultiVideo[4586:3457012] DEBUG:Twilio:Platform: Default audio device received AVAudioSessionInterruptionTypeBegan.
Do you know what causes this interruption to begin in the first place? It doesn't look like it happens when UserOne disconnects from the Room.
I am also wondering if you have Enabled Background Audio in your application, just in case this is the culprit.
Thanks, Chris
Hi, @ceaglest
Do you know what causes this interruption to begin in the first place?
Not sure, as after I've made a call and the second participant has disconnected I've put my phone aside and did nothing except staying on the page with the video call and waiting for the second participant to get back on the call. In some time 10+ minutes or so, I get AVAudioSessionInterruptionTypeBegan notification. Maybe because of inactivity iOS system put the application to the background even though it's still opened (not sure as I'm not an expert :) )
I am also wondering if you have Enabled Background Audio in your application
I saw that option but was not sure If I have to use that as I don't put the audio to the background. At least I don't do that, in case of the system can do that. So, answering your question, I haven't used that option. Is this mandatory to use that?
Enabled Background Audio has helped me to avoid this issue, thx
Description
Hello, as far as I'm not an expert in iOS development, that's why I can't identify if this issue is related to some missed logic in the quickstart-ios. I was using a MultiPart example. Seems like it's been removed, as I can't see this project right now. I expect that MultiPart video was moved to twilio-video-app-ios repository.
Anyway, I have an issue with the audio and I'm not sure that it's related to the MiltyParty. In our flow, it's possible that one of the participants can just stop the call for some time and then get back. If the video stopped for more then 15+ minutes and then the participant gets back (join to the room again), then a video is present, but audio does not work for both participants. Unsubscribing the audio and subscribing to it back when the remote participant did connect to the room does not help. Only if the page closes (dismissed) and then open again fresh page, it's possible to join the room with working audio.
As additional info, we use Pear-to-Pear connection. The second participant can use the iOS app or can be connected form the Web with the Angular SDK
NOTE: I also spot that audio stops working after this notification. Why that rise and why I don't see AVAudioSessionInterruptionTypeEnd.
Steps to Reproduce
Code
The code is almost the same as it was in MultiParty example, with only some minor changes regarding view part
Expected Behavior
The expected result is if even after 15+ minutes somebody gets back to the call, both video and audio should work.
Actual Behavior
Actually, in 15+ minutes audio stops working, but video works fine.
Reproduces How Often
Almost every time I do that
Versions
All relevant version information for the issue.
Video iOS SDK
TwilioVideo 3.2.5 via CocoaPods
Xcode
11.3.1
iOS Version
13.3.1
iOS Device
iPad Pro
Logs
Thank you