Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: Dave Addey <email@hidden>
- Date: Thu, 18 Aug 2005 08:58:35 +0100
Hi all,
I've been experiencing this kind of problem with my QuickTime-based DJ
application. When I say 'this kind of problem', I mean that a few users
experience audio dropouts in my DJ app when QuickTime is doing certain
things, such as opening movies. However, the vast majority of users don't
have thee problems. This happens across a whole range of system
configurations, from the old and slow to the 1.5Ghz PowerBook and upwards.
My dilemma is that it is almost impossible for me to emulate their dropouts,
and therefore fix the problem. More generally, it seems that QuickTime /
CoreAudio (or wherever the dropouts lie) could conceptually keep playing
back - the machine is generally up to the job - but something else hijacks
too much processor or disk access time (I'm guessing), and audio drops out.
The QuickTime model for avoiding this is to ensure that playing movies are
tasked as often as required. This is fine when the 'heavy' activities are
within my control, but doesn't help when something external / at an OS level
is causing whatever causes the dropouts.
This might be more of a QT than a CA question, but... What I've always
wondered is, would it be possible to make audio playback Priority Number One
for the Mac / for an application, so that audio dropouts would only happen
when you really are asking too much of the spec of that machine, rather than
when things just get a bit heavy? I'm sure I'm over-simplifying things, but
if the Mac has the power to play the audio, then it should play the audio,
without me having to know that it needs tasking doe to some external factor.
Is this possible through some kind of CoreAudio playback thread priority
assignation?
Other than that, my general question would be, what else can I do (as a
developer) to avoid these drop-outs in my app? (Just holler if that's a
QT-API list question).
Dave.
> From: Chris Luth <email@hidden>
> Date: Mon, 15 Aug 2005 17:10:30 -0800
> To: <email@hidden>
> Subject: Re: Coreaudio-api Digest, Vol 2, Issue 239
>
> Frank-
>
> Tried it and it didn't fix anything. It still periodically stutters,
> coinciding with the update process and with large disk writes.
>
> I suspected originally that it had something to do with the Sudden
> Motion Sensor as well. However, it happens when the laptop was on a
> solid surface, undisturbed. Severely rocking the machine *does* make
> it stop playing for a few seconds, but I don't think the two are
> related.
>
> Besides, other people with desktops (including a dual-G5 user) are
> complaining about the same issue--see the link I posted earlier to
> the Apple Discussion Boards:
> http://discussions.info.apple.com/webx?email@hiddenFmb3mj.8@.68aca9a0
> also:
> http://www.macosxhints.com/article.php?
> story=20050623234932431&query=itunes+skip
>
> OK, so if it's something in the OS that's interrupting iTunes' reads
> of the audio file, that needs to be fixed. Though I'm not a developer
> (I'm familiar with some programming terms but I haven't coded
> anything!), something that Kurt Revis said in a recent post here
> might help figure this out:
>
>
>>> So far I have looked at PlayBufferedSoundFile, which looks
>>> moderately useful, but utilizes Mach calls for VM management.
>>>
>>>
>>
>> 1) This example is probably overkill for your needs. It's designed
>> for reading long sounds from a file on disk -- think iTunes. You can
>> probably start out by loading your sounds completely into memory,
>> which is much easier to deal with.
>>
>
>
> Chris
>
> On Aug 10, 2005, at 3:17 PM, email@hidden
> wrote:
>
>
>> Message: 3
>> Date: Tue, 9 Aug 2005 23:48:52 -0600
>> From: Frank Vernon <email@hidden>
>> Subject: Re: iTunes stuttering
>> To: email@hidden
>> Message-ID: <email@hidden>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Chris-
>>
>> Just a stab in the dark here... Have you tried to reproduce your
>> problem with the Sudden Motion Sensor feature of your PowerBook
>> disabled? I've had issues with audio playback when this is enabled on
>> the same hardware you mention here.
>>
>> To turn it off:
>> sudo pmset -a sms 0
>>
>> To turn it back on:
>> sudo pmset -a sms 1
>>
>> These settings are persistent across boots.
>>
>> -Frank
>>
>>
>>
>>
>>
>>> 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
>>>
>
>
> _______________________________________________
> 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