- This topic has 7 replies, 2 voices, and was last updated 8 years, 12 months ago by Halle Winkler.
-
AuthorPosts
-
April 28, 2015 at 3:02 pm #1025538davestrandParticipant
I followed instructions on this thread and archived/imported the newly created framework to try and restore remote control events via bluetooth headsets, but it did not seem to help.
In troubleshooting I noted that I am able to restore bluetooth controls by switching to AVAudioSessionCategoryPlayback instead of AVAudioSessionCategoryPlayAndRecord like below.
NSError *error = nil; AVAudioSession *aSession = [AVAudioSession sharedInstance]; [aSession setCategory:AVAudioSessionCategoryPlayback withOptions:AVAudioSessionCategoryOptionAllowBluetooth error:&error]; [aSession setMode:AVAudioSessionModeDefault error:&error]; [aSession setActive: YES error: &error];
Initially the bluetooth headset does receive audio in low-fidelity (reduced audio quality) with OpenEars voice recognition, but remote control events are not activated. Perhaps this is a low-energy mode? Do you know if AVAudioSessionCategoryPlayAndRecord should support remote control events?
April 28, 2015 at 3:06 pm #1025539Halle WinklerPolitepixHi,
Can you give me a bit of background on the initial issue which led to this post?
April 28, 2015 at 4:10 pm #1025540davestrandParticipantYes,
I am trying to allow remote control events from bluetooth headsets. On many bluetooth headsets there is a button which normally allows the user to pause/play rewind/fast forward. My app plays mp3s, and then listens for audio commands. Until OpenEars starts listening these remote controls still work. Once OpenEars starts listening the audio switches into a different mode where these controls are disabled and audio quality is reduced. Perhaps this is just a limitation of the ‘mode’.
April 28, 2015 at 4:17 pm #1025541Halle WinklerPolitepixSorry, I think this comes more under the category of being an audio session coexistence problem across multiple media objects than an issue with OpenEars + bluetooth remote, unless the bluetooth remote on this device used to work with OpenEars 1.x and your app’s other audio session requirements simultaneously, but now it has stopped doing so with OpenEars 2.x. I’ve tested the approach in the linked thread so I know that bluetooth remote events work fine with the alteration in that thread, but all bets are basically off once there are different objects changing the session by themselves (including OpenEars, which also has to do that).
April 28, 2015 at 4:34 pm #1025542davestrandParticipantI see. I’ll continue to search around the forums in regards to “Audio Coexistence”. Perhaps this thread will be of assistance.
April 28, 2015 at 4:38 pm #1025543Halle WinklerPolitepixYes, there are many discussions of this issue to check out. I would start by verifying that bluetooth remote works without the coexistence when you make the changes from the other thread and then start trying some of the coexistence steps.
April 29, 2015 at 5:29 pm #1025556davestrandParticipantSo, one last question before I continue… Below I have a screenshot from my app with the remote control functions. Put simply the Pause never changes to a Play button when the OEPocketsphinxController starts listening. What I am noticing is that when I remove the startListening and insert a bit of code it works again… Is this an audio coexistence problem too?
I remove this…
[[OEPocketsphinxController sharedInstance] startListeningWithLanguageModelAtPath:self.lmPath dictionaryAtPath:self.dicPath acousticModelAtPath:[OEAcousticModel pathToModel:@"AcousticModelEnglish"] languageModelIsJSGF:FALSE]; // this start listen specifically messes up the bluetooth control.
and insert this… and Pause/Play works again.
NSError *error = nil; AVAudioSession *aSession = [AVAudioSession sharedInstance]; [aSession setCategory:AVAudioSessionCategoryPlayAndRecord withOptions:AVAudioSessionCategoryOptionAllowBluetooth error:&error]; [aSession setMode:AVAudioSessionModeDefault error:&error]; [aSession setActive: YES error: &error];
April 29, 2015 at 5:34 pm #1025557Halle WinklerPolitepixCorrect, everything unexpected which happens when you are using a media object other than OpenEars with its own audio session requirements at the same time you are doing recognition with OpenEars is an audio coexistence issue. The fundamental issue is that there is only one audio session and each object has requirements for what the session settings should be, and they are changing it while the other object is still using it.
-
AuthorPosts
- You must be logged in to reply to this topic.