Re: AudioOuputUnitStop
Re: AudioOuputUnitStop
- Subject: Re: AudioOuputUnitStop
- From: Bjorn Roche <email@hidden>
- Date: Tue, 6 Dec 2005 16:32:42 -0500 (EST)
Doug,
Thank you very much for your reply. Some comments below...
On Tue, 6 Dec 2005, Doug Wyatt wrote:
On Dec 4, 2005, at 8:43, Bjorn Roche wrote:
Hey all,
My audio editing software (www.xowave.com) uses portaudio
(www.portaudio.com)[1] for audio I/O.
The CoreAduio section of PortAudio is old, has a number of problems
and limitations, and does not use AUHAL. I have mostly rewritten the code
and it seems to work. I will probably have more questions, but I'd like to
start with the most important deficit in my code.
Portaudio has a concept of "completing" an audio stream and a
separate concept of "aborting" the audio stream. As far as I can tell,
AUHAL lacks these concepts, so here's what they mean in PortAudio land:
- Completing means that all remaining buffers are played and then the
stream is closed. The function in question blocks until this is done. In
other circles I have hear this referred to as "draining".
- Aborting means that the stream is closed as soon as possible, even if it
means remaining buffers are dropped.
Both operations can be performed from the callback by returning an
appropriate value, or from another thread by calling an appropriate
function, either PaStop() or PaAbort(). Both the PaStop() and PaAbort()
functions are meant to block until the stream is closed and audio has
stopped.
One of these concepts is missing from AudioOutputUnit. The docs don't
describe the behavior of AudioUnitStop() enough to tell me which of these
behaviours is implemented (unless I am missing something) but in tests I
found that the behavior seemed to be more like PortAudio's "Abort"
behavior. So a few questions come up:
* is that true?
It's closer to "aborting" than completing, maybe the same.
* is it safe to call AudioUnitStop() from the callback? Is there another
way of stopping/draining/aborting from within the callback?
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?)
* does AUHAL provide a way of draining?
I'm not sure I understand what "draining" is.
Draining gurantees that existing buffers will be played, same as
completing. As I said above:
- Completing means that all remaining buffers are played and then the
stream is closed. The function in question blocks until this is done. In
other circles I have hear this referred to as "draining".
thanks agian,
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