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.