Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Jeff Moore <email@hidden>
- Date: Thu, 11 May 2006 15:26:29 -0700
There is nothing to reconcile. You just have to broaden your
perspective a bit and try to remember that you aren't the only code
running on the system, not even in your own process.
The HAL uses a mutex to force things that affect the IO thread to
happen when the IO thread isn't running. This says nothing about how
long a call to AudioDeviceStop() will have to wait before it's effect
is achieved when called from a thread other than the IO thread.
For example, if you make a call to AudioDeviceStop() and there are
other threads of a higher priority already waiting for the IO thread
mutex, then there's a very good chance that the thread calling
AudioDeviceStop() won't get time to execute for a while. This can
lead to any number of calls to your IOProc in the meantime.
Hence, the behavior of AudioDeviceStop() cannot be guaranteed except
when you are calling it from the IO thread.
On May 11, 2006, at 2:46 PM, Tim Dorcey wrote:
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?
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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