• 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: AU Threading Question
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AU Threading Question


  • Subject: Re: AU Threading Question
  • From: Brian Willoughby <email@hidden>
  • Date: Fri, 08 Apr 2011 14:38:58 -0700


On Apr 8, 2011, at 10:03, Stephen Blinkhorn wrote:
I don't really like the NSTimer approach and I did switch to using a PropertyChanged mechanism at one point but the overall effect wasn't as 'smooth' from the user's point of view. I might try that again quickly as on paper it seems like a better approach.

Perhaps you can use a combination of both approaches. Use PropertyChanged to move the data from the AU engine to the Cocoa view, then use NSTimer to smooth out the actual display updates. This approach does allow for visual aliasing, or strobing, but perhaps it would look better overall.



My main concern is that I'm experiencing occasional audio glitches and stuttering (although no one else has ever complained about this). I've taken care to make sure I'm not doing any memory allocation via malloc or new during render calls (I use placement new using a preallocated memory block) but I've noticed that the GUI also tends to 'hang' during these periods of glitching/ stuttering and I'll get a CPU spike.

If your problems are easily reproduced, then you could try removing all meter code from your Render via #if 0 ... #endif. This should allow you to isolate whether you're doing anything problematic in your Render call.


Have you tried redesigning your code so that you avoid "placement new" as well? I've never found a need to allocate *anything* in my AU Render calls, so that makes me suspicious even of placement new. I have found that sticking to plain C, even though the overall object is C++, serves me well.

So the reason I asked the original question was to get a better understanding of how threading works in an audiounit/host context and to make sure that I'm not doing anything via the GUI that could cause the Render thread to block.

Ah, I see your question. Perhaps you're not so concerned that something in Render is causing the issue; rather that something in the Cocoa view is causing a problem. Well, if you're running in a standard, well-behaved AU host, then none of the code should be called on the audio thread except for Render. But, if you're also writing the AU hosting code, then there's easily a potential that you're calling unsanctioned API on the audio rendering thread.


Brian Willoughby
Sound Consulting

_______________________________________________
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: AU Threading Question
      • From: Stephen Blinkhorn <email@hidden>
References: 
 >AU Threading Question (From: Stephen Blinkhorn <email@hidden>)
 >Re: AU Threading Question (From: Brian Willoughby <email@hidden>)
 >Re: AU Threading Question (From: Stephen Blinkhorn <email@hidden>)

  • Prev by Date: Re: AU Threading Question
  • Next by Date: Cocoa classes and plug-in bundle (dylib) in-memory lifetimes (AU, x64, ObjC)
  • Previous by thread: Re: AU Threading Question
  • Next by thread: Re: AU Threading Question
  • Index(es):
    • Date
    • Thread