IOS audio: audio recording and sound mixing-Q &

1. Reading my code for recording

* Myinputbufferhandler

Q: There is an enqueue Buffer Action. In this way, this buffer has the opportunity to refill.

A: Yes !. There will always be enqueue actions in callback, regardless of recording or playback.

Q: parameter description

Voidaqrecorder: myinputbufferhandler (

Void * inuserdata,

Audioqueuerefinaq,

Audioqueuebufferrefinbuffer,

Constaudiotimestamp * instarttime,

Uint32 innumpackets,

Constaudiostreampacketdescription * inpacketdesc)

The description of innumpackets is as follows:

InnumberpacketdescriptionsIs the number of packet descriptions ininPacketDescsParameter.
If you are recording to a VBR (variable bitrate) format, the audio queue supplies a value for this parameter to your callback, which in turn passes it on toAudioFileWritePacketsFunction.
CBR (constant bitrate) formats don't use packet descriptions. For a CBR recording, the audio queue sets this andInpacketdescsParameterNULL.

Therefore, it seems that the value here should be null, but this is not the case,Why?

* Initnewplaybackqueue

Q: cfrunloopget? What are the things like current? Does it seem to be related to the thread's runloop?

Xthrowiferror (audioqueuenewoutput (& mdataformat, aqplayer: aqbuffercallback, this,

Cfrunloopgetcurrent (), kcfrunloopcommonmodes, 0, & mqueue), "audioqueuenew
Failed ");

2. Reading "audio Queue Service Programming Guide" + "audio queue service reference"

* Multi queues

Audio queue services also supports scheduled playback and synchronization of multiple audio queues and synchronization of audio with video.

Q: Could be used to do "mixing "?

Q: should we use audio queue service instead of audio unit in our VoIP-like applications ???

* Callback invoking

During recording or playback, an audio queue callback is invoked repeatedly by the Audio queue that owns it. The time between CILS depends on the capacity
Of the audio queue's buffers and will typically range fromHalf a secondTo several seconds.

^ Too slow ???

Enqueue Buffer: always done by call back function.

* Call back

# For recording,

Sends the audio data collected by the Audio queue from the input device in the buffer to the application, such as writing disk or

Add the buffer to the queue and wait for audio queue to fill again.

Note: The buffer obtained by call back has audio data, waiting for subsequent processing, such as sending the data to the network.

# Playback

Responsible for transferring data to fill audio data in the audio buffer

Push audio buffer into audio queue and wait for playback

Note: The buffer obtained by call back is empty, waiting for fill

3. Reading "audio unit hosting guide for iOS"

Audio units provide fast, modular audio processing

The two greatest advantages of using audio units directly are:

• Excellent responsiveness. because you have access to a realtime priority thread in an audio unit render callback function, your audio code is as close as possible to the metal. synthetic musical instruments and realtime simultaneous voice I/O benefit the most
  From using audio units directly.

• Dynamic Reconfiguration. The Audio Processing Graph API, built aroundAUGraphOpaque
  Type, lets you dynamically assemble, reconfigure, and rearrange complex audio processing chains in a thread-safe manner, all while processing audio. This is the only audio API in IOS offering this capability

Q: Does this mean for VoIP application, we can only use audio unit rather than audio queue service?