Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: alex <email@hidden>
- Date: Tue, 9 Aug 2005 19:44:18 -0400
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