Re: default output start & stop
Re: default output start & stop
- Subject: Re: default output start & stop
- From: papi <email@hidden>
- Date: Mon, 06 Jan 2003 21:57:22 -0800
Thanks for the detailed explanation! I've got a much better handle on
what's happening now.
Don't mean to disappoint, but I tracked the puzzle down to a stupid
mistake I made: I allowed the cleanup, CloseComponent(), to follow
immediately after the AudioOutputUnitStart() start call. That'd
shut it down quick ;)
Won't do that again too soon ...
Thanks!
Scott
On Sunday, January 5, 2003, at 04:50 PM, David Duncan wrote:
>
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.
_______________________________________________
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.