[warpling]

I was hoping TAAE was to blame here (maybe it still is) and the fix in 1.5.5 would solve this, but still no dice…

[warpling]

Sorry Halle, I lost track of our thread!

Removing suspendRecognition doesn’t seem to have a noticeable impact.

It must be related to these errors though:

2015-12-02 15:34:36.662 Blackbox[833:188408] 15:34:36.662 WARNING:  [0x19df2c000] 1251: AURemoteIO::Stop: error 0x10000004 calling TerminateOwnIOThread
2015-12-02 15:34:36.663 Blackbox[833:188561] 15:34:36.663 ERROR:    [AURemoteIO::IOThread] >aurioc> 1503: AURemoteIO@0x16092c840: IOThread exiting with error 0x10004002
2015-12-02 15:34:42.218 Blackbox[833:188408] 15:34:42.217 ERROR:    [0x19df2c000] AVAudioSession.mm:697: -[AVAudioSession setActive:withOptions:error:]: Deactivating an audio session that has running I/O. All I/O should be stopped or paused prior to deactivating the audio session.

On my 5s I see these errors around 30s after I lock the phone while OE is running (triggering stopListening). During this time the lock screen is not responsive (can’t slide to unlock but the “slide to unlock” glimmer animation runs). stopListening is being triggered from the main thread if that’s pertinent. What could I try troubleshooting next?

[warpling]

I’m having a similar issue with my app since it plays little UI sound effects. This is often a time when OpenEars is also beginning to attempt tearing down it’s session, so AVAudioPlayer begins trying to play a sound effect while OE tears down and OE gets upset and hiccups when it can’t teardown the audio session.

I was talking a bit with Michael Tyson about the need for AVAudioSession to keep track of how many clients it has! Anyone know someone on Apple’s Audio API team? ;)

Halle, is there a way for me to tell OE not to worry about tearing down the session or something?

[warpling]

Good addendum. And to clarify: I’m currently using 2.041.

[warpling]

I’ve been unable to narrow down a similar bug where starting/stopping Siri triggers the proper interrupt begin/end callback, but subsequent starting/stopping of Siri only triggers the interruption begin callback. I’ve seen it happen in the sample app, but it takes some serious button mashing.

I’m on a time crunch so I ended up moving my interrupt functionality to happen via the applicationWillResignActive and applicationDidBecomeActive lifecycle callbacks. Just wanted to leave this here for those stumbling upon the thread looking for a solution, albeit not necessarily the proper one!

[warpling]

Michael from TAAE took a look and caught a stupid malloc sizing issue I was making on [line 107](https://github.com/warpling/AudioEngineAndOpenEarsDemo/blob/master/AudioEngineAndOpenEarsDemo/ViewController.m#L107) (self.streamFormat.mBytesPerFrame should really be sizeof(float). It’s unclear why starting/stoping OE before using the buffers again exposed my mistake. Sorry for taking your time! This issue is closed.

[warpling]

Thanks Halle,

Thats okay, I by no means expect you to debug my code. I was just hoping you might have some idea of what OpenEars is doing behind the scene that could affect TAAE. I’d dig deeper myself but I can’t see the source of OpenEars to figure out what may be happening.

I examined the verbose logs of OE, but could not determine much since OE isn’t running/logging when TAAE crashes.

I narrowed the problem down to the calls to AEFloatConverterToFloat(...) (source). This function takes an AEFloatConverter, AudioBufferList, float output buffers, and a number of frames. The malloc error tends to occur only after OE has been started and stopped prior to starting TAAE so my thinking is that OE is changing the size or number of objects in the AudioBufferList, or the number of frames, and TAAE isn’t expecting or ready for the change but I’ve been unable to observe that. Doubling the size of the buffers seems to prevent the error even after starting/stopping OE.

[warpling]

(cross-post to TAAE forum)

[Author]

Posts