Discussion:
WASAPI: Getting an invalid Device Error in Exclusive Mode
(too old to reply)
Dinesh Iyer
2018-08-29 12:59:40 UTC
Permalink
Hi,
I am using the Oct 2016 version of PortAudio in my application. I am
currently supporting only Exclusive Mode WASAPI in my application. My app
works fine for most devices I have tested, except for a device that is
listed on my Windows sound manager as "STM32 AUDIO Streaming in HS Mode".

The device fails only when I use exclusive mode WASAPI with the error code
"paInvalidDevice". Appears to work fine in Shared Mode. I updated the
PortAudio WASAPI code to use the latest version from assembla but I get the
same error.

The device supports only 2-channel, 48000 SR, 24-bits per sample recording.
I have ensured to match these settings when calling Pa_OpenStream().

When I call Pa_IsFormatSupported(), I get an InvalidSampleRate error. The
same settings work fine in shared mode.

I used Reaper to access this device in Exclusive Mode and it appears to
work fine.

Looking for suggestions on how to troubleshoot this further.

Regards,
Dinesh
Dinesh Iyer
2018-08-29 18:26:42 UTC
Permalink
Hi team,
The specific hardware that is failing is below:
https://www.digikey.com/products/en?WT.z_cid=sp_497_0928_buynow&Enterprise=44&lang=en&Vendor=497&mpart=STM32F769I-DISC1

Dinesh
Post by Dinesh Iyer
Hi,
I am using the Oct 2016 version of PortAudio in my application. I am
currently supporting only Exclusive Mode WASAPI in my application. My app
works fine for most devices I have tested, except for a device that is
listed on my Windows sound manager as "STM32 AUDIO Streaming in HS Mode".
The device fails only when I use exclusive mode WASAPI with the error code
"paInvalidDevice". Appears to work fine in Shared Mode. I updated the
PortAudio WASAPI code to use the latest version from assembla but I get the
same error.
The device supports only 2-channel, 48000 SR, 24-bits per sample
recording. I have ensured to match these settings when calling
Pa_OpenStream().
When I call Pa_IsFormatSupported(), I get an InvalidSampleRate error. The
same settings work fine in shared mode.
I used Reaper to access this device in Exclusive Mode and it appears to
work fine.
Looking for suggestions on how to troubleshoot this further.
Regards,
Dinesh
Ross Bencina
2018-08-29 22:28:28 UTC
Permalink
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,

The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.

Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.

Ross.
Dinesh Iyer
2018-08-30 20:08:28 UTC
Permalink
Hi Ross,
I actually setup debugs and did more digging.

The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).

I verified that the PaStreamParameters contain the supported values for SR,
bits-per-sample and channel count.

I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.

Lines 2242-2245 have this code:
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}

Is this valid?

Hope this investigation helps.

Regards,
Dinesh
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-04 14:04:39 UTC
Permalink
Hi Ross,
I modified the lines of code 2242-2245 to say:
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit containers
(ints)
}

And the playback and recording worked as expected.

Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values for
SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-05 12:14:09 UTC
Permalink
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!

Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit containers
(ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values for
SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-06 08:28:08 UTC
Permalink
Hi Dinesh,

The line:

old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)

was valid for all devices until your case.

If valid data is >=20 normally Windows expects 32-bit continers (ints) as
wBitsPerSample and wValidBitsPerSample specify real data resolution.

Would you please make test and modify this line:

if ((params->channelCount <= 2) && ((bitsPerSample == 16) || (bitsPerSample
== 8)))

to such:

if ((params->channelCount <= 2) && ((bitsPerSample == 24) || (bitsPerSample
== 16) || (bitsPerSample == 8)))

Will it work either?

Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit containers
(ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values for
SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-06 12:06:19 UTC
Permalink
Hi Dinesh,

Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.

Therefore, would you please make another test:

1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;

2) in MakeWaveFormatFromParams() move these lines to the bottom of the
function:

old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;

E.g. right above 'return paNoError'.

Most probably the driver in your case does not accept erroneous nBlockAlign
and nAvgBytesPerSec because wBitsPerSample were changed to 32.

