[chuck-users] win32 woes

[Robin Davies]

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. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20070607/0378b397/attachment-0001.htm