Re: AudioOuputUnitStop
Re: AudioOuputUnitStop
- Subject: Re: AudioOuputUnitStop
- From: David Duncan <email@hidden>
- Date: Tue, 6 Dec 2005 17:08:07 -0500
If you call AudioOutputUnitStop from the I/O thread then
AudioDeviceStop is called immediately. The I/O proc will not be
called again. I believe the current I/O cycle's buffer will be
played; i.e. that the stop will actually take effect at the end of
the I/O cycle. (If I'm wrong, Jeff Moore will correct me...)
If you call AudioOutputUnitStop from another thread, then it will
call AudioDeviceStop and wait for a notification from the HAL that
the hardware has actually stopped before returning. In the
interim, the I/O proc may continue to be called.
Thus AudioOutputUnitStop is always synchronous; on return, in the
absence of an exceptional condition, the I/O proc will not be
called again.
I am a bit confused since above you indicate that the operation is
more like abort than complete, but here you seem to be describing a
complete operation, not an abort.
Anyway, I'd like to paraphrase your description to make sure I
understand it:
--- Inside the callback:
AudioOutputUnitStop() stops the callback from being called again.
(Q: will the buffer from this final call be played back to the
audio device?)
--- Outside the callback:
AudioOutputUnitStop() will block, prevent the callback from being
called again and return after the last callback is completed. (Q:
will audio from the last completed callback be played?)
Your confusion stems from assuming that Core Audio has the concept of
draining. Core Audio only knows about at most 2 buffers, the buffer
that is playing and (potentially) the buffer that it has requested
you to fill. Draining as you've described it, assumes that there is
the potential for more than these 2 buffers (from a Core Audio point
of view at least) as you would need multiple buffers to play more
than a very short segment of audio.
As to if the next buffer plays or not, I don't know. I wouldn't rely
on it going either way. If you were to implement "Draining" with Core
Audio, you would need to request from your audio source how much more
audio is available when your StopAudio() routine is called and not
return until you get a notification of some sort that there is no
more audio available.
--
Reality is what, when you stop believing in it, doesn't go away.
Failure is not an option. It is a privilege reserved for those who try.
David Duncan
_______________________________________________
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