RE: AudioDeviceStop and ioProc
RE: AudioDeviceStop and ioProc
- Subject: RE: AudioDeviceStop and ioProc
- From: "Tim Dorcey" <email@hidden>
- Date: Thu, 11 May 2006 14:46:44 -0700
- Importance: Normal
> Only if the call is made from the IO thread. If the call is
> made from
> any other thread, you can expect any number of calls to your IOProc
> between you making the call and it actually stopping. Normally this
> number will be quite small, but there are no guarantees about it.
>
> > And, I guess if my ioProc happened to be in progress at the time
> > the call was made, then the calling thread would block until the
> > ioProc
> > returned?
>
> That is correct. Any API action that affects what the IO thread is
> doing synchronizes with the IO thread.
I'm having a hard time reconciling these 2 answers. If the synchronization
machinery is in place to force the calling thread to block when the ioProc
is in progress, why would the input device ever initiate additional ioProc
calls after Stop has been called?
The first answer seems consistent with an unsynchronized model, where the
"stop" request is queued to the IO thread, allowing the calling thread to
continue. But, that doesn't fit with the second answer.
Can you clarify?
Tim
_______________________________________________
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