RE: Using an AU directly
RE: Using an AU directly
- Subject: RE: Using an AU directly
- From: Darrell Gibson <email@hidden>
- Date: Mon, 7 Sep 2009 21:12:12 +0100
- Acceptlanguage: en-US, en-GB
- Thread-topic: Using an AU directly
Philippe,
Thanks for this valuable info. Jean-Daniel has confirmed that the CAPThread utility is still available in the 10.6 SDK so this is definitely something I'm going to look at. I think to start with I'll have ago at the "hacky" methods and then have ago at getting a RT thread working.
Thanks for the tips about the audio threading system. It has at least given me a starting point, but I now have lots more questions. I don't supposed there is any more detailed documentation on the threading system? I don't recall anything about this in the Core Audio docs, but I may have missed it.
Thanks again for your help,
Darrell.
________________________________________
From: philippe wicker [email@hidden]
Sent: 07 September 2009 15:57
To: Darrell Gibson
Cc: email@hidden; Jean-Daniel Dupas
Subject: Re: Using an AU directly
On 7 sept. 09, at 14:50, Darrell Gibson wrote:
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 that, 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 to pass these pre-processed data to a worker thread that will do the analysis in the background.
Darrell.
________________________________________
From: philippe wicker [email@hidden<mailto:email@hidden>]
Sent: 07 September 2009 12:28
To: Darrell Gibson
Cc: Jean-Daniel Dupas; email@hidden<mailto: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
On 7 sept. 09, at 13:12, Darrell Gibson wrote:
Jean-Daniel,
Thanks again for your thoughts. This was actually the first thing I
tried and it does not work (or at least I could not get it to
work.) My understanding is (and it may be wrong) it is the output
"device" that initiates the "pull" and not the output "unit". As
the GenericOutput does not have an associated "device" it will not
"pull" any data. Correct me if I'm wrong?
I guess what I need to do is to mimic the functionalty of an output
"device" without sending it any data to process. Does that sound
reasonable? It sound resonable to me, but I'm unclear on what I
need to do in order to implment this.
Thanks again for your help,
Darrell.
________________________________________
From: Jean-Daniel Dupas [email@hidden<mailto:email@hidden>]
Sent: 07 September 2009 11:30
To: Darrell Gibson
Cc: email@hidden<mailto:email@hidden>
Subject: Re: Using an AU directly
OK, so I give another shoot :-)
I didn't test it but I think you can create an 'null' Output Unit
using the kAudioUnitSubType_GenericOutput which does not render at all
but will pull data if you start it using with AudioOutputStart()
Add a render hook on your last unit before the output unit using
AudioUnitAddRenderNotify(). Start the output, and see if it works.
Note: See CAAudioUnitOutputCapturer.h in the PublicUtility folder.
Le 7 sept. 2009 à 12:07, Darrell Gibson a écrit :
Jean-Daniel,
Thanks for your reply. I had not thought of just calling the
AudioUnitRender() when I want to process data. However, I still
want the AUs operation to be performed real-time. My current
understanding is that a render callback will be executed by a
separate thread. Surely if I just call the AudioUnitRender() in a
loop from the current thread I'm like to run into potential timing/
breakup issues?
I still want the AU to process data in a normal realtime manner. I
just don't want to have an output.
Thanks for your help.
Darrell.
________________________________________
From: Jean-Daniel Dupas [email@hidden<mailto:email@hidden>]
Sent: 07 September 2009 10:28
To: Darrell Gibson
Cc: email@hidden<mailto:email@hidden>
Subject: Re: Using an AU directly
Le 7 sept. 2009 à 11:07, Darrell Gibson a écrit :
Hi All,
Following on from a previous post (http://lists.apple.com/archives/Coreaudio-api/2009/Aug/msg00179.html
).
I am now trying use an AudioUnits directly on its own, without an
AUGraph. What I effectively want to do is send audio data into the
AudioUnit, let the audio unit process the data and then obtain the
processed data. (I just want the data, I don't actually want an
audio output.)
In order to do this what I have done is created an instance of the
AU and then setup an input render callback that supplies the input
data. The problem I have is without an output device to initiate
the "pull" my render callback is never called. If I connect an
output unit it does start to "pull" but I also get an output, which
I do not want. I want to analyze the output, but not listen to it.
Is there away to start a network of AUs that has does not been
connected to an output device? By start I mean initiate the "pull".
If not would I have to connect to an output unit, capture the data
coming in, but not allow the unit to render the data? Could I do
this by setting up a render callback for the output unit, write the
input into an AudioBufferList and do not call the AudioUnitRender
function? Does this sound reasonable?
I assume I can have an AU connected to another AU and still define a
render callback for the last AU? Will this work?
Thanks for any pointers you can offer.
Just a side note. If you have 10.5, you can have a look at the /
Developer/Examples/CoreAudio/PublicUtility/CAAUProcessor.h class.
It's
a class design to do offline rendering (what you're trying to do).
Unfortunately this class is no longer part of the CoreAudio SDK (in
10.6)
BU - the UK's Number One New University
The Guardian University Guide 2009 & 2010
This email is intended only for the person to whom it is addressed
and may contain confidential information. If you have received this
email in error, please notify the sender and delete this email,
which must not be copied, distributed or disclosed to any other
person.
Any views or opinions presented are solely those of the author and
do not necessarily represent those of Bournemouth University or its
subsidiary companies. Nor can any contract be formed on behalf of
the University or its subsidiary companies via email.
-- Jean-Daniel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden<mailto:email@hidden>)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden<mailto:email@hidden>
_______________________________________________
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