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:38:19 +0100
- Acceptlanguage: en-US, en-GB
- Thread-topic: Using an AU directly
Jean-Daniel,
It is not I don't want to write a null audio device, it is more that I'm not sure that know how. Presumably it will need to define things like sample rates, frame rates, data encoding etc. As well as having to manage the "pulling" of data. This is really stuff I'd rather avoid at this stage as I assume it is fairly involved. However, if it is not too difficult I'd appreciate any pointers in how to do this.
Your "hacky" solution sounds reasonable, but does seem in the same league of my original suggestion to connect an output device to my AU network, capture the data coming in to the output in a AudioBufferList and then not allowing the unit to render the data by not calling the AudioUnitRender. This solution would mean I would not have to worry about managing pull, but would get the data I need. Is there a problem I'm not see with this suggestion?
Thanks for any pointers.
Darrell.
________________________________________
From: Jean-Daniel Dupas [email@hidden]
Sent: 07 September 2009 12:24
To: Darrell Gibson
Cc: email@hidden
Subject: Re: Using an AU directly
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.
Insert this null unit between your last unit and the default output.
Le 7 sept. 2009 à 13:12, Darrell Gibson a écrit :
> 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
>
>
-- 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