Software developers love to talk about their work. This blog is proof of that: blah, blah, blah. But for a variety of reasons we must often guard our speech to avoid spilling the beans about details meant to remain private. Salaried engineers are usually expected to keep mum about a project’s details or even existence until a shipping product is delivered. So when I ask my Apple friends what they’re working on, they may reply with something vague like “on a consumer oriented application.” Oh, whoopdie-doo. Apple’s making something for consumers? Only when the application or product becomes public do they get to beam proudly, confessing their involvement as the world flocks to enjoy the fruits of their labor. If the project instead gets axed or indefinitely postponed, they turn gloomy and unresponsive. All that time, wasted on something nobody will ever see or use. Even when the product does go public, admission of involvement is usually on a friends-only, hush-hush basis. Apple and other big companies increasingly keep hidden the names of their products’ makers.

As a consultant, it’s usually understood that credit (or blame) for a product will go to the company itself. Even if the company is the type that still puts their employees’ names in the about box, it will be their name and not yours that goes in the shipping product. Sometimes this is a blessing. For instance, if the client is determined to make the Mac port of their Windows application look and feel just like its crappy Windows counterpart, it’s comforting to cash the check at the end of the project and wash ones hands clean of the dirty work that was done. We don’t like to talk about those projects. But when a project goes well and is received with public praise, it can be difficult to maintain one’s legal or ethical obligation to anonymity. Pride of ownership is one of the best fuels for software innovation. Just ask Linus Torvalds. No wonder the open source community has exploded over the past decade. As companies give programmers fewer and fewer opportunities to gloat, the open source community offers nothing but recognition as compensation for a job well done.

It was a pleasure of mine recently to work with a company that has a great perspective on this. SoundSpectrum is the company behind the “G-Force Visualization Engine,” which is what makes the pretty colors and patterns Apple’s default iTunes visualization plugin. They sell a suite of products that make the already-amazing iTunes visualizer look like child’s play. When they asked me to help them expand their Mac offerings, it was clear that they weren’t looking for a “crappy Windows port.” Their Windows products are quite good, but they made it clear that they wanted the Mac products to be different. Even a great PC application should not be blindly ported to the Mac. Mac software is different. Our agreement on this point made me eager to sign up for the job.

A consulting job where the task at hand is to “take the Windows product and make it kick ass on the Mac.” I can work with that. What Mac programmers really want is to leave a beautiful mark on the landscape of available Mac software. We want pride of ownership! SoundSpectrum took the concept to an unusual level by offering to put my own true and legal name in the about box of their products. This is brilliant. Not only do I get pride of ownership, but they get accountability. It’s my professional responsibility to always do my best work, even when it’s anonymous. But let’s face it, putting a consultant’s name in the about box can only improve the odds of getting their best work.

Two products carrying my name were released last week. The Mac editions of the G-Force Toolbar and G-Force V-Bar are dramatically different from their PC counterparts, and they kick ass. I was responsible for designing and implementing these applications from the ground up, and I’m proud of that. I’m also thrilled to have been assisted by a rich cross-platform code base, thoughtful technical brainstorming, and the excellent graphics design contributed by another consultant. It was a team effort, but in many ways the buck stops with me. Hate something about the products? I own it.

If you’ve never tried SoundSpectrum’s advanced visualization products, you should give them a spin. One of the pitfalls to this job was the tendency I had to find myself lost in staring at the mind-blowing hypnotic imagery that these products are capable of producing. You can try out the advanced visualization engine by downloading the free trial. My contributions are included in the Gold and Platinum editions, which are very affordable. In particular the Toolbar gives you fine-grained control over just about every aspect of the visualization engine. The V-Bar offers a unique kind of animated “wallpaper”: a band of transparent visualization along the side of your screen. These features have benefited PC users for several months, and now the Mac is caught up. Damn it feels good to leave a beautiful mark.

At this point we understand that a number of workarounds exist for the “CPU whine” noise bothering many MBP owners. What has remained unanswered, for the most part, is whether there is an impact, and if so how much, on the battery life when applying these workarounds. I have assumed that each of the workarounds takes away from battery life to some extent, but have been hard-pressed to declare with any confidence which is the “most efficient.”

