RE: Audio Units - newbie questions
RE: Audio Units - newbie questions
- Subject: RE: Audio Units - newbie questions
- From: "Muon Software Ltd - Dave" <email@hidden>
- Date: Tue, 11 Oct 2005 23:20:50 +0100
- Importance: Normal
> Nope - when the client calls an AU's render call it provides all the
> information:
> The buffer to put the data in
> the time stamp
> the number of frames
> the output bus number
The Render call though only has a handful of parameters:
ComponentResult CMuonTachyon::Render( AudioUnitRenderActionFlags
&ioActionFlags, const AudioTimeStamp &inTimeStamp, UInt32 nFrames )
I've been calling Outputs().GetNumberOfElements() to find the number of
busses at the top of the render call, then going through each bus and doing
something like this:
AUOutputElement* ptrOutput = GetOutput(i);
AudioBufferList& bufferList = ptrOutput->GetBufferList();
Once I've got a buffer list for each buss I build a list of pointers to pass
to my synth, which expects pointers to 8 mono buffers to render into. It
isn't fussy if the pointers are aliased, so if I wanted to render to a
single stereo output, I pass in the two real buffer pointers that I got from
the bus in my pointer array at 0,1 then 2,3 etc.
Is this hopelessly incorrect then? I'm certainly getting sound out :-)
> The AU can determine from its input settings (an AU knows what inputs
> are connected, and what aren't), and presumably from its UI (say
> which effect/send buses are patched in), exactly what data it needs
> to calculate for any given render call - so the above render loop can
> of course know what work it needs to do.
So I'm supposed to keep track of the timestamp and watch out for it changing
from one Render call to the next?
> It can be called anytime from the API - if you aren't initialised
> when you are called, then just don't do anything.
Why would a host call Reset on a plugin that it has not previously called
Initialize on? that's absurd - the plugin hasn't necessarily had sufficient
time to set itself up.
> You should fix this. In fact, I think auval might even try to test
> this case - if it doesn't it will be soon :-)
Well hang on a minute - why would a host need to call methods on AUs that
aren't initialised? what we do in our code isn't absurd, it just assumes a
logical sequence:
1. Construction (do nothing much)
2. Initialisation (do the heavy stuff)
3. Be ready for anything :-)
> Why - you think its better that you crash?
Not at all - the code currently *doesn't* crash - but only if I'm lucky and
Reset gets called before some other method comes stomping in.
> You could use AUBase's IsInitialised call to keep this state.
OK
> ????
>
> Why are you initializing (and crashing) here.
I'm not crashing there, because I've detected that the host hasn't called
Initialize yet and for reasons unknown it is trying to call methods on my
plugin before it has had chance to set up. By calling Initialize there
myself I'm working around Intialize not being called in what I would say is
the right order of thigns.
>
> Where do you handle the cleanup code? (this is where your
> m_bInitialised would be set to false)?
>
> void CMuonTachyon::Cleanup()
> {
> ???
> }
I'm not familiar with that function. Is it necessary to override it? we
currently do all cleanup in the destructor.
Regards
Dave
_______________________________________________
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