iTunes: Lack of responsiveness while dealing with audio CDs
Posted by Pierre Igot in: iTunesOctober 22nd, 2007 • 10:16 am
There is something rather frustrating about the level of performance of iTunes in ordinary, real-life situations. I think that iTunes is particularly weak at distributing power when dealing with audio CDs, either for reading/ripping or for burning purposes.
Take this situation that I experienced yesterday. I was playing a tune (AAC file, somewhere on one of my hard drive partitions) in my music library, and I inserted an audio CD that I wanted to rip. At the same time, I was also reviewing my collection of existing tracks, in order to identify duplicates and make minor adjustments in tags, etc.
The first level of frustration was reached immediately after inserting the audio CD in my optical drive. As soon as Mac OS X detected that the CD was an audio CD, iTunes became somewhat unresponsive. Now, I have checked the option to automatically retrieve track information from the CDDB/GraceNote database on the Internet, and my Internet connection is not so fast, so I do expect a bit of a delay before iTunes is able to mount the audio CD in its interface using the appropriate titles.
But it seems to me that this is no excuse for becoming unresponsive. While the audio CD is not visible and iTunes is busy retrieving the track information, it seems to me that it should be perfectly capable of handling other tasks. After all, retrieving track information over the Internet is definitely not a CPU-intensive task, and I really don’t see why mounting a CD should be CPU-intensive either. I have a Mac Pro with 4 cores and plenty of RAM (5 GB), and the built-in optical drive is a Sony DW-D150A. Even if the optical drive itself is obviously not as fast as a hard drive, surely it should be fast enough to read the little bits of information that it needs to read on the audio CD without causing the entire iTunes environment to become unresponsive, shouldn’t it?
Yet, while the mounting of the audio CD was in progress, even though iTunes was able to continue the playback of the song that I was listening to without interruption, there was definitely a lack of responsiveness in the iTunes UI, which made it impossible for me to use iTunes for anything else, such as scrolling up and down my list of tracks or making small edits in the track titles.
Then once the audio CD was mounted with the GraceNote track information, iTunes became fully responsive again. I then elected to rip the audio CD in order to add the tracks to my library, with the “” command in the “” menu. (Why this command is in the “” menu is beyond me, but there you go.)
And once again, as soon as the ripping started, the iTunes UI became pretty much unusable. The playback of the other track that I was listening to continued uninterrupted, but again scrolling up and down lists of tracks and making edits became an exercise in frustration.
Foolishly, I attempted to do a very simple thing, which was to delete an existing track (a duplicate) in my iTunes library using the command-option-shift-Delete shortcut, which not only removes the track from the library, but also moves the corresponding sound file to the trash (at least if the sound file in question is located somewhere inside the main iTunes library folder). iTunes showed the usual confirmation dialog, as expected, and then this happened:
Yes, that’s right: I got a frigging “Deleting Items…” dialog with progress bar. And get this: this modal dialog stayed visible, with the progress bar slowly creeping from left to right, for nearly two minutes (which gave me ample time to take the above screen shot). All this for deleting a single track from my library and moving the corresponding AAC file on my hard drive to the trash!
It was really quite unbelievable. Is ripping an audio CD such a CPU-intensive task that nothing else in iTunes can be done in a reasonably short time frame? And if so, why is the audio CD ripping process not a modal process to begin with? After all, if audio CD ripping is so resource-intensive, even of a Mac Pro with 4 cores and 5 GB of RAM, then surely it makes iTunes completely unusable on any machine that is slower!
The truth is, however, that, while iTunes itself becomes pretty much unusable when audio CD-related tasks are taking place, the rest of the Mac OS X environment on the Mac Pro remains perfectly usable. So the problem, as far as I can tell, is not that audio CD tasks are so CPU-intensive. It is that the iTunes application itself is not really well-designed to handle multiple tasks at the same time while remaining reasonably responsive.
But the fact remains that iTunes has a UI that leads the user to think that it should be able to handle multiple tasks simultaneously. Audio CD tasks themselves do not cause modal dialogs to appear. While iTunes is mounting or ripping an audio CD (or burning one, for that matter), it looks as if the user should be able to continue doing other things in the iTunes environment at the same time. The audio CD-related tasks are clearly treated as tasks that can be relegated to the background.
Based on my experience, however, this is simply not realistic. Even on a very fast machine, the level of usability of the iTunes environment while an audio CD-related task is taking place drops way below what the Mac OS X user would expect from a reasonably responsive application.
As far as I can tell, this is either because the audio CD tasks are indeed too CPU-intensive or because the iTunes application itself is badly written. Given that the rest of the Mac OS X environment remains usable, I would tend to think that it is the latter. But of course I am not a developer, and there is probably very little point in my submitting bug reports about this via the ADC’s Bug Reporter. There is no way that Apple’s engineers are not already aware of this. They probably simply won’t bother to fix it, either because rewriting iTunes to handle audio CD-related tasks more elegantly is too much trouble or because they think that multi-tasking iTunes users like me are only a small minority—which, of course, might very well be true.
But unfortunately once you’ve developed a multi-tasking type of personality, it is simply impossible to change back to being the type of user that just initiates one task at a time and then watches his computer screen patiently while the task is completing before trying to do anything else with his computer. I know I certainly don’t have this kind of patience anymore, and I simply cannot get used to the fact that iTunes becomes so unresponsive when dealing with audio CDs.
October 22nd, 2007 at Oct 22, 07 | 10:29 am
iTunes’ behaviour in these situations is a definite mystery. Some parts of iTunes seem to handle multi-tasking really well while quite a few others plainly suck.
I am particularly puzzled by that single track deleteion progress dialogue. I’ve seen it myself a number of times so far and applaud the iTunes engineers for properly recognising a task that may take a while to complete and for displaying a proper progress window in the situation. It just remains inexplicable why such a trivial action as removing a single song from the library should take more than a split-second.
October 22nd, 2007 at Oct 22, 07 | 8:58 pm
Didn’t you know, Pierre? You need EIGHT processor cores to run iTunes smoothly now.
Every time I put a CD in, it’s like iTunes has to have a three-minute navel gaze. Bizarre. And it’s always been that way.
And, in the same vein, why does Safari lock up while loading web pages onto a few tabs? I can’t change tabs while pages in other tabs are still loading? Ridiculous!
October 23rd, 2007 at Oct 23, 07 | 1:22 am
iTunes does this because it’s still a single-threaded Carbon app. Not that it’s any excuse at all, it’s just the technical reason. I doubt they’ll improve it that much, since most people don’t deal with CDs much any more except to rip them and then put them back in the drawer, and Carbon is much easier for developing a cross-platform app (it’s got to run on Windows) and most programmers won’t go multithreaded unless there’s a real need, because it complicates debugging greatly.
At least the Finder is now multithreaded in Leopard and doesn’t become unresponsive for an extended period when your network shares unmount. Much rejoicing there.
One thing you may not have noticed… in recent versions of iTunes you apparently can have two copies of iTunes running on different machines accessing the same library. Previously, you’d get a message that the library was already locked if you opened your library from another machine. So sometimes they do slip in these un-publicized improvements.
October 23rd, 2007 at Oct 23, 07 | 3:17 am
I think you have misdiagnosed the reason for this behavior, which I also noticed and, I agree with you, is extremely annoying. This has nothing to do with iTunes per se. Every time the mac is mounting an optical drive, it goes into a “coma” and becomes totally unresponsive (with SBOD) until the process is completed. The worst case, which happened to me, is when the optical drive cannot properly mount the disc (perhaps because it’s defective): My mac mini went into an endless loop trying to read and mount the disc. Because it was in the mounting process, there was no way for me to stop it. I had to shut it down. This warrants a n entry on Apple Bugtraq. I am hoping Leopard will fix it, but I am not holding my breath.
October 23rd, 2007 at Oct 23, 07 | 9:16 am
AlanY: It’s funny, I seem to remember that, in the very early days of Mac OS X, Carbon was presented just as a legacy thing, and Apple actually encouraged people to use another development environment (the so-called “Yellow Box”), especially for cross-platform development. It’s kind of ironic that now Carbon is the preferred environment for cross-platform development :). As for having to deal with audio CDs on a regular basis, well, to me they are still a much better alternative to on-line music files. So I do plan to continue purchasing CDs and adding them to my iTunes library on a regular basis for the foreseeable future. Now, I know that these days, Apple is all about the iTunes Store, but I really do not like it when marketing strategies get in the way of my perfectly normal, established use of the software.
germ: I don’t agree that the entire OS X system becomes unresponsive when inserting CDs of any kind. Some parts of it (i.e. the Finder) can become unresponsive, but not the OS as a whole. Even with a complete lockup such as the one you describe, you can usually still continue to work in other applications, such as Mail, Safari, TextEdit, etc. You might need a hard reset because the Finder itself is unable to recover (even after a force-quit), but it’s not the entire OS that is affected. Basically, it’s about how well individual applications handle optical media.
October 23rd, 2007 at Oct 23, 07 | 3:01 pm
I agree Pierre, I don’t buy music online either, and I do prefer to buy CDs. (Though I’ve been swayed lately by a couple of out-of-print CDs that the iTunes store had in iTunes Plus (DRM-free, 256kbps AAC) format.) It’s just that after you buy them, at least for me, they spend a little time in the computer for ripping, then go into the closet.
I’m sure Apple would prefer that iTunes was a Cocoa app, but now that it’s several million lines of code, it would be a tough switch without enough of a payout to rebuild the app from scratch. I’m sure though that they’re working on an iTunes successor somewhere in their skunkworks, perhaps something targeted at hardcore music lovers with huge libraries, akin to Aperture versus iTunes.
October 23rd, 2007 at Oct 23, 07 | 3:02 pm
Er, I meant Aperture versus iPhoto.
October 23rd, 2007 at Oct 23, 07 | 3:18 pm
Lord, an iTunes Pro application… That would really make my day!
October 23rd, 2007 at Oct 23, 07 | 11:56 pm
I got some interesting information about this.
I sat down with a couple Apple engineers today for lunch, guys with some serious technical knowledge, both personally responsible for your iTMS experience. I threw this issue at them out. They aren’t on the iTunes app team, but they know programmers who are. And guess what? They (the iTunes team) are as frustrated by this problem as we are. Why? Because it has nothing to do with iTunes, but it gets in their faces: it is, in fact, an OS X limitation, as “germ” wrote. AlanY, you were sorta half right: it is a threading problem, but at the OS level, not at the app level. OS X has never had the ability to pay attention to a mounting device while doing anything else. Macs really do lock up while mounting CDs, and not just in iTunes: we just tend to notice it there.
And, good news …
According to one them, it’s fixed in Leopard! ;-) Won’t that be nice?
October 24th, 2007 at Oct 24, 07 | 8:08 am
Paul: That’s interesting. But it doesn’t answer, for example, the question of why iTunes was so slow to delete a single track while ripping an audio CD, as described above. It was not an issue with CD mounting. The audio CD was already mounted.
October 24th, 2007 at Oct 24, 07 | 11:55 pm
No, sorry. I can assure you that my G4 mac mini really does become TOTALLY unresponsive while mounting an optical drive. It is not just Finder and/or iTunes. It’s the entire machine. And no, I cannot even switch to another application.
Now, I do not know whether this is true of other Apple machines as well, but that’s simply what happens EVERY TIME with the mac mini.
October 25th, 2007 at Oct 25, 07 | 1:12 am
Pierre: Nope, it doesn’t explain that issue, but I feel fairly pleased to have gotten a fairly definitive explanation of any of what you reported. And it’s possible that the sluggishness while ripping is a closely related problem, or something else entirely. I’ll have to go for lunch again …
October 25th, 2007 at Oct 25, 07 | 9:09 am
I guess we’ll have to see what the behaviour is like with the final Leopard build.
germ: It’s true that I have been using mostly fairly fast machines in recent years, so I do have as much experience with “slower” Macs. My guess is that it also probably depends on the brand/model of optical drive. Still, thanks to Paul, we know that at least some Apple engineers are aware of the problem.