• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Idle processing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.

  • Follow-Ups:
    • Re: Idle processing
      • From: Marc Poirier <email@hidden>
    • Re: Idle processing
      • From: email@hidden
References: 
 >Re: Idle processing (From: Marc Poirier <email@hidden>)

  • Prev by Date: Re: Idle processing
  • Next by Date: Stupid question about cvs and SourceForge.net
  • Previous by thread: Re: Idle processing
  • Next by thread: Re: Idle processing
  • Index(es):
    • Date
    • Thread