Will it work?

Will be waiting for the results of your test to make necessary adjustments.

Best regards,
Dmitry.
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers (ints) as
wBitsPerSample and wValidBitsPerSample specify real data resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit containers
(ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values for
SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-06 13:34:27 UTC
Permalink
Hi Dmitry,
I am running the changes now but I am curious how moving that code to the
bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after

if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}

and those computations were made immediately after this IF condition.

Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of the
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers (ints) as
wBitsPerSample and wValidBitsPerSample specify real data resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit containers
(ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values
for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-06 13:42:51 UTC
Permalink
Hi Dmitry,
The change you suggested did not fix the issue.

Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code to the
bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of the
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers (ints)
as wBitsPerSample and wValidBitsPerSample specify real data resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function in
pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values
for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-06 18:03:39 UTC
Permalink
Hi Dinesh,

Thank you for testing!

Would you please update PA's GIT to the latest, recompile and check how it
works now. I have committed necessary changes to WASAPI's implementation
with the improvement of the the selection of the format for Exclusive mode.
Would you please test new implementation. In my tests it works fine and I
hope will do so in you case too. Now PA will also test packed sample
formats, e.g. it will also cover your successful result when you changed
wBitsPerSample to 24.

Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code to the
bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of the
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers (ints)
as wBitsPerSample and wValidBitsPerSample specify real data resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function
in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in
this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values
for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_
IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-07 13:24:24 UTC
Permalink
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?

Dinesh
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check how it
works now. I have committed necessary changes to WASAPI's implementation
with the improvement of the the selection of the format for Exclusive mode.
Would you please test new implementation. In my tests it works fine and I
hope will do so in you case too. Now PA will also test packed sample
formats, e.g. it will also cover your successful result when you changed
wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code to
the bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of the
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers (ints)
as wBitsPerSample and wValidBitsPerSample specify real data resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function
in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported values
for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-07 14:46:08 UTC
Permalink
Hi Dmitry,
I am getting the same error after bringing in your changes to the WASAPI
code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.

Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check how
it works now. I have committed necessary changes to WASAPI's implementation
with the improvement of the the selection of the format for Exclusive mode.
Would you please test new implementation. In my tests it works fine and I
hope will do so in you case too. Now PA will also test packed sample
formats, e.g. it will also cover your successful result when you changed
wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code to
the bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit containers
(ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of the
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat function
in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in this
function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set the
BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is this
value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-08 09:26:14 UTC
Permalink
Hi Dinesh,

paWinWasapiExplicitSampleFormat is not required but it allows to force PA's
WASAPI implementation not to look for alternative close format.

Would you please set debugger's breakpoint to the line 2485. Will code
execution reach this breakpoint? If yes, please check contents of outWavex
and say what values
for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample are. If you
check logic of MakeWaveFormatFromParams(outWavex, &params, sampleRate,
TRUE) it will force packed sample format usage, e.g. requested 24-bits will
not be put into 32-bit containers.

Basically your input is welcome because you have such specific device.

Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the WASAPI
code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check how
it works now. I have committed necessary changes to WASAPI's implementation
with the improvement of the the selection of the format for Exclusive mode.
Would you please test new implementation. In my tests it works fine and I
hope will do so in you case too. Now PA will also test packed sample
formats, e.g. it will also cover your successful result when you changed
wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code to
the bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in its
original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT)
.
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set
the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is
this value that is being used in the call to IAudioClient_
IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are) returning
that error code. You can then use printf or MessageBox() to narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-10 15:46:42 UTC
Permalink
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for the
fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.

