I5 iMac and Windows 7: Headphone jack usage makes 1 core extra crazy

Question

Hi. I wasn't even sure where to post this, but here goes...
I got a new iMac at the Apple Store a few days ago. The same day, I installed Vista Ultimate. Right away, I noticed that the cpu cores (in Task Manager) were in use, one at about 100%. The overall CPU Usage showed 35%. No apps in use.
To make a long story short, I never could figure it out.
So I went and bought Windows 7 Home Premium upgrade yesterday. Installed that (64-bit). Everything is great, but the cores were still going crazy.
Turns out that when I unplug my speakers from the headphone jack, it drops to 0% cpu usage! The performance didn't seem to have been affected by it, but it bothered me.
Any ideas what that was all about? Is that a driver issue on Apples part? I could assume it is because Apple doesn't support Win7 yet, but the driver cd contains lots of Windows 7 drivers, and it did the same thing in Vista.
Anyway, thanks.

Answer 1

I'm surprised to see this happening with the new iMac Core i5/i7s. I would expect Windows 7 to be better in that dept than Mac OS.
Did you manage to find and try to update audio device drivers? RealTek?
Mac OS on 2009 Mac Pro, have high cpu in audio, flash, java as well as iTunes - but not in Windows 7. If you monitor temps (Hardware Monitor for OS X, RealTemp and Everest Ultimate), you will see quick jump in temperate, which is normal, even launching windows or apps. But the Mac Pro is 20*C higher and stays there in OS X, but not Windows 7.
That whole 35%/100% would indicate thread locking going on. And more prone with Core i7 (4 cores, 8 virtual cores with hyper-threading).
The part of the older Windows kernel that had responsibility for managing scheduling was the dispatcher, and it was protected by a global lock. "The dispatcher database lock originally protected the integrity of all the scheduler-related data structures," said Kishan. "This includes things like thread priorities, ready queues, any object that you might be able to wait on, like an event, semaphore, mutex, I/O completion port timers, asynchronous procedure calls -- all of it was protected by the scheduler, which protected everything by the dispatcher lock.
/snip/
In the new kernel for Win7 and Windows Server 2008 R2, the dispatcher lock is completely gone -- a critical element of Windows architecture up until Vista, absolutely erased. Its replacement is something called fine-grained locking, with eleven types of locks for the new scheduler -- for threads, processors, timers, objects -- and rules for how locks may be obtained to avoid what engineers still call, and rightly so, deadlock. Synchronization at a global level is no longer observed, Kishan explained, so many operations are now lock-free. In its place is a kind of parallel wait path made possible by transactional semantics -- a complex way for threads, and the LPs that execute them, to be negotiated symbolically.
snip
In other words, keeping processors busy to reduce latency -- one of the methodologies that we were told years ago would help Vista -- actually reduces overall efficiency. Multicore processors work better when their logical processors (LPs) can be put to sleep, or "parked," and their active threads shipped to another LP.
Scuttling huge chunks of Vista architecture for a faster Windows