Re: Problem with AUParameterSet
Re: Problem with AUParameterSet
- Subject: Re: Problem with AUParameterSet
- From: William Stewart <email@hidden>
- Date: Thu, 22 Feb 2007 12:56:06 -0800
On 22/02/2007, at 11:43 AM, Eric Johnson wrote:
On Feb 21, 2007, at 7:23 PM, William Stewart wrote:
I'm concerned about doing VU Meters this way - it seems to me
from your description that you would be changing the parameter
value in your render call - if that ends up sending a
notification each render call that is alot of notifications. VU
Meters are better done by marking the parameter as a VU meter and
then having the view poll for its value a few times a second to
draw it (this is how we do the meters in the compressor/limiter AUs)
Yes, there is definitely merit to the approach you suggest. We
are using an event-driven system along with a technique of
reducing the number of messages sent. Whether that system is any
better than polling remains to be seen . . .
Finally, I'm also confused about your comments about stopping the
time line and showing problems in AULab - AULab does have a
transport, but it doesn't have a timeline and has no notion of
feeding silence to an AU. I'd be happy to look at this if you can
see a problem in AULab and we can reproduce it here.
This is contrary to what I have observed. (I'm using AULab
1.0.3.) I can create a simple AULab project consisting of an
AUAudioFilePlayer, then insert one of our AU plugins. As long as
the audio engine is running, I can set a breakpoint in
ProcessBufferLists and the breakpoint will be triggered regardless
of whether the transport is playing or paused.
Yes
When the audio engine is stopped, (by clicking in the area that
says "Audio Engine Running") ProcessBufferLists is no longer
called. It sure looks to me like AULab feeds silence when the
audio engine is running.
No - when the engine is stopped it should be completely stopping
the I/O cycle on the device - so your AU will be getting no calls
at all to render. If it doesn't do that and you are getting calls
with that stopped then that is a bug we'd definitely want to look at.
At this point, the code is working, but it would be nice to know
why AudioUnitSetParameter followed by AUParameterListenerNotify is
not the same as simply calling AUParameterSet. If I am
misinterpreting AU Lab's behavior that would be nice to know too.
Lets file a bug with some example code to reproduce this. Here is
what the basic implementation looks like for both methods (as you
can see there's no real difference):
OSStatus
AUParameterSet( AUParameterListenerRef inListener,
void * inObject,
const AudioUnitParameter * inParameter,
Float32 inValue,
UInt32 inBufferOffsetInFrames)
{
CheckNull(inParameter);
const AUParameter &aup = *static_cast<const AUParameter *>
(inParameter);
OSStatus err = aup.SetValue(inValue, inBufferOffsetInFrames);
if (err) return err;
return ListenerMap::Instance()->NotifyParameterChange(inListener,
inObject, aup, &inValue);
}
OSStatus
AUParameterListenerNotify( AUParameterListenerRef inListener,
void * inObject,
const AudioUnitParameter * inParameter)
{
CheckNull(inParameter);
const AUParameter &aup = *static_cast<const AUParameter *>
(inParameter);
return ListenerMap::Instance()->NotifyParameterChange(inListener,
inObject, aup, NULL);
}
Thanks
Bill
--
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