The failure happens on line 3016 in the call to IAudioClient_Initialize().
The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.

Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to force
PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will code
execution reach this breakpoint? If yes, please check contents of outWavex
and say what values
for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample are. If you
check logic of MakeWaveFormatFromParams(outWavex, &params, sampleRate,
TRUE) it will force packed sample format usage, e.g. requested 24-bits will
not be put into 32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the WASAPI
code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check how
it works now. I have committed necessary changes to WASAPI's implementation
with the improvement of the the selection of the format for Exclusive mode.
Would you please test new implementation. In my tests it works fine and I
hope will do so in you case too. Now PA will also test packed sample
formats, e.g. it will also cover your successful result when you changed
wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code to
the bottom would change anything. Reason I ask is that there is no further
changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for WAVEFORMATEX
structure wBitsPerSample must be strictly 8 or 16 for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in
its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set
the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is
this value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return error code
you're getting and try to triangulate which site(s) is(/are)
returning
that error code. You can then use printf or MessageBox() to
narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-10 19:59:52 UTC
Permalink
Hi Dinesh,

Thank you very much for your kind help!

The problem was in the new check which is required for using USB Audio 1.0
DAC output device in Exclusive mode. I have made correction and committed
changes, would you please check if it works ok for you now.

Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for the
fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to IAudioClient_Initialize().
The return code is 0x88890020 which corresponds to AUDCLNT_E_INVALID_DEVICE_PERIOD.
Based on the input arguments to IAudioClient_Initialize, the periodicity is
being passed in as 0 because I am operating device in exclusive mode.
Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to force
PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will code
execution reach this breakpoint? If yes, please check contents of outWavex
and say what values for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample
are. If you check logic of MakeWaveFormatFromParams(outWavex, &params,
sampleRate, TRUE) it will force packed sample format usage, e.g. requested
24-bits will not be put into 32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the WASAPI
code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check
how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code
to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16
for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in
its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT)
.
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set
the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is
this value that is being used in the call to IAudioClient_
IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s) is(/are)
returning
that error code. You can then use printf or MessageBox() to
narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-10 20:58:48 UTC
Permalink
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have tested
with other devices to verify that there are no regressions. Thanks very
much for looking into this. I will keep you posted.

Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB Audio 1.0
DAC output device in Exclusive mode. I have made correction and committed
changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to force
PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will code
execution reach this breakpoint? If yes, please check contents of outWavex
and say what values
for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample are. If you
check logic of MakeWaveFormatFromParams(outWavex, &params, sampleRate,
TRUE) it will force packed sample format usage, e.g. requested 24-bits will
not be put into 32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check
how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code
to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16
for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in
its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom of
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to set
the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it is
this value that is being used in the call to IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s) is(/are)
returning
that error code. You can then use printf or MessageBox() to
narrow down
which path is being taken. Eventually you want to determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-11 14:19:21 UTC
Permalink
Hi Dmitry,
I am currently in the process of testing with other devices to ensure that
there are no regressions. If all is OK, I had a question on updating the
portaudio library at my end.

It has been nearly 3 years since the last stable release came out. Is the
latest code in the development branch stable for the entire library that I
can just pull from the tip? OR do you recommend that I just pull in the
WASAPI specific changes since the Oct 2016 stable release? OR are there
plans to have a stable release made available soon that I can just wait?

Regards
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have tested
with other devices to verify that there are no regressions. Thanks very
much for looking into this. I will keep you posted.
Regards,
Dinesh
On Mon, Sep 10, 2018 at 4:00 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB Audio
1.0 DAC output device in Exclusive mode. I have made correction and
committed changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to force
PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will code
execution reach this breakpoint? If yes, please check contents of outWavex
and say what values
for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample are. If you
check logic of MakeWaveFormatFromParams(outWavex, &params, sampleRate,
TRUE) it will force packed sample format usage, e.g. requested 24-bits will
not be put into 32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check
how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that code
to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16
for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be in
its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec * old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary
adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this. Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to
set the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it
is this value that is being used in the call to
IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Dinesh Iyer
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this
further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s) is(/are)
returning
that error code. You can then use printf or MessageBox() to
narrow down
which path is being taken. Eventually you want to determine
where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-13 08:29:30 UTC
Permalink
Hi Dinesh,

