Closed muhatashim closed 3 years ago
Your guess is a good one, however, the resources are indeed cleaned up on a call to stop()
. I actually think this is behavior is related to the AVAudioSession not being shared appropriately between the two plugins asking for it within the same app. Currently, we just let the system deactivate AVAudioSession, which works across apps, but this must not work internally. I think we may have to explicitly deactivate it on call to stop()
. That's my guess anyway.
Which video plugin are you using? And can you provide me a code snippet to demonstrate how you're making these calls? I can look into this on Monday.
Your guess is a good one, however, the resources are indeed cleaned up on a call to
stop()
. I actually think this is behavior is related to the AVAudioSession not being shared appropriately between the two plugins asking for it within the same app. Currently, we just let the system deactivate AVAudioSession, which works across apps, but this must not work internally. I think we may have to explicitly deactivate it on call tostop()
. That's my guess anyway.Which video plugin are you using? And can you provide me a code snippet to demonstrate how you're making these calls? I can look into this on Monday.
I just created a new repository to isolate the issue: https://github.com/muhatashim/flutter-voice-processor-video-player-demo
Thanks, I'll look into this!
@muhatashim, I've fixed the issue in the latest commit (it's up on pub.dev too). Sure enough, it was due to the shared AVAudioSession being defined and held by the flutter_voice_processor and then the AVPlayer used by the video_player plugin couldn't get playback rights. Once you've tested the fix, please close the issue. Thanks for reporting this!
This issue is resolved as far as we can tell. Reopen if needed.
I am using a flutter video player plugin and the video player will not play if I try to start recording from voice processor and then stop it. In other words, here are my steps:
The idea that it is not completely cleaning up the resources is just an assumption for now though. I have yet to debug to iOS code itself to see what's really going on internally. From my isolated tests though, it seems to be that the root cause stems from the stop() method.