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)](http://developer.apple.com/library/ios/documentation/MusicAudio/Conceptual/AudioUnitHostingGuide_iOS/UsingSpecificAudioUnits/UsingSpecificAudioUnits.html#//apple_ref/doc/uid/TP40009492-CH17-SW8) manage at once?
He was quite optimistic, and as it turns out, he was right: It’s rather capable.
I modified the [iPhoneMultichannelMixerTest](http://developer.apple.com/library/ios/#samplecode/iPhoneMultichannelMixerTest/Introduction/Intro.html) 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.
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.
Not too surprising that it’s linear, mixing two channels just involves adding their samples.
Indeed, that’s pretty much as expected =)
For the 100 channels, were the sample files all being loaded into memory in their entirety or were they being buffered in chunks?
Hey Bradley – they were loaded entirely into memory at the start. There were only two audio files, just layered a lot of times.
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?
*B
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.