Those days of uncertainty are over. At least, I’m ready to share my somewhat scientific results. So here is the experiment: “How long does it take a fully charged MacBook Pro to exhaust its battery to the point of forced sleep?” I applied this question to some of the workarounds I know of, and also to a control case: the MacBook Pro without any workaround (“with noise”).

So what did I do to make it “fairly scientific”? A few things. These are the preparations I made to the MBP, with the goal that battery drain should be as predictable as possible and therefore reveal any discrepancies caused by the underlying workaround. Since I have to wait around while this is happening, I also make no effort to achieve a particular long “control case” life:

1. I configured the computer’s energy saving settings (for “Battery”) such that it should “never sleep” either the computer or display. I also unchecked the “Put the hard disks to sleep” option. These features all seem like they could add unpredictable savings to one test case while somehow not kicking in the same amount on another.
2. I turned off Spotlight indexing for each of the 3 partitions on my MBP drive. Although Spotlight should only kick in when new files get added, I don’t want to take any chances that it suddenly decides to rebuild an entire index during the test.
3. I turn the screen brightness up to high. Not only is this necessary for complete silence on my computer, it also helps drain the battery faster so I can get my answer.
4. Before each test, I recharge the battery to 100% (and then some), and then restart the computer with the power cable attached. I then configure the particular workaround so that it is “active.” That is, the noise will not be audible during the test.
5. After restarting the computer, I take care to run as little as possible. After enabling the particular workaround, I launch a small, custom application I’ve written which is designed to simply record the time it was launched and the time the computer was forced to sleep. As I launch the application, I pull the plug on the 100% charged battery, thereby starting the test.

The computer is left untouched in a corner of my office. After a few minutes the automatic screen saver kicks in, and continues to run until a couple hours later, when the power gets low enough that, despite my Energy Saver settings asking not to be put to sleep, the computer is forced to do so. Whenever I notice that the machine has actually gone to sleep, I plug the power back in and wake it up. The resulting difference in time between yanking the power and going to sleep is the “test result.” Now, I worried at first that the screen saver could be using enough CPU to essentially negate the power lost to QuietMBP’s CPU utilization technique, but the tests show that such concerns are unwarranted. QuietMBP’s impact on battery life is unarguably noticeable, despite the operation of a graphical screen saver for the bulk of the test time.

So, having hopefully described my test scenario sufficiently to make it interesting and respectable, here are my results, listed by name, brief summary, and time in hours, minutes, and seconds. The order is from “most battery life” to least, with the difference from the control case in parentheses:

• Ear Plugs – Noisy MBP control case. 2:43:36
• Single CPU – Disable the second core to minimize the noise. 2:28:04 (-15:32)
• MagicNoiseKiller – Like the Mirror widget but no Dashboard involved. 2:27:58 (-15:38)
• QuietMBP – CPU idle utilization. 2:17:26. (-26:10)

So, no doubt in my mind working around the problem costs battery life, but at least I have a bit more perspective on what I’m trading for my sanity. What’s interesting of course is that Single CPU mode appears to cost battery life: the same amount as MagicNoiseKiller! This has been anecdotally discussed on various forums, but I was curious to discover its apparent truth. My theory is that when both CPUs are running, the machine doesn’t have to work as hard to do “everyday stuff.” Probably when you disable a CPU, the remaining CPU works overtime to get the same work done, and this costs it more power.

Tests that will be less interesting but still worth trying when I get more time:

• Photo Booth Visible – Photo Booth running in an open window.
• iChat Video Hidden – iChat video preview on but minimized.
• Mirror Widget – Classic “Magic” workaround, open and close Dashboard widget.

So what is the takeaway? The MacBook Pro is flawed, but you can make rational choices about which workaround has the least impact on your lifestyle.

If I can’t exploit the full battery life of my computer without distracting noises, then it’s no “professional” computer. I still don’t know what to do – I’m intrigued by suggestions like the one from Jasmine on a previous post, who suggests that perhaps the power supply just needs to have “epoxy poured on one of the coils.” If some kind of retrofix is possible, then I’d like to have the issue addressed when I send mine in for the screen inverter buzz. If they can’t fix it I may push for a (late) return, since I find the computer to be unusable without these compromising workarounds.

Those of us suffering the noise feel pretty helpless: we spent all the money and we have to sit and question the correctness of our decision. I don’t know if there is any value in online petitions or if this one is even the most appropriate one to target my signature to, but I signed it. Maybe it will help, and I don’t think it can hurt.

