Re: AU question: asynchroneous pulling
Re: AU question: asynchroneous pulling
- Subject: Re: AU question: asynchroneous pulling
- From: William Stewart <email@hidden>
- Date: Tue, 19 Oct 2004 13:35:04 -0700
On 19/10/04 12:05 PM, "Thorsten Karrer" <email@hidden> wrote:
> Hello!
>
>
> Thanks for your help! But I have still some questions left.
>
> Am 19.10.2004 um 20:23 schrieb William Stewart:
>> You can't do it this way.
>> The intention of I/O is that it is synchronous - each request someone
>> makes
>> for output, you get the input required for that....
>> So - for an effect this means *always* that a host pulls you for 512
>> frames,
>> and you ask for 512 frames of input. The reason this is this way is
>> that we
>> treat effect types of AU as something that operates in "real-time" -
>> so you
>> can't just asynchronously ask for input - if its real-time the input
>> isn't
>> there!
>
> Hmm...I thought that is the way the Varispeed AU is working. From my
> understanding it must pull it's input for a different amount of samples
> than the host pulls the output of the Varispeed.
> I did declare my AU as an "aufc", so I thought I would be able to do
> that kind of stuff.
You can pull for different numbers of samples if you are an aufc. Yes. But
the varispeed does two things that you aren't:
(1) It can pull multiple times to honour the max frames per slice
restrictions
(2) It will calculate for a given output request, what input it needs to
satisfy that - then it asks for that input.
So, essentially it obeys the same synchronous relationship between in and
out, its just that the number of input samples can vary based on the rate
parameter's value.
>
>>> Problem2:
>>> Thread1 has to pull a lot of samples at one time, since my effect is
>>> based on a FFT of size 4k. Usually the input is not able to provide
>>> such a large chunk of samples so I decided to split up the pulls into
>>> pieces of length of the number stored in the MaxFrames property of the
>>> input...
>>
>> You use your max frames for this - we assume that a host will
>> generally set
>> max frames consistently between different audio units, so its a
>> reasonable
>> assumption that your input's max frames is the same as yours. You can
>> also
>> have input coming from a callback, so you can't get max frames in that
>> case.
>
> Ok, I tried to get my max frames using the code snippet below:
>
> UInt32 MaxFrames;
> result = GetProperty(kAudioUnitProperty_MaximumFramesPerSlice,
> kAudioUnitScope_Global,
> 0,
> &MaxFrames);
>
> But all I get is result == kAudioUnitErr_InvalidProperty
AUBase has a GetMaxFrames call - that's the call you should be making.
The reason this is failing is that GetProperty is only dispatched too when
its *not* a property that is supported in AUBase. If the property is
supported in AUBase, then it is handled in the DispatchGetProperty call -
you can trace through the code if you look for that property ID to see how
this works
Bill
>
>
> Thanks again for helping!
>
> Best regards,
>
> Thorsten
>
>
> _______________________________________________
> 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
__________________________________________________________________________
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
__________________________________________________________________________
_______________________________________________
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