Re: iTunes stuttering
Re: iTunes stuttering
- Subject: Re: iTunes stuttering
- From: Greg Chapman <email@hidden>
- Date: Thu, 18 Aug 2005 12:45:54 -0700
There isn't any way to get QuickTime to schedule reads more than 2
seconds ahead. That would be a great feature request.
And I think we're officially out-of-bounds on the coreaudio list now!
Greg
On Aug 18, 2005, at 12:33 PM, Dave Addey wrote:
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:
40apple.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:
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