Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: alex <email@hidden>
- Date: Tue, 9 Aug 2005 22:57:56 -0400
I agree with all of your points. I was just trying to aggravate the bug if there is one.
alex
At 6:12 PM -0800 8/9/05, Chris Luth wrote:
>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