I would advise to use the latest code from GIT (master). Has no problems
for me (WASAPI only) for a long time already but of course you have to
thoroughly test it according your app's behavior and functionality.

Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am currently in the process of testing with other devices to ensure that
there are no regressions. If all is OK, I had a question on updating the
portaudio library at my end.
It has been nearly 3 years since the last stable release came out. Is the
latest code in the development branch stable for the entire library that I
can just pull from the tip? OR do you recommend that I just pull in the
WASAPI specific changes since the Oct 2016 stable release? OR are there
plans to have a stable release made available soon that I can just wait?
Regards
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have
tested with other devices to verify that there are no regressions. Thanks
very much for looking into this. I will keep you posted.
Regards,
Dinesh
On Mon, Sep 10, 2018 at 4:00 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB Audio
1.0 DAC output device in Exclusive mode. I have made correction and
committed changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to
force PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will code
execution reach this breakpoint? If yes, please check contents of outWavex
and say what values for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample
are. If you check logic of MakeWaveFormatFromParams(outWavex,
&params, sampleRate, TRUE) it will force packed sample format usage, e.g.
requested 24-bits will not be put into 32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and check
how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that
code to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16
for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be
in its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom
old->nBlockAlign = old->nChannels * (old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec *
old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary
adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit continers
(ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
ср, 5 сеМт. 2018 г. в 15:14, Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this.
Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT)
.
I verified that the PaStreamParameters contain the supported
values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to
set the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it
is this value that is being used in the call to IAudioClient_
IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Dinesh Iyer
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this
further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s)
is(/are) returning
that error code. You can then use printf or MessageBox() to
narrow down
which path is being taken. Eventually you want to determine
where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-09-21 21:21:31 UTC
Permalink
Hi Dmitry,
I just noticed a possible regression after incorporating your changes.
Before these changes, when I try to record 1 channel audio from any
microphone that has a default shared mode format listed as 2 channels, I
was able to. However, after these changes, it errors out. The call to
OpenStream/StartStream succeed and return a status code of 0. However, the
portaudio callback is not fired at all.

The question I have is whether the earlier behaviour is correct OR is the
new behaviour correct.

Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
I would advise to use the latest code from GIT (master). Has no problems
for me (WASAPI only) for a long time already but of course you have to
thoroughly test it according your app's behavior and functionality.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am currently in the process of testing with other devices to ensure
that there are no regressions. If all is OK, I had a question on updating
the portaudio library at my end.
It has been nearly 3 years since the last stable release came out. Is the
latest code in the development branch stable for the entire library that I
can just pull from the tip? OR do you recommend that I just pull in the
WASAPI specific changes since the Oct 2016 stable release? OR are there
plans to have a stable release made available soon that I can just wait?
Regards
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have
tested with other devices to verify that there are no regressions. Thanks
very much for looking into this. I will keep you posted.
Regards,
Dinesh
On Mon, Sep 10, 2018 at 4:00 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB Audio
1.0 DAC output device in Exclusive mode. I have made correction and
committed changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to
force PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will
code execution reach this breakpoint? If yes, please check contents
of outWavex and say what values
for wBitsPerSample, wFormatTag, Samples.wValidBitsPerSample are. If you
check logic of MakeWaveFormatFromParams(outWavex, &params, sampleRate,
TRUE) it will force packed sample format usage, e.g. requested 24-bits will
not be put into 32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and
check how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
On Thu, Sep 6, 2018 at 9:34 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that
code to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16
for WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be
in its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom
old->nBlockAlign = old->nChannels *
(old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec *
old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary
adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit
continers (ints) as wBitsPerSample and wValidBitsPerSample specify real
data resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24)
|| (bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
ср, 5 сеМт. 2018 г. в 15:14, Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this.
Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer <
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported
in this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the
supported values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to
set the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it
is this value that is being used in the call to
IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32
bit containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina <
Post by Dinesh Iyer
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this
further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s)
is(/are) returning
that error code. You can then use printf or MessageBox()
to narrow down
which path is being taken. Eventually you want to
determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-09-23 17:48:40 UTC
Permalink
Hi Dinesh,

Thank you for noticing it.

