July 2, 2013 at 5:05 am #1017586foobar8675Participant
I have a few issues i’m stumped on. I’m trying to follow the steps here
but am getting errors such as
2013-06-29 09:49:25.855 EarsTest[2240:4e07] Audio Unit render error: kAudioUnitErr_CannotDoInCurrentContext
the steps I’m doing is
1. in appdelegate, start open ears and when it can listen, suspend recognition. as part of this, initalize audio session
2. the first view controller runs background music
3. after 5 seconds music pauses and open ears recognizes calling startAudioSession right before recognition
4. i say ‘cinderella’
5. open ears receives the hypothesis
6. open ears suspends, resetting audio session after 1 second delay
then I get errors
2013-06-29 09:49:24.956 EarsTest[2240:907] The previous audio route was SpeakerAndMicrophone
2013-06-29 09:49:25.206 EarsTest[2240:907] This is not a case in which OpenEars performs a route change voluntarily. At the close of this function, the audio route is Speaker
2013-06-29 09:49:25.299 EarsTest[2240:4e07] Audio Unit render error: kAudioUnitErr_CannotDoInCurrentContext
i wrote a test app which is on github:
and any suggestions would be very appreciated!July 2, 2013 at 9:07 am #1017589Halle WinklerPolitepix
The error is because AVPlayer’s audio session is the one active at the time of the error, i.e. OpenEars is not resetting the audio session after one second delay but instead recognition is trying to start while the audio route still has no audio input.
For simplicity, can you first of all move all of your related code into the root view controller? The app delegate isn’t a great place for any non-app-delegate code. You can use OpenEarsEventsObserver to get recognition results in other view controllers so that doesn’t pin you down to have it in the root view controller and it lets us deal with the issue without wondering about any race conditions with view loading or recognition starting.
And then it would be good to see your code in viewDidLoad (or wherever it all ends up) that just relates to this task.July 3, 2013 at 4:14 pm #1017604foobar8675Participant
first, thanks for responding Halle. i moved the related code (the wrapper at least) to the first root vc per your suggestion and noticed when i comment out the method on line 117 https://github.com/captainchung/openearstest/blob/master/EarsTest/SISpinxHelper.m
it seems to work ok. however, when it is not commented , i get the errors listed before and when the avaudioplayer resumes playback, it does so at a higher volume .
i think i’m fine with it the way it is – however i’m not sure why the audio resumes playback at a louder volume. this is more curiosity, but do you have any thoughts as to why that is?July 3, 2013 at 4:26 pm #1017605Halle WinklerPolitepix
Right, that isn’t surprising since it’s the ambient session that is being created in that line which has no input stream (IIRC) so it prevents PocketsphinxController from being able to start its audio unit.
The loudness thing is less clear. I don’t know the reason for that, but my best guess is that it is related to the route. Playback can either be routed to the external speaker or the ear speaker and one is much louder than the other. Different audio sessions have different default routes and need to be overridden to get different results. PocketsphinxController does re-route to the louder speaker, but it is possible that something about the session mixing is causing it to not successfully do that and then it is only when the new session is created that the sound is fully routed to the speaker. It could also be due to a side effect of the mixing setting, for instance if it does some kind of active volume reduction on the assumption that there are two output streams that have to be combined without clipping.Lastly it could just be a difference between the two different audio session settings that is more noticeable when the session is returned to ambient.
- You must be logged in to reply to this topic.