Re: Idle processing
Re: Idle processing
- Subject: Re: Idle processing
- From: Glenn Olander <email@hidden>
- Date: Mon, 24 Feb 2003 22:30:09 -0800
The low-priority tasks I'm referring to are generally
presentation of non-critical information to the user like status
displays and meters. This information should be presented to the
user, but is lower priority than audio processing, so it should
be performed only if time is available after doing audio processing.
To implement such a thing, two elements are required:
1) A way to convey information from the model layer to the view layer
2) A way to schedule the low priority task so it doesn't interfere
with the higher priority task of audio processing.
Number one can be accomplished by the plugin with a variety of
mechanisms including message queues and property queries (triggering
a GUI update from the audio thread would be a bad thing indeed!). Number
two however, requires the supervision of the host. Only the host
knows how busy it is, and therefore whether low priority tasks should
be scheduled or not. The result is that low-priority tasks will be run
less frequently when cpu load is heavy.
This isn't really a VST-ism, but rather is the nature of many real-time
systems. All sequencers have such a system built-in for updating their
own displays. On the mac, this typically happens by running the high
priority thread at interrupt level and letting MacOS run the
low-priority thread between interrupts.
So, is it true that there is no such priority scheduling
of tasks in audio units?
- Glenn
Marc Poirier wrote:> RMS Buddy actually does not do what Glenn is trying
to do, unfortunately.
I think that I know specifically what Glenn is after, coming from VST
experience just like he is. The VST editor API includes an idle method
which your editor can override. It will get called whenever the host
feels like it, but the basic idea is that it will get called pretty
regularly, but probably not so regularly if your system is under a really
big CPU load. The idea is that the calls occur in a low priority thread
and that the host manages how often they happen, so that those idle
updates can be deferred when the audio demands are high.
In comparison, what I do in RMS Buddy is to reconcile messaging from the
audio thread to the GUI thread by posting notification from the audio
thread via the ParameterListener system (where the messages enter a queue
rather than triggering the GUI reaction from the audio thread) and then
retrieving the actual data via custom property getting (which is an
immediate event, but which is then done from the GUI thread, when the
notification is read from the parameter listener event queue).
However, after writing all of this, I now realize that probably the
question to ask is: Glenn, why exactly do you want a VST-like idle
method? I know that in my experience, I've always used that method to do
some sort of polling, to check on some state to see if it changed, to get
new information when available, etc. But with AU, we have these property
notification and parameter notification mechanisms that are really nice
and eliminate the need for any of that polling. It's a much better way to
do all of that stuff. So anyway, if that sort of polling is what you are
wanting to do in your idle calls, then perhaps it's worth reconsidering
and instead using the better capabilities that AU provides. In which case
RMS Buddy actually would provide useful example code. ;)
Marc
On Mon, 24 Feb 2003, Bill Stewart wrote:
Marc Poirer just released some code that I think is exactly what you
are looking for...
See the message with the subject:
ANN: RMS Buddy AU, public example code, props to CA team
Bill
On Monday, February 24, 2003, at 09:37 AM, Glenn Olander wrote:
I may be overlooking something, but I can't find any support
in AU for idle processing, in other words a way to run non-
critical tasks like GUI updating. Is there such a service?
I can, of course, just run my own event loop timer, but idle
processing needs to be adaptive...it should be called less
frequently if the audio engine is busy, so the host should
take that responsibility.
- Glenn
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.