Bluetooth Remote Control Ver 2.0.3

Home Forums OpenEars Bluetooth Remote Control Ver 2.0.3

Viewing 8 posts - 1 through 8 (of 8 total)

  • Author
    Posts
  • #1025538
    davestrand
    Participant

    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?

    #1025539
    Halle Winkler
    Politepix

    Hi,

    Can you give me a bit of background on the initial issue which led to this post?

    #1025540
    davestrand
    Participant

    Yes,

    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’.

    #1025541
    Halle Winkler
    Politepix

    Sorry, 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).

    #1025542
    davestrand
    Participant

    I see. I’ll continue to search around the forums in regards to “Audio Coexistence”. Perhaps this thread will be of assistance.

    #1025543
    Halle Winkler
    Politepix

    Yes, 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.

    #1025556
    davestrand
    Participant

    So, 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];

    Quick Remote Control IOS

    #1025557
    Halle Winkler
    Politepix

    Correct, 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.

Viewing 8 posts - 1 through 8 (of 8 total)
  • You must be logged in to reply to this topic.