Larry Osterman's WebLog

"It's worth a read."

I agree.  It made me chuckle.  I do appreciate its honesty.[*]  Here's the good news:

'There is some good news in this story:  Windows developers have made significant progress over the years in reducing glitching across key multimedia scenarios.  For example, music playback on an otherwise "lightly loaded" system can be generally as smooth as that $20 CD player.'

So, simply by not using your computer for computing, you can get your $2000 computer to perform as well as that $20 CD player.

(Um, except if your $2000 devices were designed for XP's version of DRM but not Vista's, but that's another story.)

Anyway, I thank Microsoft for this honesty.

Now may I suggest that more priority be given to not losing keyboard input and not losing mouse input, even if that means the audio chain will glitch a bit when some silly user is trying to use their computer for computing.

If a user is really dissatisfied because of the glitches, give them a refund for the proportionate cost of Windows Media Player (and DRM chain) that was tied to their computer purchase, and let them buy a $20 CD player.

[* Yes I admit that Microsoft sometimes tells the truth; I wish it would happen more often.]

When the frequency of lost input is correlated with CPU load and not correlated with a loss of hardware, I think the OS is the reason.

s/loss of hardware/choice of hardware/,sorry

Sorry for a third comment in a row, but I just remembered one more consideration.  Although lost input is correlated with CPU load, it's even more strongly correlated with hard disk load.  I still think OS is the reason.

"a couple of network devices that freeze the CPU solid for 250 milliseconds every few minutes"

If the network devices do DMA and lock the memory bus for 250 milliseconds then I agree that crappy hardware is the cause.  I suppose the same could be possible with IDE controllers if they can queue enough commands that they'll occupy the bus for that length of time.

But if I were to make a bet, I'd still bet on it being drivers rather than devices.  And at least in the case of IDE controllers, these are drivers where Microsoft has identified Microsoft as the provider.

It seems to happen much more frequently on Vista. I don't know if it's related to the new hardware or it's Vista's redesigned audio stack, but it does happen more often. I have logged a bug on connect that is still open (will probably get closed w/o fixing, as usual!)

What's interesting is that for a lot of people, audio on Vista glitches a lot more than it did on prior versions of Windows. While a lot of that was driver-related in the early days I still get occasional audio glitches under very heavy load (usually I/O load, not CPU load), something that just didn't happen on a far slower PC with XP.

I love Vista's new audio stack for its features, but it does seem to throw in the towel a bit quicker than XP. I would like the reasons for that explored, not audio glitches in general.

Maybe I'm just lucky, but I don't get *any* glitches on my $1500 HP laptop (dual core, 2GB ram, GForce7800.. nothing extreme) using Vista.

Even when I launch two compilations in two different VS2005, and in the same time print big documents, test web apps on my localhost and other things, I do not get any glitches. None..

I'm thinking now if I should get my ears checked?

Yeah yeah yeah, so it's hard.

Why then was XP able to do a less-glitchy job on the same hardware?

With the exception of changing resolution in (insert game name here), I can't say I remember XP glitching.

Under Vista, it's quite frequent (once or more per day). And yeah, it definitely tracks with CPu and/or disk activity.

I thought it was the dumbass-seeming decision to move audio into a process in user mode, competing with all the other user mode processes, but I've been told this "shouldn't be a problem".

Bottom line, I don't really care, I just want it to work well again, like it used to.

I'm also experiencing way more glitches on vista than on XP.

My home machine is dual core and is horrible for playing mp3 now. I upgraded the same machine from XP which played audio flawlesly. I never ever had heard a glitch on xp.

My work machine has 8 cores (2 processors) and it glitches as well.

The thing that's surprised me about glitching in Vista is its inconsistency when I've encountered it.  

Certain audio, e.g. the .mp3 podcasts from marketplace.org or from This American Life, consistently glitch once per second when I play it in WMP, but works in Winamp.  More oddly, this started happening over a weekend when I wasn't using the computer (it being my work machine).  I'd listened to a particular podcast last week Friday in WMP11 and it worked ok, came back on Monday and it didn't.  And even more oddly, music MP3s that I've ripped from my CDs continue to work just fine in WMP w/o any glitching at all.

I suppose it might be related to some driver somewhere, but the behavior is really odd and I have no clue what might have changed over the weekend to result in the different behavior.  I've pretty much just resigned myself to using winamp for podcasts for the foreseeable future.  It's too bad, I like WMP's library management rather more.

Measurements don't mean a thing when compared to real world experience.

The fact is that Windows XP glitches a lot less often than Windows Vista on the same hardware.

The fact is that audio glitches on Vista happen when you least expect it to. Even under low CPU load.

Hardly the way to attract the crowd you were targeting with the revamped audio stack...

"Actually the not losing input is as often as not due to external hardware (I have this PoS KVM that continually loses the "m" key, for example - drives me up the wall)."

Then shouldn't you have written "drives e up the wall" then?

$20 CD players have certain other advantages;

1) They can always pull from the source at > 1X (can't do that with VOIP)

2) They can prefill a hardware buffer of as large as a few seconds in anticipation of events that would otherwise cause a glitch (requires expensive memory cache)

