Tech - Stuff - Running Music/Audio Players on Windows 7 Laptops
While the particular player we use is a home-grown variant of an Open Source player these notes are generally applicable to running any player with a 'hiccup' free experience on a laptop (in our case). Hiccup in this context is a polite way of saying that the audio output on our Windows 7 laptops sucked really badly without some serious tweaking. It was vaguely useful for private listening (as long as you don't mind the occasional drop-out, stutter or explosion) but totally unacceptable for any public - even friendly public - usage without at least some - possibly even a lot of - messing around. From background reading the problem appears not to be unique to our configuration (Windows XP seemed good, from Vista onward 'real-time' system preformance seems to go rapidly downhill, with a following wind). The purpose of this page is to help others avoid the blind-alleys we navigated on our way to a perfect solution. Yes, we do now have a perfect music playing experience on Windows 7 - with some collateral damage. It is highly unlikely that the same solution set will hold true for any other hardware combination. However, we hope the general methodology will yield the required result - glitch-free music playing.
Note: We do not mention any of the vendors involved since we feel, from our background reading, that the problem is pretty widespread and therefore may consist of multiple hardware configurations and combinations. Under these circumstances it would be invidious to mention specific vendors. Though we have some thoughts on that topic as well....
The Problem
In general, the problem has almost nothing to do with processor power (unless you really are marginal in which case you probably should not be running windows 7). Our CPU usage was showing between 3 and 9% usage for the audio player depending on the features being used. We had tons of CPU capacity. And we were still dropping sound with alarming frequency (OK, it was not really meant to be a pun). The problem is entirely to do with latency. Essentially, the sound system is being blocked by kernel level (non-preemptable) drivers which run for too long, which in turn causes the audio buffers to be emptied but the player application cannot refill them due to the CPU blockage by the offending driver(s). The sound output runs in fits and starts and the sound output can vary from occasionally glitchy to consistently horrible.
Note: If you run CPU intensive tasks concurrently with music you will get the occasional drop-out, examples are periodic virus checker scans, apps that do a lot of initialisation or heavy calculation. Avoid or disable these apps during music playing or accept the occasional audio blip.
Note Futher: If you are using your laptop for late-night DJ work do not forget those regular (virus scanners especially) applications that burst into life at 3 AM, just when you are warming up.
The Solution
We messed around with a lot of features that typically operate at the user level. This helps a bit (especially if your audio player is running at over 30%) but it is playing with the symptoms not fixing the real problem. We googled and found lots of nonsense and proposed solutions that were nothing short of magical incantations (almost at the wear red socks level) but this page got us started on the right track and is well worth a good read through to get started. But read the following sections before you do anything. Here is how we fixed our problem after going up too many blind alleys.
The page above references gold-dust. The free utility DPC Latency Checker. This tool lets you calibrate the problem. It is small, quick to download and graphically displays the problem. If you have any red bars on the latency analysis display you have a serious problem. Forget running sound. The DPC download page and the tool text suggests that if you have yellow bars you should be OK. We found this not to be the case and until we were consistently in the green zone we still had problems. Perhaps only when the orbits of saturn and jupiter were in alignment but even with the occasional yellow bar (every 30 - 45 seconds in our case) we would get intermittent hiccups and burps. Green is good, everything else is bad. The page is also clear on one other point which is that problems are caused by kernel level (non-preemptable) drivers. Which make perfect sense. If you think about it. Which we didn't. So DPC identifies the problem and tells you when you have fixed it but does not provide the solution.
Our first runs of DPC Latency Checker was showing horrible clumps of red bars. So we went to Hardware Manager (via the control panel) and started disabling drivers and got lucky on our second attempt - a wireless LAN adapter driver. Since we didn't use a wireless LAN on this laptop, disabling it had no serious effect. If we were wireless LAN users we would have been faced with a possible trade-off between wireless LAN and music. A pretty shocking state of affairs frankly.
So with this wireless LAN driver disabled we now had DPC Latency Checker blip every 15 seconds, mostly green but every 30 - 45 seconds it was yellow. And the sound burped every 5 - 10 minutes. We were obviously on an edge somewhere. It drove us nuts looking for events on multiples of 15 seconds. We finally found our second piece of gold-dust. LatencyMon. Again free, again simple. This showed that most of the sytem activity at the driver level (click the drivers tab in the utility) was in the ACPI.sys driver. We wasted a couple of hours deciding not to disable the ACPI driver but played with the Power Options feature (via the control panel) since we thought it might effect the ACPI system indirectly. Complete waste of time. We went back to basics and the DPC Latency Checker page advice. It's a driver, stupid.
With much trepidation and a lot of background reading we went back to Hardware Manager and after some experimentation we discovered that disabling 'Microsoft ACPI-Compliant Control Method Battery' (under Batteries) stopped the problem in its tracks. We were solidly in the green with no blips and great sound. Far as we can tell the only effect is that we may not have such good control over battery exhaustion management when running without mains power and it appears that the system cannot differentiate between battery only and mains operation which means that the battery timer values (in the Power Options section) will always be used.
Bottom line in our case is that any time we want perfect sound we need to disable the wireless LAN and the battery management drivers and run with mains power - or take a risk and use a stop-watch if playing music while on battery-only.
Additional Notes: The following notes have been supplied by users. We cannot verify whether they work (too many configuration variables) but superficial examination suggests they could have an effect, depending on your configuration and usage and are well worth trying if you are still struggling to get glitch-free audio:
If you typically have multiple sound applications running at the same time (say, a player and Skype) then disabling exclusive control may help. To do this go to Control Panel-> Select Sound-> Select Playback tab-> select your audio output device and click Properties-> Select Advanced tab-> Uncheck 'Allow applications to take exclusive control of this device' -> Click 'Apply' then OK and dismiss all other windows.
The final issue was probably unique to us and - one hopes - would not normally apply to any commercial player. The music player application we were using read the music file on demand (while the music was playing) using a trivial single-buffered strategy. In general, this is a poor strategy and vulnerable to all kinds of problems. Especially in the case of Windows 7 where the kernel apparently holds off disc access as long as possible (possibly as a side-effect of a battery conservation strategy) and then periodically goes nuts with the disc. If you happen to be trying to read a music file, or access any file for that matter, at the same time the kernel (with maximum system priority) opens its disc reading floodgates then you are plain out of luck. Your userland app is very much low man on the totem pole. And the disc activity can intermittently last for a good couple of seconds. There is no apparent way of avoiding the problem - all you can do is work round it. In our case we modified the file access strategy to load the entire file into memory immediately before the song starts. Under these circumstances, the worst case effect may be a slight delay before the music starts (occasionally you see this, even with Media Player) but when playing starts, since the whole file is in memory, there is absolutely no latency effect. Perfect, glitch free, music every time.
Our actual solution may not, most likely will not, be true for every system - too many variables. Hopefully the methodology outlined will help find appropriate solutions for other systems. Without all those, tiresome, time-consuming, blind alleys.
Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.