I’ve gotten a fair number of incoming links to my separate entries relating to MacBook Pro noises, and as I continue to make new discoveries and add new entries, I’d like users who are linking in to have a consistent target to link against. So I’m adding a new page to my site specifically to summarize my findings to date and point to other posts I’ve made. Please use this page as a link if you decide to send information about any of my MBP Noise related posts to a friend.

Thanks for reading!

In my last post on the subject of the MacBook Pro noise dilemma, I dismissed with borderline contempt the notion that “opening and closing Mirror.widget” was a reasonable workaround for the CPU whine problem. I felt pretty certain after my experiments with tweaking CPU usage that any workaround would necessarily equate to equivalent CPU usage or battery draw behind the scenes.

I may yet turn out to have been right, but I’m now using the “Mirror Widget Hack” (MWH) instead of my own QuietMBP. Why? I just got the feeling that my machine was running hotter, mooing more, and generally behaving less amicably when QuietMBP was used to alleviate the symptoms instead of the magical Mirror.widget. The damned computer feels like a wise investment when I use the MWH! I love it again (mostly). So, to all the readers who felt dismissed by my jarring rejection of MWH: mea culpa. I’m sorry.

I don’t like magic, though. At least not when I can’t understand it. I’m ready to admit that MWH does something that brings my computer into a state of calm, but if MWH can do it, surely some other piece of software, that is more convenient to run than a dashboard widget, can do the same thing. I decided to start looking carefully into what exactly happens to the computer when you apply this hack.

First of all, Mirror.widget contains no code. Well, that’s no fun! How the hell does it fix my system, then? The widget is largely implemented in the form of a special QuickTime movie “mirror2.mov” that is somehow configured to automatically reflect the incoming iSight image in real-time. Great, so I can get the same system-calming affects by opening the movie in QuickTime Player, right? Right. But as soon as I quit QuickTime Player, the noise comes back. When you close the widget, the noise stays away forever (actually until you use some app other than Dashboard that opens and then closes access to the iSight). I thought I’d try to open the widget in Safari. No dice. Even after editing the widget so it would attempt to operate despite not being in the Dashboard – it silences the noise while the movie is visible, but the noise comes back after closing the web page. Get this: even turning off the movie in Mirror Widget, by clicking the little “i” in the lower left corner causes the noise to come back. Something about the (perhaps clumsy, but beautifully, wondrously clumsy) way that Dashboard closes up shop for the widget while the movie is active causes the system to get “stuck in good mode.”

I decided to whip out Shark, Apple’s profiling tool from the CHUD toolset. I figured there must be something different about “my computer doing nothing” before and after the magic MWH. To get a fairly straightforward sample, I quiet all visible applications except Shark and the Finder. Then, with the noise blaring, I took a 2 second timed sample of “Everything.” This means all processes on the system that are using any CPU time at all for anything. Then I silenced the MBP with the MWH, and grabbed an identical 2 second sample. I did this a few times to make sure there were no statistical anomalies coloring my view of what’s going on. The difference between the two samples? Almost absofrickinlutely nothing. In fact, nothing of interest I can pinpoint after multiple sessions of sampling at different rates, over different durations, and using different sampling configuration.

The Mirror Widget is magic. I use it and love it. Be warned that as soon as you use your iSight again in another app, and then quit, the noise will come back. But other than that, I now switch my allegiance to Mirror Widget. I just wish I knew why it does what it does. Maybe somebody with more Shark skills than I can get to the bottom of this.

Update: Supporting evidence that the silence is a side-effect of a poor “cleanup” from Dashboard: opening mirror2.mov in QuickTime Player and then force-quitting QuickTime player produces the same “permanent” fix to the system. Also, opening Photo Booth (or I presume any other iSight-using app) and force-quitting it while the silence is golden will achieve the same result. Getting closer to an answer!

More: Apple’s “WhackedTV” developer sample also eliminates the noise if you add a video track in the app (defaults to iSight) and then quit. Apparently however it cleans up or doesn’t clean up upon quit is also well-suited to leaving the Mac in quiet mode.

Update 2: I decided to hack the WhackedTV example to produce the simplest possible app that can shut the MBP up and immediately quit. This would make a suitable login item, and can be manually relaunched any time the noise comes back (e.g. after using the iSight for something real). Download MagicNoiseKiller (Intel only) today!