But before everyone starts shouting how much Vista is less performing than XP: I have done tests with both Vista and XP on my machine using Live 7 and a Midi Loopback test with three different Asio interfaces (2 x PCI + 1 x USB) and four different Midi interfaces (2 x PCI + 2 x USB). Generally I found performance to be on par with CPU load of Vista being only 1-2% higher and Midi latency+jitter being formidable on both plattforms! The only things that compromisse Vista's performance on my machine are:
1. A bug with either Live's GUI (both 6.10 and 7.01) or Nvidia graphic-card drivers that dramatically increases CPU load with specific GUI elements of Live (especially when using Simpler). Look here for more specific informations:
http://www.ableton.com/forum/viewtopic.php?t=81821
2. Badly implemented hardware-drivers like the drivers of my Audiophile 24/96 and that run perfect for Audio but introduce additional Midi latency of about 3 ms while all other Midi interfaces perform better than that (still latency remains below 4 ms though).
My computers specs are: A64 X2 @ 2.83 GHz, 2 GB RAM (@DDR566), Nvidia 4 chipset, NVidia 7800 GT, 1 x 150 GB WD Raptor (10000 rpm), 1 x 250 GB Hitachi 7K250 (7200 rpm).
So if you find Vista to be a performance hog on your machine I suggest that you first try disable of any services that you might not need (ReadyBoost, ReadyDrive, Windows-Defender, User Account Control etc). Only do this if you know what you are doing though (especially when disabling Defender and User Account Control). If you need advice on these service use an internet search machine please, don't ask here!
This post is meant to mainly discuss low-level "under the hood" improvements of Vista, not the pros and cons of Aero or any other fancy GUI related shit-chat (if you want XP with a nice and fully customizeable GUI buy "Windows Shades"). If you ain't interested in this tech-talk then just skip this thread please (yes, that means you Nebulae
).I will only list the relevant kernel improvements in short, for more insight look here (german language):
https://thesource.ofallevil.com/technet ... spx?loc=de
1. Thread/process scheduling
Before Vista thread scheduling was handled on a set interval timer that lead to "unfair" distribution of CPU time among threads even if their are set to the same priority.
Before Vista ("Leerlauf" translates to "Idle"):
Vista:
2. Multimedia Class Scheduler (MMCSS)
In short this is meant to guarantee audio-streaming without drop-outs. Yes, this means that our precious DAWs should be able to use this fancy new feature to get extra-high-multimedia-audio-streaming-über-priority! Unfortunately this does not come automatically, DAW manufacturers need to make use of it. As far as I know only Sonar uses this yet.MSDN wrote:The Multimedia Class Scheduler service (MMCSS) enables multimedia applications to ensure that their time-sensitive processing receives prioritized access to CPU resources. This service enables multimedia applications to utilize as much of the CPU as possible without denying CPU resources to lower-priority applications.
...
The key also contains a subkey named Tasks that contains the list of tasks. By default, Windows supports the following tasks:
Audio
Capture
Distribution
Games
Playback
Pro Audio
Window Manager
3. Filesystem I/O aka I/O Priorisation
Beside other improvements like symbolic file-links (similiar to what Unix OSes offered forever) and better I/O cancellation there are two important improvements that seems potentially very useful for music-creation: I/O Priorisation and bigger I/O Requests.
I/O Priorisation:
Before Vista access to the harddrive/files could not be priorized, only CPU time could be priorized. Try running an antivirus-scan or defragger at low/idle CPU priority while working with another I/O intensive application in the background on Windows XP. You will notice that the background-running low priority task will still slow down the harddrive performance of your foreground task considerably.
With Vista file I/O can have priorities for hd-access just like threads/processes can have priorities for CPU-access. Unfortunately there is no priority "High" yet, this will be introduced in future Windows versions. But scheduled tasks like Index scanning/building or Windows-Defender/Antivirus kind of applications should be running at "low" or "very low" priority and thus stay out of the way of normal applications that run at "medium" priority.
But far more important: Applications can reserve harddrive bandwidth! That means that DAWs could reserve a minimum bandwidth for track/sample playback/recording. In conjuction with the MMCSS a DAW should very well be able to guarantee glitch-free operation as long as your CPU and HD can deliver the load physically.
Bigger File I/O Request
Before Vista all file operations (aka transfering data from disk to memory and vice versa) was divided into a load of I/O request of only 64 kb size each. Even if an application send a much bigger I/O Requests it was divided into chunks of 64 kb. For example, copying a file of 10 mb size had to be divided into 160 I/O requests of 64 kb each. This creates quite some overhead for initiating I/O transfers and interaction with Kernel space.
In Vista I/O Requests can be of any size. For example the Copy functions of Explorer and the command-line use I/O Requests of 1 mb size now, which divides our 10 mb large file into only 10 chunks instead of 160. I don't know the specific performance benefits, but feel quite comfortable knowing that DAW related file-operations ain't divided into tiny chunks of 64 kb anymore. I am assuming that DAWs use bigger I/O Requests only where needed and that they use smaller ones where proper, given that they should know best how to handle their files.
4. WaveRT audio-streaming drivers
Actually the WaveRT driver-modell is nothing but a substitution for ASIO drivers and it even only seems to work on PCI/PCIe but not on USB/FW. So we might ask ourself what use there is to exchange the long proven ASIO drivers with a new Microsoft teinted driver modell at all!? Well, I don't know about you, but ASIO drivers often prove to be less than ideal performing for many hardware devices given the fact that they are kind of forced upon the native driver- and audio-system of Windows I don't even wonder about that. Mac OS features Core-Audio, a well defined standard-port for all audio-devices. Now Windows Vista at least goes into that direction, though some features like using multiple audio-interfaces concurrently still seem to be missing.
Unfortunately neither audio-hardware manufacturers nor software-coders seem to be interested in support WaveRT (yet). Only Sonar - because of their rather strong connections to Microsoft - seems to support it until now. That is quite a shame, because even with little to no driver support by hardware there is one very important piece of audio-hardware that fully supports WaveRT: Onboard PCI-Audio interfaces! No more messing with Asio4All I say!
Wikipedia wrote:For audio professionals, a new WaveRT port driver has been introduced that strives to achieve real-time performance by using the multimedia class scheduler and supports audio applications that reduce the latency of audio streams. As a result, user mode applications can completely govern streams of audio without any code execution in the kernel during runtime. WaveRT allows the user mode application direct access to the internal audio hardware buffers and sample position counters (data in the memory that is mapped to the audio hardware DMA engine). It allows applications to poll the current position in the DMA memory window that the hardware is accessing. WaveRT also supports the notion of a hardware generated clock notification event, similar to the ASIO API, so that applications need not poll for current position if they don't want to. WaveRT however works only with PCI, PCI Express or onboard audio devices; it does not work with USB or FireWire interfaces which are more widespread in the professional audio industry.
Microsoft Hardware Developer Central wrote:The WaveRT port driver supports audio applications that reduce the latency of audio streams by using the real-time scheduling support that is available in Windows Vista and later. Hardware innovations, such as the low-latency isochronous transfer modes of PCI Express devices, complement real-time scheduling.
To take advantage of these improvements, an audio device should be able to play or capture audio data with little or no intervention by the driver software. If designed properly, the audio hardware should require no help from the driver from the time that the audio stream enters the run state until it later exits that state. The result is low-latency audio that consumes few host-CPU cycles and is free of timing glitches.
The client for the WaveRT port driver is typically the global audio engine. The engine is the operating-system component that mixes the playback streams from the currently running audio applications and writes the mixed stream into the cyclic buffer. The audio device pulls the stream from the buffer and plays it.
