• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: iTunes stuttering
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: iTunes stuttering


  • Subject: Re: iTunes stuttering
  • From: Greg Chapman <email@hidden>
  • Date: Thu, 18 Aug 2005 08:28:51 -0700

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
  • Follow-Ups:
    • Re: iTunes stuttering
      • From: Dave Addey <email@hidden>
References: 
 >Re: iTunes stuttering (From: Dave Addey <email@hidden>)

  • Prev by Date: RE: XCODE 2.1 targeting Panther
  • Next by Date: Re: iTunes stuttering
  • Previous by thread: Re: iTunes stuttering
  • Next by thread: Re: iTunes stuttering
  • Index(es):
    • Date
    • Thread