Pushing MultiChannelMixer to the limit

A friend made an interesting suggestion to an issue I’m facing in the upcoming Loopy 2, and I thought I’d do some investigation: How many tracks can the MultiChannelMixer (kAudioUnitSubType_MultiChannelMixer) manage at once?

He was quite optimistic, and as it turns out, he was right: It’s rather capable.

I modified the iPhoneMultichannelMixerTest sample project to add a bunch of channels, and measured how my iPhone 4 performed. It looks pretty linear: there’s pretty much a 1:1 relationship between number of channels, and the CPU usage, actually.

Number of Inputs to MultiChannelMixer versus CPU usage

Of course, this is on the newest-most powerful iPhone, but there was no stuttering, and the interface (admittedly simple as it is) was fully responsive, including setting output volume, even with 100 channels. You’d probably want to stick with a maximum number of channels around the 75-100 mark, less for targeting lesser devices, but that’s a pretty generous limit.

Not bad.

Update: Not such great news for the iPhone 3G I just tested this on, though — it freaks at anything more than 20 channels, and isn’t too responsive with 20. The 3Gs seems to behave almost as well as the iPhone 4, but the CPU:channels relationship is more like 2:1.

, , . Bookmark the permalink. Both comments and trackbacks are currently closed.


  1. Joel Bernstein
    Posted January 24, 2011 at 1:06 am | Permalink

    Not too surprising that it’s linear, mixing two channels just involves adding their samples.

    • Posted January 24, 2011 at 11:10 am | Permalink

      Indeed, that’s pretty much as expected =)

  2. Bradley
    Posted February 12, 2011 at 12:28 am | Permalink

    For the 100 channels, were the sample files all being loaded into memory in their entirety or were they being buffered in chunks?

    • Posted February 12, 2011 at 10:20 am | Permalink

      Hey Bradley – they were loaded entirely into memory at the start. There were only two audio files, just layered a lot of times.

      • Bradley
        Posted February 12, 2011 at 4:12 pm | Permalink

        Thanks for the reply. I’m trying to do something similar, I’ve got four 1.8 MB stereo sample loops running, but I’m already seeing memory warnings from iOS.

        I’m really looking for some boiler plate code that does something to mitigate memory issues with having a lot of samples (some big some small) . Obviously they can’t be all fully loaded into memory at once, but that’s what every example I find does (albeit with 1 or 2 files max). The AudioQueue in the Audio Toolbox does the correct type of file/memory buffering, but I haven’t seen anything about anyone hooking an Audio Queue Buffer to an audio unit.

        Have you come across anything that might solve this issue? I think lots of folks could use it.

        Otherwise, Any pointers?


        • Posted February 12, 2011 at 5:23 pm | Permalink

          Hi Bradley,

          I’m afraid I can’t point you in the direction of any sample code off the top of my head, but if it were me, I’d be just buffering the audio a little at a time, possibly in a different thread to the playback one, if performance was an issue (I’d probably be using something like a circular buffer; reading samples in from file at one end, and passing them to the input callback from the other end), and freeing the played samples.