• 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
Threading issues in parameter changes
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Threading issues in parameter changes


  • Subject: Threading issues in parameter changes
  • From: Andrew McPherson <email@hidden>
  • Date: Tue, 20 Jun 2006 16:58:30 -0400

This is a somewhat esoteric question that has to do with threading in the AU processing code. The short version: can a parameter change take place between the time the first and last kernels associated with an AU effect process a particular slice of audio?

The long version:

As I understand it, an AU effect may have multiple instances of the processing kernel for handling multiple channels of audio. Presumably, when a slice of audio is processed, the CoreAudio code calls each kernel in sequence to do its processing.

Now what I want to do is to have each kernel know when a parameter has been changed. Because my AU uses a lot of parameters, it is computationally expensive to store all the previous values and check them on every slice. So what I've done is override the SetParameter methods in AUEffectBase and AUBase to set a flag saying something has been changed. (Is this legit?) Then the kernels call methods in my main AU class to check the value of the flag, and clear it if necessary.

The problem is that I want each kernel to get the message exactly once. If I have a kernel check the flag and clear it if it has been changed, then only the first kernel is going to notice the change. What I'm thinking of doing instead is having only the last kernel clear the flag (checked with the IsLastKernel() method of AUKernelBase).

I could imagine a situation, though, where a parameter change takes place between the time of the first kernel and the last kernel processing a slice, where not all of them would get the message. So can I assume that all parameter changes come between slices of audio and can never pop up in the middle of a slice? If not, how would I tell every kernel that a parameter change has taken place? (Seems like the listener methods are more designed for UI components.)

Thanks for any suggestions,
Andrew
_______________________________________________
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


  • Follow-Ups:
    • Re: Threading issues in parameter changes
      • From: Doug Wyatt <email@hidden>
  • Prev by Date: Re: Monitoring input level
  • Next by Date: Re: Monitoring input level
  • Previous by thread: Re: Don't exchange pointers
  • Next by thread: Re: Threading issues in parameter changes
  • Index(es):
    • Date
    • Thread