Re: AU instrument multiple instantiation issues (threading?)
Re: AU instrument multiple instantiation issues (threading?)
- Subject: Re: AU instrument multiple instantiation issues (threading?)
- From: Ian Kemmish <email@hidden>
- Date: Fri, 23 Jul 2010 20:44:31 +0100
On 23 Jul 2010, at 10:30, on Crooke <email@hidden> wrote:
internally the instrument has static class methods for accessing
this data, so i am aware that this is a threading bottleneck, but
since the instrument itself is only single threaded i didn't expect
this to be an issue.
When I wrote my instrument, I dived from C++ to C as soon as
possible :-), so I can't comment on the bit about static class
methods. I'll assume from your mention of a bottleneck that either
you are serialising access to the wavetables with a mutex, or you
believe that some library you are using is doing so.
1) The host can call your Au's render method on any thread(s) it feels
like.
2) The OS can run those threads on any cores it's allowed to.
3) if you are using mutexes in your rendering code, then there's
potential for that code to block, causing audio dropouts and/or
stuttering.
Wavetables are usually either read-only, or at worst written to by UI-
related code and read by rendering code. Since wavetables are usually
just tables of numbers, then they shouldn't really need any protection
at all (although for neatness you may want to use mutexes to prevent
more than one UI thread writing to them at once).
Even if your voice data has complicated structures with pointers in
them, it's usually possible with care to arrange things so that voice
edits can be performed without requiring mutexes in your rendering code.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
Ian Kemmish 18 Durham Close, Biggleswade, Beds
SG18 8HZ
email@hidden Tel: +44 1767 601361 Mob: +44 7952
854387
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -
_______________________________________________
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