Re: Problems with AUPitch and sample rate (perhaps S/R change problems in general)
Re: Problems with AUPitch and sample rate (perhaps S/R change problems in general)
- Subject: Re: Problems with AUPitch and sample rate (perhaps S/R change problems in general)
- From: "B.J. Buchalter" <email@hidden>
- Date: Mon, 17 Jul 2006 14:33:10 -0400
- Thread-topic: Problems with AUPitch and sample rate (perhaps S/R change problems in general)
Hi Bill,
>> Turns out that this changes the Sample rate only on the 0 element
>> of the
>> output scope (in the AU SDK, the code says that this is a
>> "convenience"
>> alias to the output).
>>
>> IMO, this is a bug in the AU base classes. If I change the SR
>> globally on a
>> AU, the AU base classes should automatically scan over all valid
>> scopes and
>> elements and apply the SR change to all of them.
>
> No, its quite deliberate.
>
> A sample rate (just as with any other format characteristic) is
> explicitly related to the particular scope/element. There is no
> general concept of an AU's global sample rate.
>
> A couple of cases can illustrate this:
> (1) Some of Apple's format converters can take a different sample
> rate and thus perform a sample rate conversion between an input and
> an output sample rate
> (2) Apple's 3DMixer will allow inputs to have a different sample rate
Well, then I would submit that the base class should return an error if the
property is changed on the global scope. Then it would be clear that it
doesn't do what you would think it does (i.e. Globally change the sample
rate of the Plug-in). Either the global scope sample rate is global or its
not. It shouldn't be the output scope sample rate.
So it seems to me that changing the sample rate on the global scope of a
plug should either:
1) Change the sample rate on all scopes and elements.
-or-
2) Do nothing and return an error.
Option (3): change it on element 0 of the output scope, is just weird and
misleading.
If there is no intention to change this or consider it a bug, then this
weird aliasing should be documented clearly, as well as the requirement to
change the sample rate on all scopes when changing the sample rate on a plug
that only appears to have a global rate. Otherwise you can test and
everything seems to be working, but it is still not correct.
I guess since this is compiled into a bunch of plugs, really the only thing
to do is document it.
Clearly doing the right thing is not that tough, but also not completely
obvious...
BR,
B.J. Buchalter
Metric Halo
5 Donovan Drive
Hopewell Junction, NY 12533 USA
tel +1 845 223-6112
fax +1 603 250-2451
_______________________________________________
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