Re: AudioDeviceStop and ioProc
Re: AudioDeviceStop and ioProc
- Subject: Re: AudioDeviceStop and ioProc
- From: Steve Checkoway <email@hidden>
- Date: Tue, 23 May 2006 16:37:34 -0700
Jeff Moore wrote:
As Bill says, the command line version is definitely the way to go. It
even has a pretty good man page to help you out.
Excellent. I'll give that a shot when I make it back to that computer.
At any rate, the new backtraces you put in the previous email work out
like this:
- Thread 2 appears to be the the main thread. It is blocked making a
call to AudioDeviceStop(). The lock it is blocked on is definitely the
IO thread lock.
- Thread 3 appears to be the HAL's notification thread. It is also
blocked trying to lock the IO thread lock, probably because it is
fielding a notification from the driver. The other back trace for this
thread shows the thread in it's normal, quiet state.
- Thread 5 appears to be an IO thread. It is not blocked. Rather, it
is in a system call that maps a pthread ID to a mach thread ID so that
the HAL can change the thread into a time constraint thread. Being a
running IO thread, this thread is holding the lock that the other two
threads are blocked on.
This information is inconclusive. It looks to me like all the HAL
threads are functioning normally. The IO thread is not blocked, so it
will eventually let go of the lock which will unblock the other
threads. I imagine that there are other threads in this process. I
would need to see what those threads are doing to be able to diagnose
the hang further.
There are. There are 11 threads in all. There is the GUI thread which
does almost nothing and as I recall was just waiting for events the
whole time. Thread 4 is a decoder thread which decodes the audio into
the 16 bit signed lpcm that is consumed in the IO thread (in a lockless
manner). Threads 6 through 11 have absolutely nothing to do with audio;
one is nothing more than a runloop consuming events from the IOKit such
as keyboard presses and joystick button presses, the rest are worker
threads for doing specialized tasks, none of which are related to audio.
I think one deals with USB mass storage devices (for use as "memory
cards" for game data), and others are used for preloading data or
concurrent openGL rendering. There's possibly a thread that uses ffmpeg
to make openGL textures out of frames of movies but doesn't touch audio.
I'm not sure if it's even running at this point though.
The main thread (thread 2) only interacts with the audio when starting
the device or shutting it down or telling the decoder thread to decode
another chunk of audio.
BTW, these back traces are classic examples of why an instantaneous
look at the stacks is not really that helpful when trying to diagnose
a hang. To an untrained eye, thread 5 might looked blocked. It isn't,
but the only way to know that is to do what the sample tool does: take
snapshots of the stacks over time. This would show that this thread
has many different back traces because it is still running.
I'm starting to appreciate that. As I said, I'll give it a shot when I
get back to that computer.
Thanks,
- Steve
_______________________________________________
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