Re: AU Processing in Threads
Re: AU Processing in Threads
- Subject: Re: AU Processing in Threads
- From: William Stewart <email@hidden>
- Date: Tue, 27 Apr 2004 11:56:58 -0700
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.