Removing AEAudioUnitChannels and getting error -10861

edited May 2013

I am getting the following error when I attempt to remove too many channels at once:

AEAudioController.m:1035: Update graph result -10861

My app creates and plays AEAudioUnitChannels on-demand, using local media files played thru the Audio Unit component kAudioUnitSubType_AudioFilePlayer.

I call AudioFileOpenURL() ahead of time in a prepareToPlay method, and when the play method is called, I set channelIsPlaying to YES, configure the kAudioUnitProperty_ScheduledFileRegion on the audio unit, and add the render callback using AudioUnitAddRenderNotify().

Upon stopping, I set channelIsPlaying to NO, call AudioUnitRemoveRenderNotify() followed by AudioUnitReset() before attempting to removeChannels: on the AEAudioController.

In the simulator, I can play and stop 5 audio files simultaneously without problem. But if I play 6 at once, I get the -10861 error after the last file stops. Once that error appears, the AEAudioController is horked and will not play any more audio until it is destroyed and a new one reinitialized.

This makes me think that the asynchronous calls inside so many removeChannels: calls are taking too long to complete, and maybe are causing the main Audio Unit render loop to screw up and fail somehow.

The only thing that "works" is not removing the channels after they finish playing. But then I'm faced with a 100 channel limit (as enforced by kMaximumChannelsPerGroup), and I can't afford to arbitrarily limit my users to only 100 items.

Should I be waiting until some proper moment to ask the Audio Controller to remove the channels, or should I queue the channels for removal at a more opportune time? I have tried not reusing the same channel objects, tried calling removeChannels: on the render loop thread (took too long), tried AEAudioControllerSendAsynchronousMessageToMainThread(). Nothing worked.

Anyone having this same issue? I assume it's an implementation issue on my end -- but I really could use some ideas about how to fix it.


  • This sounds like a TAAE bug to me, @balord - I'd like to take a look at this, but it'd be a huge help if you could create a sample project that demonstrates the issue so I can dive straight in. Perhaps just alter the sample project provided with TAAE to add/remove a large number of channels, then post a patch (or a zip with the whole lot) here?

    Generally speaking, I think you've taken the right approach - it's just a matter of figuring out why it's borking.

  • edited May 2013

    Your note about github issue 22 seems like it could be related to this issue, yeah?

    I will still see if I can replicate the issue for you in the Example Project tho... Thanks much.

  • edited May 2013

    Attached is a version of the EngineSample project where I stripped ViewController.m down to just the play button and created in a bunch of channels with a pared-down version of my AEAudioUnitChannel subclass.

    (I use ARC in my app, so excuse my sloppy memory management.)

    When you hit the play button, it will play each channel with a slight delay between them.

    My tests in the simulator do fine with 5 channels playing 0.5 seconds apart -- hit the play button as many times as you want. Things go bad when you build it with 6 channels -- hitting play a second time sounds like it only plays 5 of the 6 channels. And the whole AUGraph is unrecoverable after playing 7 or more channels.

    This is the error I get in the console:

    AEAudioController.m:988: Update graph result -10861 FFFFD593 ˇˇ’ì

    which is

    [self updateGraph]

    inside of


    , but in my app it often stops at


    on AEAudioController.m:483 in



    I really hope this helps!

  • Nice work, that does indeed help!

    I've done some experimenting, and it looks very much like there's something like a buffer overrun problem in either BLAudioUnitChannel or AEAudioUnitChannel. When replacing that class with AEAudioFilePlayer, everything works perfectly, but when using BLAudioUnitChannel, I've found it appears to be trashing an internal data structure within AEAudioController - in particular, with my testing, it results in AEAudioController thinking an Audiobus output port's been set for the channel (the 'audiobusOutputPort' element of the internal channel structure is non-NULL).

    I've spent about all the time I can justify on it today, so I'm going to have to leave it there, at least for now, but the steps forward are to pour over those two classes and try to find where the memory problems are.

  • I really appreciate you taking a look at it.

    I'll keep an eye out for a solution, but your comment on github issue 22 got me thinking about how I handle my AE channels. For now rather than remove, I will keep a set of "unused" channels and attempt to reuse existing channels before adding new ones. Then I can just remove all the channels when I dealloc the AEAudioController and whatever happens happens. Possibly it's a better approach long-term anyway.

  • Probably a good call!

  • btw - I just pulled the latest commits in from github and saw commit ac928bf addressed channel removal.

    i tried my sample project (zipped above) with this latest TAAE and no more errors! thanks!

  • Ah, excellent news

Sign In or Register to comment.