There was an unlucky typo on the line 5271 (if (stream->out.monoBuffer
== NULL)) should be (if (stream->in.monoBuffer == NULL)). Fixed!

Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I just noticed a possible regression after incorporating your changes.
Before these changes, when I try to record 1 channel audio from any
microphone that has a default shared mode format listed as 2 channels, I was
able to. However, after these changes, it errors out. The call to
OpenStream/StartStream succeed and return a status code of 0. However, the
portaudio callback is not fired at all.
The question I have is whether the earlier behaviour is correct OR is the
new behaviour correct.
Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
I would advise to use the latest code from GIT (master). Has no problems
for me (WASAPI only) for a long time already but of course you have to
thoroughly test it according your app's behavior and functionality.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am currently in the process of testing with other devices to ensure
that there are no regressions. If all is OK, I had a question on updating
the portaudio library at my end.
It has been nearly 3 years since the last stable release came out. Is the
latest code in the development branch stable for the entire library that I
can just pull from the tip? OR do you recommend that I just pull in the
WASAPI specific changes since the Oct 2016 stable release? OR are there
plans to have a stable release made available soon that I can just wait?
Regards
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have
tested with other devices to verify that there are no regressions. Thanks
very much for looking into this. I will keep you posted.
Regards,
Dinesh
On Mon, Sep 10, 2018 at 4:00 PM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB Audio
1.0 DAC output device in Exclusive mode. I have made correction and
committed changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to
force PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will
code execution reach this breakpoint? If yes, please check contents of
outWavex and say what values for wBitsPerSample, wFormatTag,
Samples.wValidBitsPerSample are. If you check logic of
MakeWaveFormatFromParams(outWavex, &params, sampleRate, TRUE) it will force
packed sample format usage, e.g. requested 24-bits will not be put into
32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and
check how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
On Thu, Sep 6, 2018 at 9:34 AM Dinesh Iyer
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that
code to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16 for
WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be
in its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom
old->nBlockAlign = old->nChannels *
(old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec *
old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary
adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit
continers (ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24) ||
(bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
ср, 5 сент. 2018 г. в 15:14, Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this.
Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in
this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the
supported values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to
set the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it
is this value that is being used in the call to
IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32
bit containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this
further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s)
is(/are) returning
that error code. You can then use printf or MessageBox()
to narrow down
which path is being taken. Eventually you want to
determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dinesh Iyer
2018-10-03 10:17:05 UTC
Permalink
Hi Dmitry,
Thanks for the fix. I was able to try it and was able to record 1-channel
audio from a stereo device.

However, I noticed that for certain soundcards (Steinberg UR-22, UR-44),
which operate at 24-bits per sample, recording 1 channel audio sporadically
crashes my application (no stack trace). I tried doing this with a Realtek
Microphone which operates at 16-bits per sample and it works fine.

Any ideas?

Dinesh
Post by Ross Bencina
Hi Dinesh,
Thank you for noticing it.
There was an unlucky typo on the line 5271 (if (stream->out.monoBuffer
== NULL)) should be (if (stream->in.monoBuffer == NULL)). Fixed!
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I just noticed a possible regression after incorporating your changes.
Before these changes, when I try to record 1 channel audio from any
microphone that has a default shared mode format listed as 2 channels, I
was
Post by Dinesh Iyer
able to. However, after these changes, it errors out. The call to
OpenStream/StartStream succeed and return a status code of 0. However,
the
Post by Dinesh Iyer
portaudio callback is not fired at all.
The question I have is whether the earlier behaviour is correct OR is the
new behaviour correct.
Regards,
Dinesh
On Thu, Sep 13, 2018 at 4:29 AM Dmitry Kostjuchenko <
Post by Ross Bencina
Hi Dinesh,
I would advise to use the latest code from GIT (master). Has no problems
for me (WASAPI only) for a long time already but of course you have to
thoroughly test it according your app's behavior and functionality.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am currently in the process of testing with other devices to ensure
that there are no regressions. If all is OK, I had a question on
updating
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
the portaudio library at my end.
It has been nearly 3 years since the last stable release came out. Is
the
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
latest code in the development branch stable for the entire library
that I
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
can just pull from the tip? OR do you recommend that I just pull in the
WASAPI specific changes since the Oct 2016 stable release? OR are there
plans to have a stable release made available soon that I can just
wait?
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Regards
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have
tested with other devices to verify that there are no regressions.
Thanks
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
very much for looking into this. I will keep you posted.
Regards,
Dinesh
On Mon, Sep 10, 2018 at 4:00 PM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB
Audio
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
1.0 DAC output device in Exclusive mode. I have made correction and
committed changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values
for
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which
corresponds
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0
because I
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to
force PA's WASAPI implementation not to look for alternative close
format.
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Would you please set debugger's breakpoint to the line 2485. Will
code execution reach this breakpoint? If yes, please check
contents of
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
outWavex and say what values for wBitsPerSample, wFormatTag,
Samples.wValidBitsPerSample are. If you check logic of
MakeWaveFormatFromParams(outWavex, &params, sampleRate, TRUE) it
will force
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
packed sample format usage, e.g. requested 24-bits will not be put
into
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
On Fri, Sep 7, 2018 at 9:24 AM Dinesh Iyer <
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and
check how it works now. I have committed necessary changes to
WASAPI's
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
implementation with the improvement of the the selection of the
format for
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Exclusive mode. Would you please test new implementation. In my
tests it
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
works fine and I hope will do so in you case too. Now PA will
also test
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
packed sample formats, e.g. it will also cover your successful
result when
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
On Thu, Sep 6, 2018 at 9:34 AM Dinesh Iyer
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that
code to the bottom would change anything. Reason I ask is
that there is no
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF
condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or
16 for
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file
be
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
in its original state;
2) in MakeWaveFormatFromParams() move these lines to the
bottom
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
old->nBlockAlign = old->nChannels *
(old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec *
old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept
erroneous
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were
changed to 32.
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Will it work?
Will be waiting for the results of your test to make
necessary
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit
continers (ints) as wBitsPerSample and wValidBitsPerSample
specify real data
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24) ||
(bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
ср, 5 сеМт. 2018 г. в 15:14, Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this.
Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32
bit
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to
IAudioClient_IsFormatSupported in
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Dinesh Iyer
this function returns 0x88890008
(AUDCLNT_E_UNSUPPORTED_FORMAT).
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Dinesh Iyer
I verified that the PaStreamParameters contain the
supported values for SR, bits-per-sample and channel
count.
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Dinesh Iyer
I noticed the MakeWaveFormatFromParams function appears
to
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Dinesh Iyer
set the BitsPerSample in the WAVEFORMATEXTENSIBLE struct
to 32-bits. And it
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Dinesh Iyer
is this value that is being used in the call to
IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32
bit containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this
further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the
return
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Dinesh Iyer
Post by Ross Bencina
error code
you're getting and try to triangulate which site(s)
is(/are) returning
that error code. You can then use printf or MessageBox()
to narrow down
which path is being taken. Eventually you want to
determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Dmitry Kostjuchenko
2018-10-21 10:29:15 UTC
Permalink
Hi Dinesh,

Sorry for the delayed reply!
which operate at 24-bits per sample, recording 1 channel audio sporadically crashes my application (no stack trace)
I analyzed possible problem from WASAPI's side and found out that
there could be possibility that MonoToStereo converter could write
beyond the destination memory buffer if its sample format is packed
24-bit integer format (could happen only in case of Exclusive mode
when device supports only packed 24-bit format). Our implementation
expected 24-bit format be packed in 32-bit integer containers.

The corresponding change was made and committed, so you could check.
Your crashes could be caused by this bug but only in case device
insists on packed 24-bit samples (6 bytes per sample) in Exclusive
mode. In all other cases this bug was noop.

Best regards,
Dmitry.

Best regards,
Dmitry.
Hi Dmitry,
Thanks for the fix. I was able to try it and was able to record 1-channel audio from a stereo device.
However, I noticed that for certain soundcards (Steinberg UR-22, UR-44), which operate at 24-bits per sample, recording 1 channel audio sporadically crashes my application (no stack trace). I tried doing this with a Realtek Microphone which operates at 16-bits per sample and it works fine.
Any ideas?
Dinesh
Post by Ross Bencina
Hi Dinesh,
Thank you for noticing it.
There was an unlucky typo on the line 5271 (if (stream->out.monoBuffer
== NULL)) should be (if (stream->in.monoBuffer == NULL)). Fixed!
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I just noticed a possible regression after incorporating your changes.
Before these changes, when I try to record 1 channel audio from any
microphone that has a default shared mode format listed as 2 channels, I was
able to. However, after these changes, it errors out. The call to
OpenStream/StartStream succeed and return a status code of 0. However, the
portaudio callback is not fired at all.
The question I have is whether the earlier behaviour is correct OR is the
new behaviour correct.
Regards,
Dinesh
Post by Ross Bencina
Hi Dinesh,
I would advise to use the latest code from GIT (master). Has no problems
for me (WASAPI only) for a long time already but of course you have to
thoroughly test it according your app's behavior and functionality.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am currently in the process of testing with other devices to ensure
that there are no regressions. If all is OK, I had a question on updating
the portaudio library at my end.
It has been nearly 3 years since the last stable release came out. Is the
latest code in the development branch stable for the entire library that I
can just pull from the tip? OR do you recommend that I just pull in the
WASAPI specific changes since the Oct 2016 stable release? OR are there
plans to have a stable release made available soon that I can just wait?
Regards
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
The latest changes appear to have fixed the issue. I still not have
tested with other devices to verify that there are no regressions. Thanks
very much for looking into this. I will keep you posted.
Regards,
Dinesh
On Mon, Sep 10, 2018 at 4:00 PM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Thank you very much for your kind help!
The problem was in the new check which is required for using USB Audio
1.0 DAC output device in Exclusive mode. I have made correction and
committed changes, would you please check if it works ok for you now.
Best regards,
Dmitry.
Post by Dinesh Iyer
Dmitry,
I verified the outWavex on line 2485 and confirmed that the values for
the fields wBitsPerSample = 24, wFormatTag = 65534 (0xFFFE),
Sample.wValidBitsPerSample = 24.
The failure happens on line 3016 in the call to
IAudioClient_Initialize(). The return code is 0x88890020 which corresponds
to AUDCLNT_E_INVALID_DEVICE_PERIOD. Based on the input arguments to
IAudioClient_Initialize, the periodicity is being passed in as 0 because I
am operating device in exclusive mode.
Regards,
Dinesh
On Sat, Sep 8, 2018 at 5:26 AM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
paWinWasapiExplicitSampleFormat is not required but it allows to
force PA's WASAPI implementation not to look for alternative close format.
Would you please set debugger's breakpoint to the line 2485. Will
code execution reach this breakpoint? If yes, please check contents of
outWavex and say what values for wBitsPerSample, wFormatTag,
Samples.wValidBitsPerSample are. If you check logic of
MakeWaveFormatFromParams(outWavex, &params, sampleRate, TRUE) it will force
packed sample format usage, e.g. requested 24-bits will not be put into
32-bit containers.
Basically your input is welcome because you have such specific device.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
I am getting the same error after bringing in your changes to the
WASAPI code. The error happens with and without setting the
paWinWasapiExplicitSampleFormat flag.
Dinesh
Post by Dinesh Iyer
Hi Dmitry,
Do I have to set the flag paWinWasapiExplicitSampleFormat in the
PaWasapiStreamInfo?
Dinesh
On Thu, Sep 6, 2018 at 2:03 PM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Thank you for testing!
Would you please update PA's GIT to the latest, recompile and
check how it works now. I have committed necessary changes to WASAPI's
implementation with the improvement of the the selection of the format for
Exclusive mode. Would you please test new implementation. In my tests it
works fine and I hope will do so in you case too. Now PA will also test
packed sample formats, e.g. it will also cover your successful result when
you changed wBitsPerSample to 24.
Best regards,
Dmitry.
Post by Dinesh Iyer
Hi Dmitry,
The change you suggested did not fix the issue.
Dinesh
On Thu, Sep 6, 2018 at 9:34 AM Dinesh Iyer
Post by Dinesh Iyer
Hi Dmitry,
I am running the changes now but I am curious how moving that
code to the bottom would change anything. Reason I ask is that there is no
further changes being made to the fields of "old" after
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
}
and those computations were made immediately after this IF
condition.
Regards,
Dinesh
On Thu, Sep 6, 2018 at 8:06 AM Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
Please disregard my previous e-mail. Accroding MSDN for
WAVEFORMATEX structure wBitsPerSample must be strictly 8 or 16 for
WAVE_FORMAT_PCM.
1) undo all your changes, e.g. let the pa_win_wasapi.c file be
in its original state;
2) in MakeWaveFormatFromParams() move these lines to the bottom
old->nBlockAlign = old->nChannels *
(old->wBitsPerSample / 8);
old->nAvgBytesPerSec = old->nSamplesPerSec *
old->nBlockAlign;
E.g. right above 'return paNoError'.
Most probably the driver in your case does not accept erroneous
nBlockAlign and nAvgBytesPerSec because wBitsPerSample were changed to 32.
Will it work?
Will be waiting for the results of your test to make necessary
adjustments.
Best regards,
Dmitry.
2018-09-06 11:28 GMT+03:00 Dmitry Kostjuchenko
Post by Ross Bencina
Hi Dinesh,
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32 bit
containers (ints)
was valid for all devices until your case.
If valid data is >=20 normally Windows expects 32-bit
continers (ints) as wBitsPerSample and wValidBitsPerSample specify real data
resolution.
if ((params->channelCount <= 2) && ((bitsPerSample == 16) ||
(bitsPerSample == 8)))
if ((params->channelCount <= 2) && ((bitsPerSample == 24) ||
(bitsPerSample == 16) || (bitsPerSample == 8)))
Will it work either?
Best regards,
Dmitry.
ср, 5 сент. 2018 г. в 15:14, Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
I was wondering if you had a chance to look into this.
Appreciate it!
Dinesh
On Tue, Sep 4, 2018 at 10:04 AM Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 24; // 20 or 24 bits must go in 32 bit
containers (ints)
}
And the playback and recording worked as expected.
Regards,
Dinesh
On Thu, Aug 30, 2018 at 4:08 PM Dinesh Iyer
Post by Dinesh Iyer
Hi Ross,
I actually setup debugs and did more digging.
The cause of the issue appears to be the GetClosestFormat
function in pa_win_wasapi.c. Every call to IAudioClient_IsFormatSupported in
this function returns 0x88890008 (AUDCLNT_E_UNSUPPORTED_FORMAT).
I verified that the PaStreamParameters contain the
supported values for SR, bits-per-sample and channel count.
I noticed the MakeWaveFormatFromParams function appears to
set the BitsPerSample in the WAVEFORMATEXTENSIBLE struct to 32-bits. And it
is this value that is being used in the call to
IAudioClient_IsFormatSupported.
if ((old->wBitsPerSample = bitsPerSample) > 16)
{
old->wBitsPerSample = 32; // 20 or 24 bits must go in 32
bit containers (ints)
}
Is this valid?
Hope this investigation helps.
Regards,
Dinesh
On Wed, Aug 29, 2018 at 6:28 PM Ross Bencina
Post by Ross Bencina
Post by Dinesh Iyer
Looking for suggestions on how to troubleshoot this
further.
Hi Dinesh,
The obvious suggestion is to step into the PortAudio
OpenStream call
using a debugger and see where it is failing.
Alternatively you can grep the source code for the return
error code
you're getting and try to triangulate which site(s)
is(/are) returning
that error code. You can then use printf or MessageBox()
to narrow down
which path is being taken. Eventually you want to
determine where
PortAudio is giving up, and why.
Ross.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
Loading...