Re: AudioOuputUnitStop
Re: AudioOuputUnitStop
- Subject: Re: AudioOuputUnitStop
- From: Jeff Moore <email@hidden>
- Date: Tue, 6 Dec 2005 15:29:28 -0800
From the HAL's perspective, AudioDeviceStop() has no guarantees
unless it is called on the IO thread (that is, from inside of a call
out to an IOProc). There could be any number of calls out to IOProcs
between when the call to AudioDeviceStop() returns and when the the
thread actually terminates. It's generally small, but it is
definitely not guaranteed as the operation is totally asynchronous.
The only guarantee is that the HAL will send a notification for the
property kAudioDevicePropertyDeviceIsRunning when things are totally
done. (Note that in a process with many unrelated HAL clients, it's
easy to get into a situation where calling AudioDeviceStop() only
stops the IOProc in question and doesn't actually send a
kAudioDevicePropertyDeviceIsRunning notification when other clients
in the process are still doing IO.)
When AudioDeviceStop() is called on the IO thread, things are
different. The HAL will not call the IOProc that was stopped again
after the AudioDeviceStop() call completes, but the buffer provided
by that IOProc will get played (and nothing after that from that
IOProc).
AudioOutputUnitStop() has the same general behavior as AudioDeviceStop
(). The difference is that when AudioOutputUnitStop() is called from
outside the IO thread, the call blocks until the HAL actually stops
things. AudioOutputUnitStop() does not block when made from the IO
thread.
On Dec 6, 2005, at 2:51 PM, Bjorn Roche wrote:
On Tue, 6 Dec 2005, David Duncan wrote:
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.
Thanks David.
I'm not sure this answers my question: 2 buffers is still 2
buffers, and when I reach the end of the stream I want to make sure
all the data I put on those buffers is heard. This requires a
concept of draining ie completing playback of those buffers. Let me
try giving a concrete example:
Lets say I have an app that plays an audio file to completion. I
want to make sure that every last sample of that file is heard, and
then I want the callbacks ceased ASAP. So I register an IOProc on
the AudioUnit and start the stream. The IOProc gets its data from
the file and puts it on the output buffer and after a few calls it
notices that it's reached the end. So: when can I call
AudioOutputUnitStop() and still guarantee that every last sample is
heard -- including the ones I just read with in that callback?
IE Can my IOProc look like this:
IOProc:
- get data from file
- copy the buffer into the output stream for playback
- is there any more data?
+ yes: do nothing
+ no: call AudioOutputUnitStop()
If I do that, might the IOProc be called again after
AudioOutputUnitStop()? will the data copied durring the last call
of the AudioIOProc (the one that called AudioOutputUnitStop) be
played back?
What if i call AudioOutputUnitStop() from another thread? will
audio from each IOProc that was called be processed, or might some
be dropped?
thanks again,
bjorn
-------------
Bjorn Roche
Check out my CD Mastering Software
for Mac OS X : http://www.xowave.com
_______________________________________________
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
--
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