Re: Discussion: Scheduling AU parameter changes, both MIDI
Re: Discussion: Scheduling AU parameter changes, both MIDI
- Subject: Re: Discussion: Scheduling AU parameter changes, both MIDI
- From: William Stewart <email@hidden>
- Date: Wed, 5 Jul 2006 14:19:51 -0700
On 04/07/2006, at 2:43 PM, Ian Kemmish wrote:
On 4 Jul 2006, at 8:02 pm, Brian Willoughby <email@hidden>
wrote:
My current understanding is that there is no way to schedule a
parameter
change beyond the current buffer being rendered in an AU.
I think it's slightly more complicated than that. All the routines
with an "inOffsetSampleFrames" parameter are called before your
Render routine is called, and therefore at a time when your AU
doesn't yet know how long the buffer to be rendered is going to be.
So the AU must be able to queue events up to the current *maximum*
number of frames. If, as is frequently the case, the buffer it's
actually called upon to render turns out to be shorter than the
maximum, the AU needs a strategy for dealing with orphaned events -
as a safety net if for no other reason.
Sure - but that would be a pretty broken host - in order for a host
to calculate sample offsets it probably also needs to know the
duration of the next call to the AU's render call.
1) Ignoring them is probably bad both for the user and for the AU.
2) Explicitly discarding them is bad for the user.
3) Pretending they all happen at the end of the actual buffer to be
rendered is somewhat better.
4) Rolling them over into the next (or subsequent) buffer(s) to be
rendered is best for the user (assuming that the host hasn't
started misbehaving and issuing dud calls), but may be difficult
for some AUs to implement.
We don't support this behaviour and would consider this to be out of
spec.
It may be true that no host *should* issue parameter changes
scheduled beyond the end of the next buffer to be rendered, but
since I can't remember finding any strictures in the documentation
on that point, I had to put in code to cope with it anyway.
Hmm... a simple question to this list would have clarified your
concerns, but its always reasonable to guard against a bad function
parameter particularly if that can have bad affects in your code.
I assume that similarly paranoid AUs will behave in a similar way.
So, amending the spec. here may be something that's easy to do, if
enough people feel it's useful.
I don't understand the need to ammend the spec here. We've been I
think quite clear on our expectations here.
This issue is discussed at:
file:///Developer/Examples/CoreAudio/Documentation//AudioUnits/
index.html
In the "Audio Unit Parameters" section
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