[Portaudio] WASAPI problem

[Robert Bielik]

I have a problem when trying to use WASAPI opening a device with 44.1k/6channels (exclusive mode) where it complains about AUDCLNT_E_UNSUPPORTED_FORMAT, but I can open the device fine using WDMKS... I'll debug more but thought I'd pop the Q if there any bells ringing... :)

I'd rather use WASAPI in this particular application as it "abstracts away" the topology demux (i.e. in WDMKS you see one device, whereas in WASAPI you might have Speakers/Line out/SPDIF/...), which is a PITA to get using Pin/node descriptors on the topology filter... (this is something that needs to be done though for a portmixer WDMKS implementation).

Also a question on max channels in WASAPI impl: It seems the max no of channels is retrieved from the shared mode default format (PKEY_AudioEngine_DeviceFormat), but that might not be the maximum channels a device can support in exclusive mode ?

Regards,
/Rob

[Ross Bencina]

Hi Rob

Post by Robert Bielik
I'd rather use WASAPI in this particular application as it "abstracts
away" the topology demux (i.e. in WDMKS you see one device, whereas in
WASAPI you might have Speakers/Line out/SPDIF/...), which is a PITA to get
using Pin/node descriptors on the topology filter... (this is something
that needs to be done though for a portmixer WDMKS implementation).

I don't know about portmixer, but it strikes me that there might be some
ramifications for PortAudio.

There are no hard and fast rules at this level, but I think there are going
to be some user expectations based on what other host APIs offer. Especially
if the info is available on the platform.

Without the topology info how does the current WDMKS implementation work? Is
the caller limited to opening such a device as a single multi-channel
stream? Can they select a subset of channels? Can they discover which PA
channels correspond to which hardware ports?

Post by Robert Bielik
From my point of view it would be desirable to at least be able to query for

user-readable names for each channel. You can do this for PA/ASIO for
example. Is that looking like a PITA too?

Cheers

Ross

[Robert Bielik]

I don't know about portmixer, but it strikes me that there might be some ramifications for PortAudio.

Yes, this is very true.

Without the topology info how does the current WDMKS implementation work? Is the caller limited to opening such a device as a single multi-channel stream? Can they select a subset of channels? Can they discover which PA channels correspond to which hardware ports?

Let's say you have 3 different input sources, Mic/Line/SPDIF, for WDMKS you will see only one input device (input pin), and the one that is used is what is chosen as default in the control panel (Vista & Win7).

For output you might have 2 different output pins on a device, in this case the WDMKS implementation will take the first and best pin that matches the selected output format, which in this case might be only "Speakers". So in essence, you won't be able to choose the other output pin through PA.

From my point of view it would be desirable to at least be able to query for user-readable names for each channel. You can do this for PA/ASIO for example. Is that looking like a PITA too?

No, this is pretty much what I was thinking of adding:
1. For a mux kind of input you'd get 3 different paWDMKS input devices, same device in each case but with a different mux setting (output would be analogous)
2. For several output pins, you'd get a different paWDMKS output devices, same device in each case but with different output pin selected (this should be pretty easy).

For a demux output, the case would be similar to 1.

For pins without name, they'd be given names like "Output N".

I have C++ code for traversing the topology graph, so the PITA is to convert this to C (de-objectifying the code that is)

/Rob

[Ross Bencina]

Post by Robert Bielik
Let's say you have 3 different input sources, Mic/Line/SPDIF, for WDMKS
you will see only one input device (input pin), and the one that is used
is what is chosen as default in the control panel (Vista & Win7).
For output you might have 2 different output pins on a device, in this
case the WDMKS implementation will take the first and best pin that
matches the selected output format, which in this case might be only
"Speakers". So in essence, you won't be able to choose the other output
pin through PA.

Ok, so in a multichannel scenario (say a card with 5.1 output) one "pin"
would cover all 6 channels?

Post by Robert Bielik
I have C++ code for traversing the topology graph, so the PITA is to
convert this to C (de-objectifying the code that is)

I don't think there's a strict requirement for all PA implementation to be
in C. pa_asio.cpp is C++ (since the ASIO API is C++). I guess it depends on
whether it's much more difficult to implement the topology traversal in C. I
could imagine if it's all COM interfaces it might be easier to manage in C++

Ross.

[Robert Bielik]

Ok, so in a multichannel scenario (say a card with 5.1 output) one "pin" would cover all 6 channels?

Yes.

Post by Robert Bielik
I have C++ code for traversing the topology graph, so the PITA is to convert this to C (de-objectifying the code that is)

I don't think there's a strict requirement for all PA implementation to be in C. pa_asio.cpp is C++ (since the ASIO API is C++). I guess it depends on whether it's much more difficult to implement the topology traversal in C. I could imagine if it's all COM interfaces it might be easier to manage in C++

