Re: AU instrument multiple instantiation issues (threading?)
Re: AU instrument multiple instantiation issues (threading?)
- Subject: Re: AU instrument multiple instantiation issues (threading?)
- From: Jon Crooke <email@hidden>
- Date: Fri, 23 Jul 2010 11:23:39 +0100
hi phillipe,
thanks, that's a lot of very useful info. i'll be looking into it today.
j
On 23 Jul 2010, at 11:12, philippe wicker wrote:
>
> On 23 juil. 2010, at 11:30, Jon Crooke wrote:
>
>> hi all,
>>
>> so i'm approaching completion of my first AU synth, and have begun to test it in various DAWs and have discovered what must be some kind of very large flaw in my design: it does not appear to support multiple instantiation correctly. this is not something i previously thought would be an issue, but it seems that i must have been entirely wrong about this. the issue:
>>
>> single instantiation of the instrument works fine, however a second instantiation causes stuttering of the audio.
>> instantiating a second instrument fires up the second core, so clearly they are running on separate threads.
>
> Well not necessarily. I don't know for every DAWs, but last time I had to check for that Logic called the audio process callback on the same thread for a single core machine, and on different threads on a multi-core machine (I suppose this is a way to dispatch the load on all the available cores). But that was some years ago.....
>
>> it seems like the issue is accessing the instrument's wavetables, however, shouldn't these instantiations and their data be entirely separate processes? 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.
>
> Accessing a shared constant data should not be a problem. Accessing a C++ static data - or a plain C global data - that may be modified by an instance of your plug-in leads to the kind of problem you mention. Search into your code for every modifiable data that are either static (in the C++ sense or in the C sense) or global and find a way to gather these data in a structure which is instantiated along with the plug-in instance (which means that you would have to make your static methods instance methods).
>
> If your wavetables are built by the plug-in instance depending upon some parameters - which may be different between all the instances - and if the memory that contains the tables is a static or a global data you will get corrupted audio.
>
>>
>> anyway, i hope someone can shed some light on this issue
>>
>> many thanks
>>
>> j _______________________________________________
>> 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
>
_______________________________________________
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