XCTest problem: "You may only use one TAAE instance at a time"

Loving the 1.5 release so far (and the awesome AEAudioFilePlayer).

I'm having a problem where unit tests are unpredictably failing with NSInternalInconsistencyExceptions. The error message is "You may only use one TAAE instance at a time".

As far as I can tell, I'm properly dealloc ing the AEAudioController in the class under test, so it should be completely trashed and re-init'ed and restarted between individual tests.

I wondered if it was a latency issue (as I know AEAudioController takes a small amount of time to start), but adding a simple sleep(1.0) before and after each unit test didn't help.

Not sure what else I can try. Any thoughts?

Comments

  • (commenting out the line:
    NSAssert(!__AEAllocated, @You may only use one TAAE instance at a time);
    in AEAudioController.m prevents the errors, but I'm assuming there's a better solution if I can properly understand what's causing the problem.)

  • i had this problem before when i alloc AEAudioControler twice . had to only alloc once to fix it. might be be something different you are referring too.

  • There does indeed seem to be some retain cycle occurring - I've not had time to look deeply into it, though, I'm afraid (as TAAE's generally meant to be a singleton anyway). It'll need some time spent hunched over Instruments, I'd say.

  • First post to the forums. Thanks Michael for such a great engine. I've been able to use it to do some really cool things in my first app. I'll be releasing in the very near future (fingers crossed).

    Back on topic: I'm facing the same issue, although in my case I have a segmented control that allows users to switch between audio modes. One mode sets up AEAudioController with input enabled, the other without. Previous to this release, I could quickly tap back and forth between segments, and TAAE would be happy with tearing down/setting up the new controllers. Now I get this assertion because the previous controller has yet to call dealloc(). I could try commenting out the assertion, as jakemoves did, but I agree that's a kludge. Eliminating the retain cycle would probably fix it for me.

    But I do have a related question: there's no way for me to enable/disable input on AEAudioController without releasing the old and allocating a new, right? Am I missing something obvious?

  • And.... I answered my own question. Either I didn't notice it before, or it's a new method, but setInputEnabled just fixed my problem. I can switch back and forth between modes with ease now.

  • You didn't miss it - I just added that the other day =) (and thanks for the kind words!)

Sign In or Register to comment.