Re: Question: What is the impact of changing .cpp AudioUnitEffectsource to .mm
Re: Question: What is the impact of changing .cpp AudioUnitEffectsource to .mm
- Subject: Re: Question: What is the impact of changing .cpp AudioUnitEffectsource to .mm
- From: William Stewart <email@hidden>
- Date: Tue, 22 Jun 2010 10:29:47 -0700
On Jun 22, 2010, at 2:43 AM, Iain Houston wrote:
>
> On 21 Jun 2010, at 23:03, William Stewart wrote:
>
>> We deliberately do not create GC contexts on the I/O thread, so doing any operation with the ObjC runtime on that thread will crash in snow leopard in a GC app. ... using CF on the I/O thread as well is not advised ....
>
> Bill, that's really useful, thanks.
> A(nother) naive question follows. Will it always be obvious when we are operating on the I/O thread? e.g. an audio unit rendering callback is presumably on the I/O thread,
yes... this is a reasonable assumption
> but conversely an audio session property listener is presumably not running on the I/O thread as it is provided a CFDictionaryRef ... or it is, but it is not deemed time-constrained?
no audio session calls execute on an I/O thread.
> Is there a simple deciding rule for us to determine when we are running on the I/O thread and when not?
On the phone, you are on an I/O thread when you are using the RemoteIO or VPIO units for input and output (I/O) to the audio device. Any other audio API (including audio queue and OpenAL) is not on the I/O thread.
On the desktop, the same holds true, with the additional feature of having direct access to the HAL (AudioDevice API) which is the mechanism that actually schedules I/O.
Bill
_______________________________________________
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