Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: Chris Luth <email@hidden>
- Date: Tue, 9 Aug 2005 18:12:41 -0800
I do not have an external drive (yet) that I can use for that. I did
move my swap file to a separate partition on my old G4 tower to
prevent fragmenting, but I made the partition too small and it kept
filling up. So yes, I am familiar with the process.
However, I do not think it's VM, although it sounds like it could be.
I ran sar -p 1 100 and sar -q 1 100, and neither one showed any VM
paging activity during the stutters.
Even if it is VM, short of moving the swapfile (not a good idea on a
portable, anyway, since the external disk won't always be attached!),
there'd be no way to prevent disk accesses during playback. It should
be iTunes' (or QT's or whatever's) responsibility to maintain a
decent-sized data buffer so that disk writes won't affect playback.
Chris
On Aug 9, 2005, at 3:44 PM, alex wrote:
Again, this is probably a stupid suggestion but do you have a
external hard disk you can put your swap file onto for testing
purposes?
I'm not advocating moving your swap file as this isn't recommended,
however it is doable and there are some nice detailed instructions
for accomplishing this online, search google (it's easy). I say if
you run out of options give this one a shot. Many unix folk swear
on keeping their swap on a separate partition but I haven't found
any definitive proof [with OS X] that this is even worth the effort
(but I digress).
My thinking is that the disk hardware is causing the stuttering
(specifically the interaction between iTunes and the VM process on
your machine).
Then again I may just be blowing smoke, I'm good at that! ;-)
alex
At 3:16 PM -0800 8/9/05, 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.
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.
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 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.
_______________________________________________
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
_______________________________________________
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