With OpenEars on and listening, Airplay is disabled

Home Forums OpenEars With OpenEars on and listening, Airplay is disabled

Tagged: 

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

  • Author
    Posts
  • #1020308
    wfilleman
    Participant

    Hi Halle,

    I’ve got my app(s) updated and submitted to Apple for approval (finger’s crossed) and I’m starting in on generating a couple of video how-to guides on the app.

    I’m using the MAC OS software called AirServer to Airplay the screen from my iOS device to my MAC to record. The problem I’m running into is whenever I have an active Airplay connection and I turn the mic on (activate OpenEars), the AirPlay connection is dropped until I turn off the mic (tell OpenEars to stop listening).

    Any ideas about what I can do to keep the Airplay connection active while using OpenEars?

    Thanks Halle!
    Wes

    #1020309
    wfilleman
    Participant

    Hi Halle,

    Ok, found a partial workaround from: https://developer.apple.com/library/ios/qa/qa1803/_index.html

    Looks like iOS doesn’t let us do Airplay if we’re using the “VoiceChat” OpenEars option. Any of the other 4 options will allow Airplay, but then I lose the ability to play sounds from the app using the AudioServicesCreateSystemSoundID method. Specifically, iOS disables Airplay when using the AudioSession property: AVAudioSessionModeVoiceChat

    For now this will work for my demo video. The sound from the app isn’t necessary.

    If you happen to know of a combination of settings the .audioMode property that allows for speech recognition + sound playback + Airplay, I’m all ears, so to speak. My guess is that I’d need to change how I’m playing sounds and move away from the AudioServicesCreateSystemSoundID method.

    Thanks Halle,
    Wes

    #1020317
    Halle Winkler
    Politepix

    Hi Wes,

    Sorry, I really don’t know the answer to that one – the audio modes are offered on an as-is basis since trying to find all their quirks with different configurations would be prohibitive in terms of time, especially since they can also change in iOS releases.

    #1020318
    Halle Winkler
    Politepix

    My standard piece of advice for doing repeated short sounds is always to put them in an AVAudioPlayer that has been prepared to play or played silently once, since it doesn’t raise the same compatibility issues as AudioServicesCreateSystemSoundID (which compatibility issue is one of those quirks I mentioned).

    #1020340
    wfilleman
    Participant

    Thanks Halle,

    I did a little experimenting, and AVAudioPlayer works on the local iPad device and when Airplaying to another source, however, AVAudioPlayer has a bit of a delay (maybe 0.2 seconds) in playing the audio even after calling prepareToPlay. Seems like that’s the nature of this mechanism.

    In my case that wasn’t acceptable to convert over 100%, so I’ve gone back to using AudioServicesCreateSystemSoundID which give a nice immediate sound effect when only on the iOS device (no airplay).

    The workaround for anyone else reading is I look at the number of screens connected to the iOS device by calling [UIScreen screens]. If more than one (Airplay) then I configure PocketSphinx as the “Default” audioMode and use AVAudioPlayer to play my sounds. If there is only one screen then I configure PocketSphinx as the “VoiceChat” audioMode and use the AudioServicesCreateSystemSoundID method to create and play sounds.

    Not a perfect solution, but I figure that a little delay on the rarely used AirPlay mirroring is acceptable. 99% of the time the users would never run into this case and they get the optimal sound performance.

    Wes

    #1020341
    Halle Winkler
    Politepix

    Hi Wes,

    Sounds good, and thanks for documenting it for other readers.

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