Data transfer via Audio channel-miscellaneous

Possible ways the application could be coded:

• I/o Unit Directly
• AVRecorder
• OpenAL
• (it's too complicated, it's like a independent system and I don't have time to look into that.It's more meant for gaming, where you place a moving sound source into a stereo space and take into account of effects like echo and dopler effect and all that.)
• AudioQueueServices

By Making use of AudioQueueCallBack Function(AudioQueueService)
Audio Queu Service might be a better choice if we are not trying to implement bi-directional communication.
The Build in API would take care of the hardware connections automatically. The incoming audio data would stored in buffers, which are queued up. Once a buffer is full, the AudioQueuCallBack function is invoked, to deal with the data inside the full buffer, and clear the buffer for further use.

• Advantage of audioQueueService.
• It's one level up from handling i/o unit directly, there is less coding required.(memory management, signal roughing is all taken care of by API)
• The adjustable buffer size would enables us to find a balance between the latency of  processed signal and overhead of repeated function call.
• Disadvantage of AudioQueueService:
• the latency would make it impossible for us to implement handshaking signal.
• As according to apple documentation, a bufferQueueCallBack is typically invoked every half second to every a few seconds
• even if we shrink the buffer size to reduce the interval between the callBacks, it won't be possible to be invoked like render callback, 

By Making Use of RenderCallBack Function:(i/p Unit Directly)


RenderCallBack function is invoked when a slice of output signal is needed(a pull approach, initiated by output). The input audio data is passed into the renderCallBack function and it would do something with the input and pass it on to the output.
In our case, however, there won't be a audio output, as we are trying to transmit data through audio channel. But we can still make use of the renderCallBack function to have a doSomething function synchronized to input data.

• Core of this idea is that we can configure a dummy output device, with a renderCallBack Function. 
• If the dummy output device and the input device is configured at exactly the same sampling rate. the renderCallBack function would be called synchronized to arrival of every sample we get from the audio input.
• The advantage of this method would be:
• We might have better battery consummations, as the processing is carried out for each of the samples exactly once, and there is no constant monitoring going on in this approach.
• There is possibility for implementing hand-shadking signal for data integrity or two way realtime communication, as the latency for this process is very low. As claimed by apple documentation. 
• The constrains would be:
• The renderCallBack function must be simple enough. Otherwise, we might lose samples.

Notes taking as going along documentations:

• in Multimedia Programing guide
• Audio Session:
• need to set Sample rate, Num of channels and enables inputs
• category, interruption handling and route change is not really applicable
• Playing Audio
• Access iPod library with mediaPicker/ mediaQuery
• Vibration and system sound with systemSoundService
• AVAudioPlayer
• AudioQueueServices
• need to read AudioQueueServiceProgrammingGuide
• OpenAL need to check openAL website
• Recording Audio
• Recorde with AVRecorder
• Recorder with AudioQueueService

Resource would be useful:
Librarys need to be studied:
Audio Unit Component Service
Audio Component Service
Audio Unit Hosting Guide for iOS
Guides:

• AudioProgramingGuide:
• iPhone Recording App:
• Audio Session Programing Guide:

As we are concerning real-time communication. The recorder class won't be able to serve this purpose.

Libraries might be useful:

• Framework: 
• AVFundation
• Classes:
• AVAudioPlayer
• AVAudioRecorder
• AVAudioSessionClass
• AVAudioRecorderDeligate Protocol

For our project:

• AVAudioRecorer and its delicate can be used to perform the recording task
• AVAudioPlayer can be used to playback the recorded track, if needed
• AVAudioSessionClass is needed to get the proper audio related system configurations for the software to run on.

iPhone simulator testing v.s. on-device testing:


In short, we would be able to simulate the software on iPhone simulator, but we won't be able to settle the more 'hardware- related' issue such as when the user plug/unplug a earphone/mic.
Therefore, simulator can be used in the initial phase of the development. And we will have to settle the rest by simulating on a actually device.


I have tried a downloaded project done by someone else on a simulator. The simulator would be able to access the mic on Mac and would be able to replay the recorded sound.


However, there are certain sinarios that cannot be tested on iPhone simulator according to the Developer's Guide:

When running in the simulator, you cannot:

• Invoke an interruption
• Change the setting of the Silent switch
• Simulate screen lock
• Simulate the plugging in or unplugging of a headset
• Query audio route information or test audio session category behavior
• Test audio mixing behavior—that is, playing your audio along with audio from another application (such as the iPod)