Re: AU Processing in Threads
Re: AU Processing in Threads
- Subject: Re: AU Processing in Threads
- From: Chris Wendt <email@hidden>
- Date: Tue, 27 Apr 2004 23:11:56 -0400
Thanks Kelly and Bill. That's exactly the info I was looking for...
-Chris
On Apr 27, 2004, at 2:56 PM, William Stewart wrote:
>
There's also some helper classes in the CA SDK in Public Utility
>
(CAPThread and CAGuard and CAMutex - these are all you really need!)
>
and Million Monkee's too has some code for basic p_thread usage...
>
>
Bill
>
>
On 27/04/2004, at 7:00 AM, kelly jacklin wrote:
>
>
> On Apr 26, 2004, at 6:40 PM, Chris Wendt wrote:
>
>
>
>> Even setting the thread priority to the max (10,000), the threaded
>
>> version has many hick-ups and slow downs especially with things like
>
>> moving windows etc. My timing tests of the threaded version show
>
>> that on average the threaded version seems to take up to 3x the time
>
>> to complete the same processing per frame. I'm a bit new to MacOSX
>
>> threading, so are MP Threads not the best route? Are AudioUnit's
>
>> not friendly with threading? Doesn't make sense to me but I'm a bit
>
>> puzzled.
>
>
>
> I'll let someone else address the general issue of threading AUs, but
>
> as to which API to use, I would strongly recommend that you _not_ use
>
> the MP API. Due to the vagaries of how the MP API was defined (long
>
> ago), there are several decisions that had to be made in implementing
>
> the MP API under OSX that are sub-optimal (to say the least). In
>
> particular:
>
>
>
> - due to issues with respect to how termination is handled, all
>
> actions on MP semaphores, queues, and other constructs must take a
>
> lock (global to the process) around modifying the construct structure
>
> itself. This means that multiple threads using _separate_ (distinct)
>
> synchronization constructs (for example semaphores) can contend with
>
> each other, even though they are completely unrelated.
>
>
>
> - the MP "processing weight" of 1-10000 ends up mapping to an
>
> application priority range in OSX. Setting your thread's "weight" to
>
> 10000 results in a relatively high-priority app thread, but
>
> definitely _not_ realtime scheduled. Note that the "processing
>
> weight" of the MP API was never intended to be a priority, it was
>
> intended to be relative use of processor. Under OS9, in order to
>
> truly use this mechanism effectively, you had to know the weights of
>
> all the other threads...
>
>
>
> I strongly recommend you adopt the pthread API directly, as it is
>
> much more sanely implemented, and is much better documented and used
>
> throughout the industry. It is also somewhat easier to use, once you
>
> understand how condition variables work.
>
>
>
> Hope this helps,
>
>
>
> kelly jacklin
>
> _______________________________________________
>
> 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.
>
>
>
>
>
--
>
mailto:email@hidden
>
tel: +1 408 974 4056
>
>
_______________________________________________________________________
>
___
>
Culture Ship Names:
>
Ravished By The Sheer Implausibility Of That Last Statement
>
I said, I've Got A Big Stick [OU]
>
Inappropiate Response [OU]
>
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
>
_______________________________________________________________________
>
___
_______________________________________________
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.