Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: Dave Addey <email@hidden>
- Date: Thu, 18 Aug 2005 20:33:36 +0100
Hi Greg,
Thanks for the response. Is there any way to increase how far ahead
QuickTime stays, i.e. increase it from 2 sec to something else, in a
particular case? Otherwise, if something else on the system starts eating
up processor time, then my tasking calls wouldn't get called often enough
(as they would also be delayed). I guess what I mean is, I want the audio
to *always* keep playing, no matter what.
The other reports we have experienced are of dropouts whilst QuickTime is
performing heavy tasks. I have read elsewhere that the preferred way to
avoid QuickTime causing dropouts to itself is to perform heavy operations
(export, movie open etc.) on a background thread (assuming that the media in
question is thread-safe, of course). Whilst this seems reasonable, if the
QT model is a tasking model, would it not be possible for QuickTime to task
*itself* when needed? These heavy tasks are effectively a closed box to the
API user, but they must themselves know that movies are currently playing,
and could therefore (optionally?) task these other movies whilst they do
their thing, avoiding audio dropouts.
Just a few thoughts! I'm really keen to avoid audio dropouts at *all*
costs, and I want to be 100% if sure this is possible with QuickTime (with
CoreAudio under the hood) at present.
Dave.
> From: Greg Chapman <email@hidden>
> Date: Thu, 18 Aug 2005 08:28:51 -0700
> To: CoreAudio API <email@hidden>
> Subject: Re: iTunes stuttering
>
> Hi Dave,
>
> Yes, QuickTime has a "tasking" model, and the disk I/O's are
> scheduled during that "task" call. Everything else audio-related
> (the actual issue of the i/o, audio decompression, audio processing,
> etc) is done on very high priority threads. QuickTime tries to keep 2
> + seconds ahead on the I/O scheduling side, but if something holds
> you off for more than 2 seconds, you run the risk of running dry, and
> therefore stuttering.
>
> I have also heard reports of breakup during iTunes playback, and
> iTunes (usually) doesn't use QuickTime, so there may be something
> going on on the CoreAudio side as well, but my experience is that
> CoreAudio doesn't generally overload just because of high CPU usage
> by the rest of the system. That audio device i/o thread is the
> highest priority user thread around. I'm not sure I've _ever_ seen
> it preempted.
>
> Greg
>
> On Aug 18, 2005, at 12:58 AM, Dave Addey wrote:
>
>> 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:
>>> 40dsl.pipex.com
>>>
>>> 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
>>
>
> _______________________________________________
> 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