Sometimes the expectations of our customers mystify me.
One of the senior developers at Microsoft recently complained that the audio quality on his machine (running Windows Server 2008) was poor.
To me, it’s not surprising. Server SKUs are tuned for high performance in server scenarios, they’re not configured for desktop scenarios. That’s the entire POINT of having a server SKU – one of the major differences between server SKUs and client SKUs is that the client SKUs are tuned to balance the OS in favor of foreground responsiveness and the server SKUs are tuned in favor of background responsiveness (after all, its a server, there’s usually nobody sitting at the console, so there’s no point in optimizing for the console).
In this particular case, the documentation for the MMCSS service describes a large part of the root cause for the problem: The MMCSS service (which is the service that provides glitch resilient services for Windows multimedia applications) is essentially disabled on server SKUs. It’s just one of probably hundreds of other settings that are tweaked in favor of server responsiveness on server SKUs.
Apparently we’ve got a bunch of support requests coming in from customers who are running server SKUs on their desktop and are upset that audio quality is poor. And this mystifies me. It’s a server operating system – if you want client operating system performance, use a client operating system.
PS: To change the MMCSS tuning options, you should follow the suggestions from the MSDN article I linked to above:
The MMCSS settings are stored in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile This key contains a REG_DWORD value named SystemResponsiveness that determines the percentage of CPU resources that should be guaranteed to low-priority tasks. For example, if this value is 20, then 20% of CPU resources are reserved for low-priority tasks. Note that values that are not evenly divisible by 10 are rounded up to the nearest multiple of 10. A value of 0 is also treated as 10.
The MMCSS settings are stored in the following registry key:
This key contains a REG_DWORD value named SystemResponsiveness that determines the percentage of CPU resources that should be guaranteed to low-priority tasks. For example, if this value is 20, then 20% of CPU resources are reserved for low-priority tasks. Note that values that are not evenly divisible by 10 are rounded up to the nearest multiple of 10. A value of 0 is also treated as 10.
For Vista, this value is set to 20, for Server 2008 the value is set to 100 (which disables MMCSS).
If you're an Office dev, you have to run server. Only work system I have that runs a client is my laptop.
How is a dev supposed to actually work without good tunes? Don't you realize that not understanding your user base has impacted Microsoft dev productivity? <g>
In the good old days (circa NT 3.51 and prior - I forget when that slider went away), there was a slider for how to tune your server. Maybe we should have a Win2k8 Developer's Edition.
The VirtualDub example was on a Windows XP machine. I doubt that MMCSS and Vista would have made a difference, as the video playback was running at a very high data rate (>20MB/sec) and wouldn't have tolerated even moderate sharing of the disk.
IMO, if audio is breaking up at any regular rate, the result should be called broken rather than degraded or prioritized. I'd say that if the user has sound enabled and is playing something, there is a reasonable expectation that the OS should try to keep it from breaking up, since otherwise the user could simply disable audio. I wouldn't necessarily suggest retuning Server to remedy this given its primary intent, but I think it's a valid complaint.
As for why the breakups occur, my experience has been that sample rate conversion in Vista contributes to this problem since the higher quality converter takes more CPU time. I've recovered ~7% of a 2GHz P4 by matching output streams to the current mixing rate. I'd also suggest again the ability to trade off latency for resilience as I really don't need 10ms latency when playing a music file.
"People also forget about how really fragile their audio experience was on that 300MHz Celeron box. In 1998 there was only one app that could play audio on the system at a time (the mixer functionality was added in WIn98). And if anyone did anything that vaguely stresed the CPU or disk, audio glitched like crazy."
Still happens today on my 4x2.4GHz desktop. A particular IDE controller card I've got seems to do a mix of hogging the PCI bus and spamming interrupts, causing the whole system to glitch (audio stutter, mouse driver dropping mouse movements, desktop freezing, the works).
Torkell: I'm willing to guess that the IDE controller is configured to run in PIO mode not DMA mode. When a disk controller's in PIO mode, it has to transfer the entire disk read one byte at a time when processing the disk interrupt.
That was fine back in 1984 with MS-DOS but not these days. Unfortunately hardware manufactures don't always realize this.
This would be an acceptable answer if it weren't for the fact Microsoft distinguishes its product editions by arbitrarily disabling different parts of the operating system. It's not all that hard to see that there may be a customer somewhere who needs client-like multimedia support with server-like background tasks, perhaps, say, for running a display advertising system.
Windows Server 2008 ships with audio completely disabled by default. This should be your first hint that Server isn't optimized for audio.
Larry: I'm pretty sure it's running in DMA, not PIO (it's a Promise 133TX2, if you're interested). Windows claims it's using DMA, and I can pull large files off it faster than PIO should handle. The odd thing I've noticed is that lots of small files (or working with lots of metadata) tends to be more of a problem than a few large files - I usually trigger it with a backup script that scans for new files. It's probably some weird firmware bug or implementation detail, as a different IDE card (Highpoint RocketRaid) never caused any problems.
Speaking of DMA/PIO, last week's discovery is that a SATA drive can run in PIO mode. I did something or other to a SATA cable (probably bent it too much), and the result was an event log full of disk errors, followed by some strange bluescreens (i think one was session3 init failed) and eventually Windows dropping the drive down to PIO. My computer comes up with "interesting" ways to fail...
@ Richard Berg, how is Remote Desktop neutered? :) TS RemoteApp? And also software RAID or did you mean hardware RAID? How is web development neutered? IIS limitations? I would like to know.
People run server OSes as workstation simply because it comes with all the CPU/RAM gobbing, "user-friendly" crap OFF.
Then we can manually turn back on what we need.
Koro: That's fine. Read my article again - I NEVER said that I had a problem with people running server products day-to-day.
I said that I was surprised that people expected that servers would be as responsive to the console as a client.
One would think that today when 4GB of RAM is a commodity the system could prefetch entire audio file to memory.
Furthermore, decoding mp3 and wma doesn't even register on a CPU usage meter with today's multicore CPUs.
So if the I/O and decoding aren't the bottlenecks for audio playback WHY IT DOESN'T WORK FLAWLESSLY ALREADY?!?
And what is that nonsense about audio stack running at priority 15 and a lot of other processes running at higher priority?!? Audio stack should run with a real-time priority. Period. No other task should have higher priority. Not even video because you are more likely to notice dropped audio samples than dropped video frames.
Finally, if the OS has so many higher priority tasks to begin with, then that is the sign that the priority system has been seriously abused. If everyone has high priority then nobody does. It is as simple as that.
"It is as simple as that."
Gosh, Larry... after all this time that you've been working on Windows audio, you still haven't realized just how simple all of this is. It's a good thing we have guys like Igor around to tell us how all of this should be done. Maybe you should hire him.
Igor: It's a SERVER. The people who own and run servers tend to think that servers should spend their time doing things OTHER than rendering multimedia.
And there are things that run at higher priority than user mode threads.
Larry, you're preaching to the choir. Well, to me anyway. <grin> I tried and tried to get Media Player removed from the Desktop Experience Pack exactly because of the audio issue but someone who gets overpaid at multiples of what I do said "uh... no."
Such is life! I suppose that those "Server as Client" users on 2008 also disable UAC so that they can burn music CDs and such too. Ah well, such is life!
With all due respect for your knowledge and experience -- THERE IS NO REASON NOT TO PROPERLY SUPPORT AUDIO ON A SERVER SKU.
If you don't play anything, and leave audio services disabled (as they are by default) it won't affect the OS performance in any way, except that for those who want audio to work, it will work properly once they enable what needs to be enabled.
Furthermore, going by that weird logic of yours, why don't you rip out the GUI from server SKUs?
After all, nobody looks at the console screen either, and we all know that video card DPCs take a lot of CPU time -- much more than any audio card out there including the professional ones.
Finally, going back to SERVER .vs. CLIENT -- the only differences (even though Microsoft would like us to believe that there is more to it) are in scheduling quantums and priority boosts, security settings, and services configuration.
There is no special SERVER kernel, no special files, no voodoo magic that differentiates SERVER from CLIENT OS. IT IS THE SAME PRODUCT CONFIGURED SLIGHTLY DIFFERENTLY.
If you ask me, the biggest difference between SERVER and CLIENT is in the PRICE TAG.
If you are ignorant when it comes to Windows OS architecture, computer hardware and electronics in general that doesn't mean everyone is. I beg to differ.