It's not COM, but there are a lot of memory allocs and DeviceIoControl calls, and using C++ makes it easier to keep track of things. First though I'll check if there
is some minimal C approach that could be done with relative ease...

/Rob

[Dmitry Kostjuchenko]

Hi Guys!

I am sorry for delayed reply about WASAPI, just noticed message :)

Post by Robert Bielik
I have a problem when trying to use WASAPI opening a device with 44.1k/6channels (exclusive mode) where it complains about AUDCLNT_E_UNSUPPORTED_FORMAT

It shall be opening in exclusive. In my testing environment I have 7.1
and ability to set 6.1, 5.1, 4.1, Quad, Stereo and Mono. All these
configurations I tested and they worked.

Post by Robert Bielik
It seems the max no of channels is retrieved from the shared mode default format (PKEY_AudioEngine_DeviceFormat), but that might not be the maximum channels a device can support in exclusive mode ?

The format data are taken from IAudioClient with this function -
IAudioClient_IsFormatSupported and one of its parameters is Mode
(AUDCLNT_SHAREMODE_SHARED or EXCLUSIVE). So, if format data is
incorrect for Exclusive mode then I believe it can be due to problems
below WASAPI levels, e.g. driver provides some inadequate data.

Best regards,
Dmitry.

[Robert Bielik]

Post by Dmitry Kostjuchenko
It shall be opening in exclusive. In my testing environment I have 7.1
and ability to set 6.1, 5.1, 4.1, Quad, Stereo and Mono. All these
configurations I tested and they worked.

The device is of my own making, so I definitely think there might be a problem there... ;)

For the 5.1 config (which fails for me), what is the channel config, is it ..._5POINT1 or ..._5POINT1_SURROUND ? Or maybe you
have no control of that ?

Regards,
/Rob

[Robert Bielik]

Post by Dmitry Kostjuchenko
It shall be opening in exclusive. In my testing environment I have 7.1
and ability to set 6.1, 5.1, 4.1, Quad, Stereo and Mono. All these
configurations I tested and they worked.

Oh geez, setting the channel config on my device to _5POINT1_SURROUND makes it work... go figure...

But another question: I have a USB device (WaveCyclic) which I can drive reliably at 10 ms latency through WDMKS, but WASAPI will
not let me. Instead I get a whopping 167 ms of latency (exclusive, output only stream). Any tips here ?

Regards,
/Rob

[g4]

Hello Robert

Post by Robert Bielik
Instead I get a whopping 167 ms of latency (exclusive, output only
stream). Any tips here ?

Which OS?

[Dmitry Kostjuchenko]

Post by Robert Bielik
Any tips here ?

I am afraid it is beyond our control :) E.g. on WASAPI level all seems
to be done ok and 167ms latency is high enough to be stable. There are
cases although that high latency value on Exclusive mode makes
unstable audio (I got it for >500 ms), due to internal scheduling of
WASAPI I suspect, e.g. when internal buffers are too big. What if you
try smaller values between 20 and 40...

Dmitry.

[Robert Bielik]

Post by Dmitry Kostjuchenko

Post by Robert Bielik
Any tips here ?

I am afraid it is beyond our control :) E.g. on WASAPI level all seems
to be done ok and 167ms latency is high enough to be stable. There are
cases although that high latency value on Exclusive mode makes
unstable audio (I got it for>500 ms), due to internal scheduling of
WASAPI I suspect, e.g. when internal buffers are too big. What if you
try smaller values between 20 and 40...

Ok, I tried 10 ms, but got 167 ms... but I'll try with larger latency values.

Hmm... does really seem that WDMKS has a shoe to fill here... for the device in question (Edirol PCR-A30) I can actually
stream at < 10 ms latency.

/Rob

[Robert Bielik]

Post by g4
Hello Robert

Post by Robert Bielik
Instead I get a whopping 167 ms of latency (exclusive, output only
stream). Any tips here ?

Which OS?

Vista 32 bit

/R

[g4]

Post by Robert Bielik

Post by g4
Hello Robert

Post by Robert Bielik
Instead I get a whopping 167 ms of latency (exclusive, output only
stream). Any tips here ?

Which OS?

Vista 32 bit

I was under the impression that exclusive mode was broken on Vista, and
not properly fixed in SP1. Do you have a ready to compile example I can
try here?

The sample code in this article is hilarious. See if you share my sense
of humour :)

http://msdn.microsoft.com/en-us/library/dd370844%28v=vs.85%29.aspx

[Robert Bielik]

Post by Robert Bielik
Vista 32 bit

I was under the impression that exclusive mode was broken on Vista, and not properly fixed in SP1. Do you have a ready to compile example I can try here?

Hmm.. now that you mention it that sounds familiar...

The sample code in this article is hilarious. See if you share my sense of humour :)

I'd say that it's more scary than funny. One has to wonder if the code for Windows looks the same... ;)

But do tell which part you found most funny :)

/Rob