Re: Audio Units - newbie questions
Re: Audio Units - newbie questions
- Subject: Re: Audio Units - newbie questions
- From: William Stewart <email@hidden>
- Date: Tue, 11 Oct 2005 18:23:41 -0700
On 11/10/2005, at 3:20 PM, Muon Software Ltd - Dave wrote:
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
You should look through AUBase:
// you should look at the implementation of this call in AUBase.cpp
ComponentResult DoRender
( AudioUnitRenderActionFlags & ioActionFlags,
const
AudioTimeStamp & inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames,
AudioBufferList & ioData);
// a whole bunch of comments here
virtual ComponentResult RenderBus
( AudioUnitRenderActionFlags & ioActionFlags,
const
AudioTimeStamp & inTimeStamp,
UInt32 inBusNumber,
UInt32 inNumberFrames)
Essentially, this is the call you need to over-ride.
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 :-)
But are you getting sound out correctly on each of your output buses?
I think it might kind of work because AUBase's RenderBus call will
ONLY call your render call once and I suspect almost by accident it
might be getting the output data because of what you're doing with
the element's buffer lists. I would certainly not want to guarantee
that this would always work.
You've essentially got the right approach I think (ie you calculate
all your data into an array of channels), but it should be integrated
into the AUBase semantics more robustly.
We're going to cleanup some code we have that demonstrates how to do
this and try to get this out soon (I'll try and send you a copy
privately before then, so you can see how we're handling this)
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?
Yes - that tells you when you have to render new data - with multiple
buses that's important.
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.
Sure - but why should you crash? You should certainly not be
initialising yourself.
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 :-)
If I can't do something sensible with your plugin between open and
init, then why would we have bothered discriminating between these
two states?
Some hosts, in order to streamline the user experience, wanted to
manage resources in use at any given time. So, they spent
considerable time optimising their own engines and DSP processes,
etc. One step they wanted to take was to place AUs in a quiescent
state, but NOT close them, when some part of the mix was not in use -
lets say the track was made inactive. The user can still see the AU,
the and AU's view may indeed still be open. Interacting with it may
be a meaningless gesture, but at least the view should open/close
properly, and perhaps even allow some basic manipulations.
The AU Semantic we defined for this was Initialisation - so, the host
apps concerned would try to uninitialise the AUs that were in this
place, only to find that they would crash.
This was so poorly both understood and supported by AUs that the
feature was essentially dropped. Which is a shame to our minds,
because this is one of the uses we had envisaged when we
discriminated between these two states.
In the AU documentation, this is discussed. AU Lab added a debug menu
so you can test out your plugin in an uninitialised state. We would
love to see AU developers take this into account.
void CMuonTachyon::Cleanup()
{
???
}
I'm not familiar with that function. Is it necessary to override
it? we
currently do all cleanup in the destructor.
Please read the documentation about the states of AUs.
It is basic to the design of AU's that the states are properly
tracked. For instance, uninitialising and re-initialising an AU are
done when reformating the AU is desired (even if this is only a
sample rate change). If you aren't allowing your initialised state to
be cleared by Uninitialise, then many operations are no longer
possible. auval will also test this path, so this should be causing
you problems already.
Bill
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
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
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