Re: default output start & stop
Re: default output start & stop
- Subject: Re: default output start & stop
- From: David Duncan <email@hidden>
- Date: Sun, 5 Jan 2003 19:50:38 -0500
On Sunday, January 5, 2003, at 06:32 PM, papi wrote:
There's a thread feeding the audio? I haven't worked with threads
myself
yet, but I haven't been able to find anything in the DefaultAudioOutput
sample app that says it's creating or calling a thread.
So, I hope this isn't off-topic, but if the theOutputUnit
is/contains/represents
a thread and the AudioOutputUnitStart() function starts playing it, how
does one stop it? Pressing my button that calls AudioOutputUnitStop()
just waits for the usleep() "timer" to expire.
Thanks again!
Scott
p.s. the render callback supplies a never-ending supply of PCM data
to the AU. Playback duration is currently (temporarily!) controlled
solely
by the length of time specified in usleep().
CoreAudio works by setting up a second thread that it uses to ask the
App for audio data. This is part of the way that the HAL gets audio
from each application to mix into the output stream. AudioUnits layers
the DefaultAudioOutput unit over this thread that exposes a standard
method of processing audio through an application. Each audio unit has
a Render callback that is where the audio gets submitted to the
particular AudioUnit. An AudioOutputUnit is always the topmost unit in
an audio unit chain. The output unit knows how to talk to the
destination of the audio (in this case the CoreAudio HAL). Again, it is
the HAL that is setting up the second thread to query the audio, the
DefaultAudioOutputUnit is just talking to the HAL to transfer the audio.
When you call AudioOutputUnitStart(), then the Output unit starts
querying the audio unit chain (in this case the render callback that is
producing the sine wave) for audio. The output unit delivers this audio
to the CoreAudio HAL. This process continues until you call
AudioOutputUnitStop(). The length of time between
AudioOutputUnitStart() and AudioOutputUnitStop() determines how long
the audio plays for, the usleep() call was solely a method of holding
for 5 seconds between the calls. Since your triggering the start/stop
with a button, then you don't need the usleep() at all.
--
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
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.