In summary, you can't beat dedicated hardware.

Yes, I can't wait for the second part, as I too do not understand why DMA doesn't appear to be used like it used to be. I mean, back in the 386/486 days, the "solution" to sound glitches was to use DMA.

Initially, the spare onboard DMA channel was used, but this very quickly because a single point of contention amongst devices (other than just Audio). So the sound card designers incorporated their own "DMA" hardware, and the Engineering term "Buss-Master", then became a marketing one.

I fail to see a valid excuse. If hardware costs $2,000 and it has drivers that behave properly, then the only one to blame is OS itself. Most likely the scheduler.

What I do not understand is why people are so obsessed with inventing "smart" schedulers which have uneven quantums (time slices), various foreground boosts, and load of other "interactivity level prediction" crap.

Scheduler should do what it is meant to do -- schedule. If you want realtime operations to work in realtime, then scheduler "output" must be predictable 100% of the time. In other words, you must have fixed time slice, not variable, and no stupid boosting and messing with priorities.

Likewise, DPCs and ISRs should have fixed slice, if they don't do what they are supposed to do in that time window, then sorry, they are going to be postponed. If that means crash and loss of data -- so be it, but we will soon be able to distinguish good hardware (and driver) vendors from the bad ones and those lazy driver developers would be forced to optimize for performance down to µs, not ms intervals.

I say, give everyone 10ms slice and just change how often they run based on priority which user can set between say -128 (idle) and +127 (realtime). Then you will have no glitches whatsoever.

Larry, I said "if it has drivers that behave properly". Most of them do, except perhaps for really cheap "made in China" noname devices.

If you believe otherwise (i.e. that in the majority of cases drivers do not behave properly) then it is even worse because:

1. It is Microsoft's fault for not enforcing driver writers to adhere to the certain level of quality.

2. It is Microsoft's fault for raking money on WHQL certification which doesn't really add to the end-user experience except for the fact that it inflates hardware prices and delays driver updates until certification is obtained for each revision.

The idea of WHQL is good, but unfortunately very poorly executed one.

Larry, last time I checked vendors had to pay for each WHQL certification.

In the article you linked, Raymond wrote:

"Some unscrupulous drivers will detect that they are being run by WHQL and disable various features so they pass certification."

And what does Microsoft do about that? Let it be?!? Come on! If you discover cheating, you don't give them certification, you keep the money, publish the list of cheaters on your web site and leave them scratching their nasty, ugly heads.

But no, you decide to put up with it just so you can boast about how many devices work with Windows. Marketing over engineering, I heard of it.

And about this:

"Of course, they also run dog slow in the WHQL lab, but that's okay, because WHQL is interested in whether the driver contains any bugs, not whether the driver has the fastest triangle fill rate in the industry."

Please, tell me it is not true. Tell me that WHQL cares about speed. At least it should care about ISRs and DPCs not going over some predefined number of µs or ms. If they do, then driver should not pass certification. Why at least minimal ISR and DPC processing speed is not enforced?

As I see it, WHQL is completely useless as it is.

Oh, and as for money, last thing I heard was $250 per certification. Considering that some IHVs (especially video card manufacturers) have to update their drivers very often (because of new hardware, game compatibility fixes, and workstation ISV fixes) and they are required to certify them, that surely isn't a pittance as you put it.

$250 per certification does seem like a lot, but when you factor in the labor time, (I'm sure they don't use minimum wage interns for the certs) and the testing hardware and logistics required, I doubt Microsoft is making big bucks on it. Perhaps they do sometimes, but still, for something as huge and important as WHQL is, $250 isn't all that bad.

My experience with glitching in Vista is mixed... it does tend to glitch at more unpredictable moments (XP as you said was easy to cause to fail0, but whether it really does it more or less is tough to quantify. Knee-jerk reaction is to say yes (my first-couple-hours experience with vista was TERRIBLE), but since then it's been pretty good, and with more level headed thinking, I'd say it's on par.

What I do wonder about though, with regards to the very low-latency audio required for pro-audio uses that the linked article discusses, is why you guys removed kernel streaming. KS seemed to be a hell of a good way to get your audio handled at the lowest level possible to keep the latency down and stability up, and it was a damn good feature to have. Vista seems to have potentially abstracted itself a bit too far from the hardware for the professional musician to consider it. I may be wrong though. Larry, if you've discussed KS before, I must have missed it! I would be interested to know what you think about it though! :)

So, is there any chance to find out why WHQL doesn't enforce maximum ISR and DPC time? That would be a tremendous step forward in driver quality.

Interesting, an audio-processing buddy of mine thought that KS had been removed, which was a big stumbling block for him to upgrade to Vista. I think he'll be very pleasantly surprised :D