HomeHaving spent quite some time attempting to fix audio gapping in my computer, and having delved into the underlying technologies a bit, I have concluded that there are very few software configuration changes a person can make that will have a meaningful impact on audio performance. Perhaps the most significant configuration option available is to ensure that video cards and other devices are not hogging the PCI buss through excessive PCI latency settings. I will discuss this in another topic.
My original approach to audio gapping was to throw hardware upgrades at the problem. I then began thinking about using performance monitoring as a way to help make decisions as to whether hardware was in fact a bottleneck, and if so, which component upgrades would be helpful.
The performance metrics exposed by Ulysses are neither secret nor profound. Microsoft has both written a book on performance tuning and provided a free performance monitor inside the Windows 2000/XP operating systems. This documentation is lengthy and not particularly accessible to the casual user, and the performance monitor tool has severe interface and operational limitations as well. What I am providing to you with Ulysses is the distillation of my understanding of these topics into what I consider to be key metrics for identifying the kinds of stress that can impact audio performance.
Ulysses does not analyze the data, nor does it tell you what changes you should make to your system. What it does do is replace some of the guesswork with insight into what is going on in your system. I recommend that you observe it when your system is doing well, when it is almost ready to fail, and when it is gapping, and get a feel for how the components were behaving under these conditions. I also think it is helpful to approach Windows performance analysis with a couple of key points in mind.
Any discussion of Windows performance with musical applications should begin with the perspective that this operating system was not orginally designed for the type of task we seek to put it to.
To provide perspective, I will start with the source, and I am including in its entirety an article from the Microsoft KnowledgeBase which provides an excellent discussion of their design objectives for the NT architecture, which forms the foundation of Windows 2000 and XP, as it relates to RTOS. I will then discuss how this relates to the heart of musical processing, buffering and latency, and then, of course, turn my attention to the protagonist of this particular production, the Ulysses Performance Monitor.
This article was previously published under Q94265
You can use a variety of criteria to measure the performance of a real-time system. The following are examples of the kinds of measurements that might be used to determine real-time throughput:
Because such specifics are hard to measure, this article provides a general discussion of the suitability of Windows NT as a real-time system.
Users often want a total program development/GUI user environment, virtual memory, and so forth, without any corresponding reduction in response time. Real-time systems, however, are dedicated systems for the duration of an "event" During that time, the system is essentially locked, and no other activity can take place except that real-time event. (Note that very few situations demand microsecond or millisecond response time.)
Windows NT has the same basic structure as VMS. Windows NT has more efficient mechanisms than RSX-11M. It has a better design than VAXELN, which is a real-time embedded OS toolkit. All three of these systems are very successful.
Although Windows NT has good real-time capabilities; it is not designed to compete with a special purpose real-time system. If you need such a system, obtain the special real-time hardware and supporting operating system.
The bottom line is we wish we had an RTOS for our musical toys, but we don't. While it wasn't designed with the recording and playback of music in mind, Windows is where a lot of the applications are. Due to economies of scale, it is less expensive to purchase an Intel/Windows computer that is 10 times more powerful than a similarily capable RTOS platform, and hope that the excess processing capacity will enable the computer to be able to, without fail, process the hardware buffer on the I/O card in a timely fashion. Naturally there is also the benefit of being able to use this computer for all sorts of non-musical activities.
Any operating system communication with a hardware device is triggered by an interrupt. An interrupt commands the CPU to suspend whatever thread it is processing and turn its attention to the request presented by the interrupt. There is a certain amount of overhead associated with interrupt processing which includes the saving of the current execution context. To process audio one sample at a time, at the rate of, for example, 44,100 samples per second is not practical given the capabilities of our readily available systems.
Interrupt overhead is reduced to managable levels through the use of buffering. The I/O hardware which is capable of running at the full sample rate places samples into a buffer. If the buffer can hold 1024 samples, the CPU must be able to empty it every 23.2199 milliseconds, or about 43 times per second. If it fails to do so we meet our nemesis, the evil with many names: buffer underrun, pop, gap, snap, or maybe our application program simply puts up a message box and stops processing.
The buffer provides its benefits at a cost which represents our other nemesis: Latency. If the buffer gets emptied every 23 milliseconds, the playback is 23 milliseconds behind. We hit the key and the virtual synth plays a noticeable moment later. The singer would hear their voice with an echo that makes it impossible for them to sing properly.
This, then, is the crux of the computer music balancing act--achieving a low enough latency while still remaining 100% underrun free for as many hours as we may require. And for the many of us who are not satisfied with our latency, we throw money at hardware and throw our time into tuning, configuring, and sound-device swapping
Another design objective of the Win2k/XP design was to make it run well under a wide variety of circumstances and not expose tuning "Knobs" to the customer. Presumably the idea was to reduce the number of problems and service calls caused by clueless and heavy-handed tinkerers. The "self-tuning" functionality does less than one would hope, but Windows does make some internal adjustments based on workload. Of particular interest to us is the performance-enhancing File Cache which is made larger when programs use less of the available physical memory.
There are a variety of hardware-device-configuration kind of things that are done and can be done such as moving the audio card to a PCI slot that doesn't share interrupts with another device, and so forth. Sadly, in this release, Ulysses is blind to the vicissitudes and vices of hardware and device drivers.