Re: HAL Thread question
Re: HAL Thread question
- Subject: Re: HAL Thread question
- From: Jeff Moore <email@hidden>
- Date: Tue, 18 Apr 2006 14:04:50 -0700
Yes, this is normal. By default, the HAL creates a thread on which it
can field notifications from the drivers and do a few other things.
The HAL system object property, kAudioHardwarePropertyRunLoop, can be
used to tell the HAL to use an application thread to field
notifications. Note that the catch is that the thread in question has
to reliably task it's run loop, so not just any thread will work.
Some applications tell the HAL to use the main event thread. Others
just tell the HAL to use whatever thread the app has set up for
miscellaneous notifications.
HALLab's main() (in the file HLMain.mm) has a an example of setting
this property to the main event thread.
On Apr 18, 2006, at 8:03 AM, Craig Hopson wrote:
Can someone give me a quick thread sanity check...
I start my app and attach Thread Viewer. I have one thread, the
main loop, running.
I do whatever setup and hit Play. I now have three more threads
running:
the HAL thread
a high priority I/O thread
my internal processing thread
I hit Stop. At this point I:
call MusicPlayerStop
stop, disconnect, and dispose of my processor(s) (They are
terminal, so the AUGraph remains in tact.)
call DisposeMusicPlayer
call DisposeMusicSequence
My processor thread and the I/O thread go away, but the HAL thread
stays around (waiting in run loop). Is this normal? When I Play
again, I do not get a new HAL thread. Once created, does the HAL
thread hang around ? Or, am I missing something in my tear down?
It doesn't seem to be a problem (now), I'm just curious if this is
expected behavior or if I need to look for something in my code.
--
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