I am writing a program that has two view controllers. One view controller configures a sound which is played through a remoteIO audioUnit. The other view controller receives audio from the mic, processes that audio and displays information related to the sound received from the mic. Both view controllers need work with the same audio graph. I have used the Apple's AurioTouch2 example to guide my code, but that program puts much of the code in the application delegate (and a helper class) including setting up the audio graph and the callbacks for incoming and outgoing audio. This seems to put more code in the application delegate than necessary. What is the best practice for structuring my application? Where should the audio unit be setup? Where should the callback be for send audio to the audio unit? Where should the callback be for received audio?
1 Answers
Since there is only one RemoteIO Audio Unit available to an iOS app, a singleton controller object might be a good place to centrally locate all code related to that Audio Unit. The combination of the app delegate plus possibly a helper object or class can serve as a surrogate for this singleton controller in small simple apps. But in larger apps it might be better to use a separate audio controller class. Some sort of Model class might be suitable for encapsulating any audio state data (waveform data, etc.)
A reference to the audio controller object or data model objects can be passed to any other view controllers that need to control or access audio. That would fit an MVC pattern for combined light (UIViews) and sound (audio units).
Note that the Audio Unit API is a C API, so using globally visible C subroutines and state is also possible (e.g. some .c files not associated with any class).
