Re: Is AUVarispeed reentrant
Re: Is AUVarispeed reentrant
- Subject: Re: Is AUVarispeed reentrant
- From: William Stewart <email@hidden>
- Date: Fri, 23 Jan 2009 12:56:31 -0800
You call an audio unit to do render and that is considered to be an
atomic, single threaded operation from the caller's point of view. The
AU may call out (either through host callbacks or input callbacks/
connections or render notifications) and you can call back into the AU
for various things (say the value of a parameter for instance)
The varispeed can be connected to another instance of a varispeed,
control it independently, etc and I don't know of any problems with
this - you can host multiple varispeeds in AULab to test this if you
want external verification
So, from the basic point of view, there shouldn't be anything wrong
with your scenario
Bill
On Jan 23, 2009, at 8:40 AM, Mike Kluev wrote:
Are there any known issues with AUVarispeed reentrancy? I have
a non trivial case when inputProc of one varispeed unit may call
render->inputProc for another varispeed unit, etc. If I change
AUVarispeed to AUConverter it works correctly. It also works
correctly with another code path that is based on AudioConverter.
With AUVarispeed my output is somewhat damaged. I haven't
canonize it yet to a minimal sample that reproduces the problem.
Mike
_______________________________________________
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
_______________________________________________
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