Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Reduce the CPU load from iTunes song encoding Apps
When I use iTunes to rip a CD or otherwise change a song's encoding (say from Apple Lossless to AAC), my old Rev. A TiBook's CPU load will be so high that it starts to make it less responsive and somewhat unusable. It even affects the network card, which will periodically drop the network connection. Playing with the UNIX renice command never had any noticeable effect on this issue (in fact, it usually caused some problems).

A trick I stumbled across the other day is to start the rip or conversion operation, and then open up the Preferences dialog. This will reduce the CPU load by a third on my laptop, and will allow everything else to function normally.

I assume the scheduling of the run loop for handling the dialog forces the better behavior.) It will extend the time it takes to perform the task, but at least I can still use my laptop while it is doing it in the background.
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[8,126 views]  

Reduce the CPU load from iTunes song encoding | 9 comments | Create New Account
Click here to return to the 'Reduce the CPU load from iTunes song encoding' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Reduce the CPU load from iTunes song encoding
Authored by: iacas on Nov 24, '04 11:25:38AM

If iTunes uses the Carbon event model, there really isn't much of a "run loop" anymore. Since Apple's been pushing it for four WWDCs now, I bet it probably uses it.

---
--
Erik J. Barzeski
Web Everywhere



[ Reply to This | # ]
Reduce the CPU load from iTunes song encoding
Authored by: smithkennedy on Nov 24, '04 02:10:06PM

You may be getting the old Event Manager "event loop" confused with CFRunLoop / NSRunLoop, which are Mac OS X-only technologies, and exist at a very low level (CoreFoundation).

The Carbon Event Manager is a higher-level API for Carbon developers to use instead of the deprecated Event Manager API, and is usable either in Mac OS 8.6-9.2.2 if CarbonLib 1.1.1 is installed, or in Mac OS X. The Mac OS X implementation provides access to the underlying CFRunLoop using GetCFRunLoopFromEventLoop(). If you look at the documentation for the Carbon Event Manager, and also the discussion of "CFRunLoop" in CoreFoundation documentation, this should be come more clear.

I don't know specifics of thread management in Carbon apps on Mac OS X because I develop either to IOKit, POSIX, CoreFoundation APIs, or Cocoa APIs if I need to do a GUI for some reason (infrequent). But the fact that the CPU load is reduced when the Preferences dialog is open makes me think that iTunes creates a new Carbon Event Manager for that dialog, and since it is the front window, that thread gets the priority during its time slices. There is not a 1-to-1 relationship between CFRunLoops and Carbon Event Managers.

But when a new modal dialog for Preferences is presented by iTunes, the side effect of the underlying implementation seems to be that the CPU load drops by a third or so.



[ Reply to This | # ]
Reduce the CPU load from iTunes song encoding
Authored by: dogboy on Nov 24, '04 01:30:30PM

Try closing the iTunes window completely, or hiding it. I heard it makes a big difference, although I properly haven't tested it, I seem to remember it made a difference on my old G3 iBook.



[ Reply to This | # ]
Progress bar
Authored by: sinjin on Nov 24, '04 02:26:36PM

I wonder if difference seen by the submitter has anything to do with hiding of the progress bar (as suggested here in the comments). I seem to recall a hint here that said you could speed up system optimizations after a software install by hiding or minimizing the installer window--the explanation being the progress bar really eats up cpu cycles. Anyhow, just thinking that this might be evidence of the generality of the hint.



[ Reply to This | # ]
RE: Progress bar
Authored by: smithkennedy on Dec 19, '04 10:44:21AM

These were interesting suggestions, but I didn't see that they made any difference. I tried hiding the main window and closing the main window as well, but neither of them reduced the CPU load I have seen. Only the Preferences window being open seems to affect it on my systems.



[ Reply to This | # ]
CPU load w/apple Preferences
Authored by: kissedsmiley on Nov 24, '04 09:40:27PM

I don't know if it's related, but just today I had somewhat the opposite behavior. Using not too many apps, I had system preferences open to IKey and my system was slow and hoarding the RAM. I closed the preferences, and it subtracted 500MB from my usage! (g4 powerbook, 1G RAM, osx10.3.2)



[ Reply to This | # ]
CPU load w/apple Preferences
Authored by: smithkennedy on Nov 25, '04 10:41:06AM

Don't get "System Preferences" confused with an app's preferences. And you are citing a third-party preference pane, which most likely has a bug if it is exhibiting that behavior. It is also quite possible it is not managing memory well, or improperly, if it is eating up that many resources! :-)



[ Reply to This | # ]
CPU load w/apple Preferences
Authored by: sinjin on Nov 25, '04 12:26:33PM

Yes, "System Preferences" is what you are talking about, it is an application, so a bit different than preferences within an application.

Some of Apple's standard Pref Panes can really eat up the cpu as well. Try opening "Sound". My cpu hits about 90-100% seemingly while trying to render the little mic sound level meter.



[ Reply to This | # ]
CPU load w/apple Preferences
Authored by: calroth on Nov 27, '04 08:57:04PM
My cpu hits about 90-100% seemingly while trying to render the little mic sound level meter.

Slightly off-topic... but that's how it should work!

Given the choice between being idle, and using spare processor cycles to make the meter update faster, I think it's smarter to use the cycles.

Of course, it should never get in the way of real processing, but if you're not doing any of that, it doesn't matter.



[ Reply to This | # ]