- This topic has 14 replies, 2 voices, and was last updated 8 years, 9 months ago by .
-
Posts
-
Hello halle.
when i send [pocketsphinxController stopListening]message.
i find that my audioSession route changed.
when i was playing audio, this will cause my playing audio stoped because of session route change.this is log
Stopping listening.
2015-07-02 18:00:24.782 SpeakOut[4740:1376358] Cleaning up.
2015-07-02 18:00:24.782 SpeakOut[4740:1376358] Cleanup complete.
2015-07-02 18:00:24.868 SpeakOut[4740:1376358] Unable to stop listening because because an utterance is still in progress; trying again.
2015-07-02 18:00:24.886 SpeakOut[4740:1376423] -[SOAudioManager handleSessionRouteChange:](128): -[SOAudioManager handleSessionRouteChange:]
2015-07-02 18:00:24.886 SpeakOut[4740:1376423] -[SOAudioManager handleSessionRouteChange:](138): {
AVAudioSessionRouteChangePreviousRouteKey = “<AVAudioSessionRouteDescription: 0x1704027c0, \ninputs = (\n \”<AVAudioSessionPortDescription: 0x170402790, type = MicrophoneBuiltIn; name = iPhone \\U9ea6\\U514b\\U98ce; UID = Built-In Microphone; selectedDataSource = \\U4e0b>\”\n); \noutputs = (\n \”<AVAudioSessionPortDescription: 0x170402700, type = Speaker; name = \\U626c\\U58f0\\U5668; UID = Speaker; selectedDataSource = (null)>\”\n)>”;
AVAudioSessionRouteChangeReasonKey = 3;
}
2015-07-02 18:00:24.888 SpeakOut[4740:1376423] Audio route has changed for the following reason:
2015-07-02 18:00:24.890 SpeakOut[4740:1376423] There was a category change. The new category is AVAudioSessionCategoryPlayAndRecord
2015-07-02 18:00:24.894 SpeakOut[4740:1376423] This is not a case in which OpenEars notifies of a route change. At the close of this function, the new audio route is —Speaker—. The previous route before changing to this route was <AVAudioSessionRouteDescription: 0x1704027c0,
inputs = (
“<AVAudioSessionPortDescription: 0x170402790, type = MicrophoneBuiltIn; name = iPhone \U9ea6\U514b\U98ce; UID = Built-In Microphone; selectedDataSource = \U4e0b>”
);
outputs = (
“<AVAudioSessionPortDescription: 0x170402700, type = Speaker; name = \U626c\U58f0\U5668; UID = Speaker; selectedDataSource = (null)>”
)>.Hello,
This originates somewhere else in your app (probably your AVAudioPlayer code). OpenEars never sets a speaker-only route and it doesn’t send any route changes on stop.
You have a custom audio session manager, which is probably creating a complicated situation since OpenEars also has an audio session manager. Check into what your custom audio session manager is doing, and what your playback code for your AVAudioSession does to the audio session.
stopListening doesn’t cause a route change and OpenEars never sets a speaker-only audio route. To solve this it is necessary to troubleshoot the other parts of your app.
Give extra attention to your custom audio session manager that is performing the same functionality as OpenEars’ audio session manager and running at the same time, because that is a likely source of complexity, and to the playback code of your AVAudioPlayer to see if it interacts with your audio session.
I can’t help you with your request because the issue you are seeing doesn’t come from OpenEars. I am sorry I can’t help with that.
Hello,
If you want me to investigate the logging, it is necessary to show the complete log for the whole app session without removing any parts of it, thank you. This log has the beginning and the middle removed so I can’t use it to understand what is happening in your session.
Hi,
Thank you for showing me more, but I need to see 100% of the OELogging output from the very beginning – there is no way for me to understand what is happening without seeing the whole thing. I can’t help if you cut out any of the logging. This log output has more content, but you have removed the beginning.
Thank you :) I will create a bug report for this and get back to you when I know why it is happening.
I took a look and this is correct behavior. OpenEars is not setting the route, it is only setting the audiosession inactive once it is done using it, which is a requirement for any object which makes audio session changes once it is done using the session.
The side-effect of releasing the audio session is that iOS sets routes and session types when the session is released. This is not possible for OpenEars to control.
If your AVAudioPlayers need a particular audio session or route, you can set them in the AVAudioPlayer initialization or playback code, and (if necessary) unset them in the AVAudioPlayer playback completion callback. Does that makes sense?
I unfortunately can’t prevent this from happening because it doesn’t start with OpenEars, it a behavior of the operating system. The only way to change the behavior would be to not release the audio session, but that isn’t correct handling for an object that has changed the audio session and doesn’t need its changes any more.
Another alternative to avoid releasing the audio session would be to use suspend and resume instead of start and stop for your listening session.
OK, I’m glad to hear you have a solution that works for you.
- You must be logged in to reply to this topic.