James, I can't speak to what the current implemenation is, but I've been in the underlying code before. The PortAudio audio library and DirectX don't entirely play well together due to conflicting assumptions and featuresets. Part of the problem with DirectX, increasingly so recently, is that there's no resonable way to enumerate available device modes, short of probing for them. This makes some sense. Consider the case of an audio device that will support arbitrary audio rates, that max out at 96khz, if there are 4 channels or fewer, but maxes out at 48khzif there are more than 4 channels. Essentially an audio device with an infinite number of modes, but with restrictions. PortAudio insists on enumerating all available device modes before it actually starts up, by doing probes of a finite, but very large set of audio modes. PortAudio is also based on the premise that 6 channels are 6 arbitrar independent channels; while directx insists that a channel should also be identified by a speaker position (a very unfortunate assumption when dealing with pro-audio, where a channel doesn't have a speaker position). Newer DirectX device drivers support WAVEFORMATEXTENSIBLE, which allows applications to request 6 channels, and also specify which six speakers those channels are associated with. For a given number of speakers, there are multiple reasonable configurations: e.g. 4 channels could be (Front L Front R Rear L Rear R), or (FL, FR, Center, subwoofer), or (FL FR, Center, Rear center). Currently, some DirectX devices will allow requests for 6 channels/(no speaker spec) via a non-extensible WAVEFORMAT spec, while others absolutely require a fully specified WAVEFORMATEXTENSIBLE, specifying the position of each speaker, before they will allow advanced audio modes. I have devices that will - support requests for 6 channel (no speaker spec). - will not support request for 6 channel (no speaker spec). - indicate that they will support various speaker/sample-rate configurations when probing, but fail to initialize in some of them. And things get even worse when there are input channels: the number of available output channels and/or the sample rates avaialble may depend on whether there is a running instance of a capture device. So portaudio's assumption that valid audio modes can be pre-enumerated fails. Total chaos. Mostly Microsoft's fault. Microsoft's position is probably that WAVEFORMAT requests with 6 channels are not legal; if you want 6 channels, yo8u must use WAVEFORMATEXTENSIBLE, and you must specify speaker postion. I get the impression that the message that this is a silly model for pro-audio devices may be sinking in, but I don't have high hopes. A plausible fix would be to extend portaudio to allow specification of speaker postion, or use WAVEFORMATEXTENSIBLE, and enumerate valid speaker configurations (in decreasing probability) until you find one that works. The probelm with the latter approach is that, increasingly, in Vista especially, a request for a particular speaker configuration may succeed even if the physical speakers don't match. (The mixer will remix channels). So, what would happen is that you may end up playing 6 channel audio (FR FL Subwoofer, RR RL, RC), even though your actual speaker configuration is (FR FR Center RR RL RC). PortAudio doesn't support WAVEFORMATEXTENSIBLE (I don't think). So, you may or may not be out of luck with respect to 6.1 support, depending on what your driver does. The simple solution, most probably, is to use ASIO drivers. Although chances are not good that a VIA chipset has ASIO drivers.