Re: kAudioUnitProperty_Latency and AUPeakLimiter
Re: kAudioUnitProperty_Latency and AUPeakLimiter
- Subject: Re: kAudioUnitProperty_Latency and AUPeakLimiter
- From: Bjorn Roche <email@hidden>
- Date: Thu, 2 Aug 2007 09:44:06 -0400
William,
Thanks for your reply, and especially the suggestion about updating
when parameters marked kAudioUnitParameterFlag_NonRealTime change.
However, I want to be very clear that I think this is a bug and why,
so forgive me if I belabor this point a bit...
On Aug 1, 2007, at 2:30 PM, William Stewart wrote:
its a bug (or maybe feature) - the latency for this AU is based on
the value of the kLimiterParam_AttackTime parameter (and it isn't
being updated). This parameter is marked as
"kAudioUnitParameterFlag_NonRealTime"
- the host app asked to be notified about changes to a certain
property. no error was returned.
- the property changed, but the host received no notification.
There is effectively no way to register a listener for
kAudioUnitProperty_Latency, because registering has no effect. Bug.
There are other parameters in Apple's (and others I am sure) AUs
that have similar characteristics. The time pitch is one,
parameters on reverbs and delays will change the "TailTime" and in
general it hasn't been our practise to issue notifications for
changes in these properties based on parameter value changes.
The problem for most host apps is that when the latency changes it
requires some reconfiguration of the rendering engine if you are
going to do anything about it and that will introduce glitches.
The fact that the audio unit programmers thought to themselves "ah,
but if I fire this event, a host might glitch" is completely
irrelevant -- especially when you consider the fact that the audio
unit glitches when that property is changed anyhow! If the host
didn't want notifications, it wouldn't have asked! Why not give the
host a little credit, and let them decide when and how to deal with
changes?
For my present purposes, I don't need to "reconfigure my rendering
engine", but even if I did, I would at least want to know when and if
I had to, so that I could do it as soon as possible and only when
necessary. Consider this: playback will be different when the host
finally does get around to reconfiguring the rendering engine. Since
there is no way of knowing when the rendering engine needs to be
reconfigured (because the rendering engine will never receive
notification to that effect), some apps may not do it until, say, the
file is saved and reopened, at which point they will reread the
latency parameter, and, since it's different, they will compensate
differently from how they compensated before and suddenly the session
sounds different from when they saved it! Depending on the latency
change, this could effect phase or even musical timing, which I think
is pretty serious.
Finally, what if the host WANTS to "reconfigure the rendering engine"
during playback? Sure, that would be hard, and sure, it probably
would introduce some sort of glitch, but that's a design decision the
host should make, not one the Audio Unit should make.
Obviously, the same thoughts would apply to tail time, and whatever
other events are not delivered.
You can certainly file a bug, but I'm not sure whether we'd fix it
(and it would in any case remain a problem on Tiger).
Bug # 5378746
If you want to be able to respond to changes like this, then I
think a rule of thumb that you could apply would be that anytime a
parameter marked with this flag
(kAudioUnitParameterFlag_NonRealTime) could change Latency or Tail,
so you could reassess at that point. For parameters not marked with
this flag, I don't think you would need to do that work.
Thanks again for this suggestion -- I will certainly use it. I assume
there are no other changes hidden by
kAudioUnitParameterFlag_NonRealTime?
bjorn
-----------------------------
Bjorn Roche
XO Wave
Digital Audio Production and Post-Production Software
http://www.xowave.com
http://blog.bjornroche.com
http://myspace.com/xowave
_______________________________________________
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