Re: using audio units from a command line utility
Re: using audio units from a command line utility
- Subject: Re: using audio units from a command line utility
- From: Brian Willoughby <email@hidden>
- Date: Wed, 16 Apr 2008 20:27:38 -0700
On Apr 16, 2008, at 14:53, Ashley Allen wrote:
I'm creating a command line utility in C that will create an audio
graph of file player units that will compile and mix a group of
audio files to a single file. Is there an event loop API call I can
make to wait for the audio units to complete there task before
exiting? Otherwise, I think my command line utility will simply
exit before completion.
You will need to coordinate between the routine which pulls from the
graph versus your file player units, because the latter are where
you'll know when they've reached the end of their input files. If
the files vary in length, then you have the complicated situation
where you need to wait until the longest file has been completely
read, making sure that silence is produced for the tail of any
shorter input files. In addition, you'll need to allow for the
latency and tail time of the longest path through your graph
(assuming you have AudioUnits besides simple mixers - e.g. reverb -
in the signal path).
Take a look at the RecordAudioToFile sample code for a hint or two.
It uses AudioOutputUnitStart() and AudioOutputUnitStop() to control
the flow. It's a bit different than your utility, because it uses an
output unit to grab audio from an input device, while you have files
both on input and output. There still might be some useful code in
there once you look around.
In your case, you'll have to predict the minimum number of samples
needed for a complete output file, and then make sure that your loop
which calls ExtAudioFileWriteAsync() allows the process to continue
until at least that minimum number of samples have been pulled.
After you've processed the minimum number of samples, you should stop
pulling from the graph and fall out of the loop. There might be a
few too many samples in your output file, depending upon the block
size processed by your graph, but that should not be a problem so
long as your input routines provide silence after the input file
length has been exhausted. Since you don't want to cut off any extra
samples introduced by plug-in latency or tails, you should probably
design a little overshoot at the end. This is how most DAW software
works, in practice. You almost always end up with a few extra
samples when you bounce.
Brian Willoughby
Sound Consulting
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden