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 13:50:08 +0100
- Acceptlanguage: en-US, en-GB
- Thread-topic: Using an AU directly
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.
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.
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,
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
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]
> Sent: 07 September 2009 11:30
> To: Darrell Gibson
> Cc: 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]
>> Sent: 07 September 2009 10:28
>> To: Darrell Gibson
>> Cc: 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)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to 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