Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: Jeff Moore <email@hidden>
- Date: Tue, 9 Aug 2005 17:52:27 -0700
On Aug 9, 2005, at 4:16 PM, Chris Luth wrote:
I played around with HALLab (after building it) for a few minutes.
Pardon my CoreAudio ignorance, but I don't really understand the
data it's giving me or how to interpret it.
No worries. That's what we're here for. It really does help if you
have a working knowledge of how the HAL and the driver go about doing
their jobs. Developers doing any deep audio work really should take
the time to learn this. My old WWDC talks and what documentation
there is are great places to start.
It doesn't sound like you are a developer, so here's a greatly
simplified view of what's going on:
In order to do IO, the HAL needs to run a thread (often referred to
as the IO Thread). This thread wakes up at regular intervals. The
duration of the interval is determined by application, but the
default is roughly 11.6 ms. This thread is one of the highest
priority threads on the system. Pretty much the only things that can
cause this thread to wake up late are primary interrupts, the VM
pager, and other IO threads.
When the IO Thread wakes up it executes the following algorithm (also
referred to as an IO cycle):
1) capture the current time
2) update the clock that tracks the hardware
3) calculate the time stamp of the first frame of input data and
first frame of output data for this interval
4) read the input data at the time calculated in 3 from the driver
5) call the application to provide the input data and to provide a
buffer into which to put the output data
6) write the output data at the time calculated in 3 to the driver
7) calculate the next time to the IO thread needs to wake up
8) check to see if the thread missed the deadline and send the
overload notification if so
9) go to sleep until the time calculated in 6
In order to maintain synchronization between the hardware and the
HAL, the driver provides a stream of time stamps that related the
sample time to the CPU clock. This is the relationship that gets
updated in step 2 above. From this relationship, the HAL derives
what's known as the rate scalar of the device which tells us how much
faster or slower than the nominal speed the device is running at.
This is probably the bare minimum you need to know to get useful
information from the telemetry.
Just as Jeff suspected, here's one thing I noticed after playing
around a bit: I did a File>New>New Input Window, clicked on "Start
IO," and watched the Log to see what happened. When the audio
skipped, a corresponding log entry appeared, similar to the following:
449626.252741: overload
Again, no idea what this means, but it's a promising lead.
An overload is a notification that the HAL sends to a listener to
indicate that the deadline for the current buffer of data was missed.
This is step 8 in the IO thread's algorithm.
The Input Window provides an interface on the input side of the
device. It allows you to start and stop the device in order to do
software play through or to record the input to a file. It also
tracks the notifications that the HAL sends.
I'm not sure how to hook into a target app. File>New>New IO Cycle
Telemetry Window didn't give me much luck, either: I couldn't
figure out how to start the monitoring, and no data ever appeared
in that window.
To target an application, you type it's process ID (which you can get
from top) into the indicated field. Then you use the device pop-up to
select the device you want to monitor. The capture rate pop-up
controls how often HALLab should query the target to get the
telemetry. One or two seconds is usually what you need.
Once you have things set up, you switch to the target app and do the
thing that produces the glitching. The telemetry window will start to
fill up with the data. The data can be viewed two ways as whole
cycles or raw. For the most part, you should stick with the whole
cycles view.
In this view, each line in the table represents an entire IO cycle.
The columns of the table are different statistics for the cycle.
These statistics are derived from the times of various parts of the
IO cycle. If a line is grey, it means that all the input buffers and
all the output buffers contained zeroes. If a line is black it means
there was at least one non-zero sample in either the input or output.
If a line is red, it means that an overload happened during that cycle.
You can use the "Previous" and "Next" buttons to move from overload
to overload.
If you open the disclosure triangle of a cycle, you can see the
timing of each individual step in the IO cycle's algorithm as
individual events. You can also see exactly what kind of overload
took place by the error events.
That should be enough to get you going. I'm sure once you get some
telemetry, you'll have some more questions about what it all means.
Feel free to post screenshots or whatever of the telemetry, and I'll
help you decipher it.
To answer Alex's question: the one that's stuttering is the
internal drive on my 17" PB 1.67GHz with OS 10.4.2. The drive is
100GB, 5400 rpm, and connected via Ultra ATA/100.
Chris
On Aug 9, 2005, at 2:33 PM, email@hidden
wrote:
Without going into the possible reasons for them (there are a myriad
of possibilities), glitches usually manifest themselves as an
overload or other anomaly in the HAL. The best tool to use to observe
the HAL is HALLab's IO cycle telemetry. The telemetry lets you hook
into a target app and snoop on what the HAL is up to. It also lets
you take latency traces based on telemetry events. Between the two
kinds of data you should be able to get a pretty darn good idea about
why something is glitching.
Plus, you end up with some solid data on which to base a bug report
when you file a bug about the problem.
--
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