Apple

Philippe,

Thanks for your suggestion. I've not looked at CAPThread before so I'll take a look. However, am I write in assuming that the PublicUtility have been dropped in the 10.6 SDK? This would put me off going down this route.

I must admit that I've not yet installed 10.6 :-) Not that I'm not interested, to the contrary, but I don't need it immediately for my job (mainly working on embedded DSPs software at the time).

It seems however that PublicUtility is indeed still available.

You mention that this utility has a similar functionality to that of the CoreAudio IOProc. Is there any info on the core audio system? It would help me understand the underlying API that I seem to be getting into.

Well, CoreAudio and the HAL does much more than CAPThread. CAPThread is "only" a - nice - wrapper around the POSIX threads.

When you create and start your output unit an audio (RT) thread is created on behalf of you by the system. When the CoreAudio layer (the HAL really) needs data from your output unit it wakes up this audio thread which in turn calls the render of your graph's head.

Creating yourself a RT thread that periodically wakes up would mimic this behavior.

If you don't want to go this route (I would understand, playing with threads is not trivial) you could try the suggestion of Jean-Daniel below:

If you don't want to write a null audio device, I have a last idea.
If you want an 'hacky' way to do this, create an audio unit that render 'empty' buffers (or zero filled buffer) whatever the input.
Use AudioUnitAddRenderNotify on the last unit of your graph to intercept rendered data.

I'm currently working on a "proof of concept". As a result I want to perform real-time analysis of the data coming out of an AU network, but I don't actually want an audio output.

Thanks for your help,

In any case don't forget that if you don't want to kill the real-time there's not many OS APIs you can safely call in your real time callback. So if you have to write some results into a file for instance this should (must) not be done from the RT callback. The rule is never call a potentially blocking API from a RT thread (no fread, fwrite, malloc, new...). Instead do a light pre-process of your data and find a non-blocking way - some kind of FIFO - to pass these pre-processed data to a worker thread that will do the analysis in the background.

Darrell.

________________________________________
From: philippe wicker [email@hidden]
Sent: 07 September 2009 12:28
To: Darrell Gibson
Cc: Jean-Daniel Dupas; email@hidden
Subject: Re: Using an AU directly

What you could do is create a time constrained thread (you can use the
PublicUtility/CAPThread wrapper for this purpose), let your RT thread
looping on a pthread_cond_timedwait_relative_np (or use PublicUtility/
CAGuard::WaitUntil() method) and call AudioUnitRender on your AU
when your thread returns from the WaitUntil(). Doing so is somehow
equivalent to what CoreAudio is doing when it calls your IOProc.

Now you'll have to be careful about what kind of job you want to do in
this RT thread loop apart from calling your AU render. Maybe you could
tell us why you need "real time" calls of your AU render and what do
you plan to do with the AU rendered outputs?

Philippe

References:
	>Using an AU directly (From: Darrell Gibson <email@hidden>)
	>Re: Using an AU directly (From: Jean-Daniel Dupas <email@hidden>)
	>RE: Using an AU directly (From: Darrell Gibson <email@hidden>)
	>Re: Using an AU directly (From: Jean-Daniel Dupas <email@hidden>)
	>RE: Using an AU directly (From: Darrell Gibson <email@hidden>)
	>Re: Using an AU directly (From: philippe wicker <email@hidden>)
	>RE: Using an AU directly (From: Darrell Gibson <email@hidden>)