[Portaudio] "Real" 24 bits with portaudio

Discussion:

Louis-Paul CORDIER

2018-07-09 17:27:26 UTC

Hi everybody,

Simple question here. I am developing an app that needs to capture audio
from professional audio card. To check if a card is capable of opening a
stream in 24bits, I am using the Pa_IsFormatSupported() function, with
"sampleFormat " of structure PaStreamParameters set to paInt24.

Unfortunately under Windows at least, looking at the input buffer, zero
are added to each sample, meaning that it is not a true 24 bits, but
rather a 16bits internally converted by portaudio.

After a little dig into portaudio sample, it seems that
PaUtil_SelectClosestAvailableFormat( WaveToPaFormat(&stream->out.wavex),
outputSampleFormat );
is used to find the best format regarding the user willing. This
behaviour does not suit to my app as the user needs to be sure that
everything will be recorded in TRUE 24bits.

Would it be possible to add an extra flag or function to make portaudio
fails if the requested format by the user is NOT available internally?

Thank you for your help.

LPC

Evan Balster

2018-07-09 22:30:44 UTC

Permalink

Hello, Louis â

Try opening a PaInt32 or PaFloat32 stream. That should, with any luck,
give you access to the highest precision available. Modern OS sound
systems, Windows included, tend to provide either int16 or float32 formats
from their APIs â and float32 guarantees a minimum of 24 bits of
fixed-point precision.

â Evan Balster
creator of imitone <http://imitone.com>

On Mon, Jul 9, 2018 at 12:27 PM, Louis-Paul CORDIER <

Post by Louis-Paul CORDIER
Hi everybody,
Simple question here. I am developing an app that needs to capture audio
from professional audio card. To check if a card is capable of opening a
stream in 24bits, I am using the Pa_IsFormatSupported() function, with
"sampleFormat " of structure PaStreamParameters set to paInt24.
Unfortunately under Windows at least, looking at the input buffer, zero
are added to each sample, meaning that it is not a true 24 bits, but rather
a 16bits internally converted by portaudio.
After a little dig into portaudio sample, it seems that
PaUtil_SelectClosestAvailableFormat( WaveToPaFormat(&stream->out.wavex),
outputSampleFormat );
is used to find the best format regarding the user willing. This behaviour
does not suit to my app as the user needs to be sure that everything will
be recorded in TRUE 24bits.
Would it be possible to add an extra flag or function to make portaudio
fails if the requested format by the user is NOT available internally?
Thank you for your help.
LPC
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Chris

2018-07-09 22:31:46 UTC

Permalink

It's been a few years since I last dealt with this, but when I was doing QC for Dmitry as he was developing the WASAPI interface for PortAudio, this was tested. The program "Audacity" uses PortAudio and Dmitry's WASAPI code. There are other programs that haven't had much success using WASAPI but PortAudio's implementation, used in Audacity, works well.

You first have to get PortAudio to use WASAPI in the "Exclusive" mode. My testing revealed that 24-bit WASAPI is bit perfect, i.e. you get the same bit pattern out of it that you put into it, unlike previous Windows audio API's. I have a walking-one pattern which I was using to test WASAPI and it passed my testing. As I say, it's been a couple of years since I last dealt with this.

"Would it be possible to add an extra flag or function to make portaudio fails if the requested format by the user is NOT available internally?"

This isn't necessary. Just use Pa_IsFormatSupported(). I suspect that you are not explicitly and correctly putting your program into WASAPI mode and PortAudio is defaulting to a bit depth of 16, which explains why your 24-bit samples are being padded with one byte of all zeroes

I wrote an audio recording application which uses PortAudio's WASAPI mode but it is written in PureBasic. You are welcome to the code provided you do not share it with anyone else, but you will need PureBasic. I think there is a free version of PureBasic available which might work, but PureBasic is not expensive and is worth it as far as I'm concerned.

My recording program does work with Windows 10, but I need to recompile the PortAudio part as Dmitry has recently made some changes to the WASAPI interface.

https://www.purebasic.com/

-----Original Message-----
From: Louis-Paul CORDIER <***@dynamixyz.com>
To: portaudio <***@lists.columbia.edu>
Sent: Mon, Jul 9, 2018 10:28 am
Subject: [Portaudio] "Real" 24 bits with portaudio

Hi everybody,

Simple question here. I am developing an app that needs to capture audio
from professional audio card. To check if a card is capable of opening a
stream in 24bits, I am using the Pa_IsFormatSupported() function, with
"sampleFormat " of structure PaStreamParameters set to paInt24.

Unfortunately under Windows at least, looking at the input buffer, zero
are added to each sample, meaning that it is not a true 24 bits, but
rather a 16bits internally converted by portaudio.

After a little dig into portaudio sample, it seems that
PaUtil_SelectClosestAvailableFormat( WaveToPaFormat(&stream->out.wavex),
outputSampleFormat );
is used to find the best format regarding the user willing. This
behaviour does not suit to my app as the user needs to be sure that
everything will be recorded in TRUE 24bits.

Would it be possible to add an extra flag or function to make portaudio
fails if the requested format by the user is NOT available internally?

Thank you for your help.

LPC

Chris

2018-07-09 22:41:43 UTC

Permalink

"Try opening a PaInt32 or PaFloat32 stream. That should, with any luck, give you access to the highest precision available. Modern OS sound systems, Windows included, tend to provide either int16 or float32 formats from their APIs — and float32 guarantees a minimum of 24 bits of fixed-point precision."

I doubt this will work. I don't know of an A-to-D converter in general use that puts out floating-point samples. There may be some drivers that convert from 24 bits to float but it's not going to be a bit-perfect replica of what the hardware A-to-D converter is putting out.

To do what the O.P. wants in Windows you need to be in the WASAPI mode. Last time I checked, the other Windows audio API's such as DirectSound top out at 16 bits.

-----Original Message-----
From: Evan Balster <***@imitone.com>
To: portaudio list <***@lists.columbia.edu>
Sent: Mon, Jul 9, 2018 3:31 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

Hello, Louis —

Try opening a PaInt32 or PaFloat32 stream. That should, with any luck, give you access to the highest precision available. Modern OS sound systems, Windows included, tend to provide either int16 or float32 formats from their APIs — and float32 guarantees a minimum of 24 bits of fixed-point precision.

– Evan Balster
creator of imitone

On Mon, Jul 9, 2018 at 12:27 PM, Louis-Paul CORDIER <***@dynamixyz.com> wrote:
Hi everybody,

Simple question here. I am developing an app that needs to capture audio from professional audio card. To check if a card is capable of opening a stream in 24bits, I am using the Pa_IsFormatSupported() function, with "sampleFormat " of structure PaStreamParameters set to paInt24.

Unfortunately under Windows at least, looking at the input buffer, zero are added to each sample, meaning that it is not a true 24 bits, but rather a 16bits internally converted by portaudio.

After a little dig into portaudio sample, it seems that
PaUtil_SelectClosestAvailableFormat( WaveToPaFormat(&stream->out.wavex), outputSampleFormat );
is used to find the best format regarding the user willing. This behaviour does not suit to my app as the user needs to be sure that everything will be recorded in TRUE 24bits.

Would it be possible to add an extra flag or function to make portaudio fails if the requested format by the user is NOT available internally?

Thank you for your help.

LPC
_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

Ross Bencina

2018-07-10 00:48:35 UTC

Permalink

Hello Louis,

From the code that you're quoting, it sounds like you're using the
PA/WMME back-end. I don't think 24-bit I/O is implemented for PA/WMME.

You need to select the ASIO or perhaps WASAPI back-ends to get 24-bit I/O.

In any case, PortAudio provides no way to tell you whether the device
itself supports 24-bit (few native APIs do provide this). In general
PortAudio will up-convert if it can only get 16-bit from the device.
IsFormatSupported is more like
PaWillNotFailWithAFormatErrorIfYouTryToOpenTheStreamWithThatFormat. In
the case of sample rate and channel count, the system needs to support
those values, in the case of sample format, PA does the formtat
conversion itself.

Your only option is to use paInt32 and check whether the low bits are zero.

Thanks,

Ross.

Post by Louis-Paul CORDIER
Hi everybody,
Simple question here. I am developing an app that needs to capture audio
from professional audio card. To check if a card is capable of opening a
stream in 24bits, I am using the Pa_IsFormatSupported() function, with
"sampleFormat " of structure PaStreamParameters set to paInt24.
Unfortunately under Windows at least, looking at the input buffer, zero
are added to each sample, meaning that it is not a true 24 bits, but
rather a 16bits internally converted by portaudio.
After a little dig into portaudio sample, it seems that
PaUtil_SelectClosestAvailableFormat( WaveToPaFormat(&stream->out.wavex),
outputSampleFormat );
is used to find the best format regarding the user willing. This
behaviour does not suit to my app as the user needs to be sure that
everything will be recorded in TRUE 24bits.
Would it be possible to add an extra flag or function to make portaudio
fails if the requested format by the user is NOT available internally?
Thank you for your help.
LPC
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Ross Bencina

2018-07-10 01:22:26 UTC

Permalink

Sorry, Louis-Paul, my apologies for contracting your name.

Post by Ross Bencina
IsFormatSupported is more like
PaWillNotFailWithAFormatErrorIfYouTryToOpenTheStreamWithThatFormat. In
the case of sample rate and channel count, the system needs to support
those values, in the case of sample format, PA does the formtat
conversion itself.

To be clear, when I say "the system needs to support" what I mean is
that the native API stack needs to support the requested sample rate and
channel count. There is nothing stopping the OS from performing sample
rate conversion or allowing to open more channels than exist.

Some native APIs will only support hardware-supplied channel count and
sample rates, others will convert. Most will support opening less
channels than max channels.

Ross.

Chris

2018-07-10 01:29:36 UTC

Permalink

-----Original Message-----
From: Ross Bencina <rossb-***@audiomulch.com>
To: portaudio list <***@lists.columbia.edu>; Louis-Paul CORDIER <***@dynamixyz.com>
Sent: Mon, Jul 9, 2018 5:49 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

"Your only option is to use paInt32 and check whether the low bits are zero."

If he fetches 32-bit samples from a 24-bit device, I would think his samples will be padded with 8 zeroes.

Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry and I put a lot of hours into making WASAPI work on PortAudio so why not use it? I assume the O.P. is not running Windows XP or prior.

Axel Holzinger

2018-07-10 06:47:11 UTC

Permalink

I can confirm that via WASAPI in exclusive mode on Windows (tested only with
Windows 10) bit transparent operation with 24 bits per sample with PortAudio
is working well.

Anyhow a function to really get the device capabilities would be very
useful. This was also missing in the native (Windows) APIs, which in the
past made me write Windows code that really tries to open the device in all
thinkable formats to really find out, if it's supporting some format. So it
might be hard to add such a function in PortAudio.

Just my 0.02$
Axel

Post by Chris
-----Original Message-----
Sent: Tuesday, July 10, 2018 3:30 AM
Subject: Re: [Portaudio] "Real" 24 bits with portaudio
-----Original Message-----
Sent: Mon, Jul 9, 2018 5:49 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio
"Your only option is to use paInt32 and check whether the low bits are zero."
If he fetches 32-bit samples from a 24-bit device, I would think his

samples will

Post by Chris
be padded with 8 zeroes.
Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry

and I

Post by Chris
put a lot of hours into making WASAPI work on PortAudio so why not use it?

Post by Chris
assume the O.P. is not running Windows XP or prior.
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Louis-Paul CORDIER

2018-07-10 08:23:29 UTC

Permalink

Hi everybody,

Thank you all for your quick replies. Ross no worries, my first-name is
being crushed since my childhood ;)

1. Opening the stream as PaInt32 is not acceptable for my use case, as
I need to know at opening if it's 24bits or not.
2. I will give a try to Wasapi exclusive mode, but still portaudio can
silently do a conversion to my understanding of the code.
3. I digged into the source code this morning and to my understanding
of the Windows SDK doc, it would be possible to determine if the
audio format is supported or not by the device. (from
https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient-isformatsupported)

"For shared mode, if the audio engine supports the caller-specified
format, *IsFormatSupported* sets **ppClosestMatch* to *NULL* and
returns S_OK. If the audio engine does not support the
caller-specified format but does support a similar format, the
method retrieves the similar format through the /ppClosestMatch/
parameter and returns S_FALSE. If the audio engine does not support
the caller-specified format or any similar format, the method sets
/*ppClosestMatch/ to *NULL* and returns AUDCLNT_E_UNSUPPORTED_FORMAT."

After reading into the PA wasapi code, it seems that you developed
an heuristic for selecting the right audio format. So even in shared
mode, we could add a flag that will make Pa_IsFormatSupported to
fail if the underlying device can't provide the exact format
requested by the user instead of executing the heuristic.
4. Side note 1: I've found some function in pa_utils very useful, even
for the end user. it would be great to export functions into this
header while installing portaudio with CMake?
5. Side note 2: I jumped into Portaudio CMakeLists.txt. It does not
look like a "modern cmake". Would it be accepted by the community if
I update the CMakeLists? Maybe these 2 last questions deserve
another thread in the mailing list though...

BR,

Louis-Paul

Post by Axel Holzinger
I can confirm that via WASAPI in exclusive mode on Windows (tested only with
Windows 10) bit transparent operation with 24 bits per sample with PortAudio
is working well.
Anyhow a function to really get the device capabilities would be very
useful. This was also missing in the native (Windows) APIs, which in the
past made me write Windows code that really tries to open the device in all
thinkable formats to really find out, if it's supporting some format. So it
might be hard to add such a function in PortAudio.
Just my 0.02$
Axel

zero."

Post by Chris
If he fetches 32-bit samples from a 24-bit device, I would think his

samples will

Post by Chris
be padded with 8 zeroes.
Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry

and I

Post by Chris
put a lot of hours into making WASAPI work on PortAudio so why not use it?

Axel Holzinger

2018-07-10 08:36:20 UTC

Permalink

Louis-Paul,

WASAPI shared mode will hardly be bit transparent as the Windows audio service will process the samples. Only if your process is the only one using the audio device AND the configured default format (in Windows audio control panel applet) is exactly the same format your application is requesting.

Just another 0.02$

Axel

From: portaudio-***@lists.columbia.edu [mailto:portaudio-***@lists.columbia.edu] On Behalf Of Louis-Paul CORDIER
Sent: Tuesday, July 10, 2018 10:23 AM
To: 'portaudio list' <***@lists.columbia.edu>
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

Hi everybody,

Thank you all for your quick replies. Ross no worries, my first-name is being crushed since my childhood ;)

1. Opening the stream as PaInt32 is not acceptable for my use case, as I need to know at opening if it's 24bits or not.
2. I will give a try to Wasapi exclusive mode, but still portaudio can silently do a conversion to my understanding of the code.
3. I digged into the source code this morning and to my understanding of the Windows SDK doc, it would be possible to determine if the audio format is supported or not by the device. (from https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient-isformatsupported)

"For shared mode, if the audio engine supports the caller-specified format, IsFormatSupported sets *ppClosestMatch to NULL and returns S_OK. If the audio engine does not support the caller-specified format but does support a similar format, the method retrieves the similar format through the ppClosestMatch parameter and returns S_FALSE. If the audio engine does not support the caller-specified format or any similar format, the method sets *ppClosestMatch to NULL and returns AUDCLNT_E_UNSUPPORTED_FORMAT."

After reading into the PA wasapi code, it seems that you developed an heuristic for selecting the right audio format. So even in shared mode, we could add a flag that will make Pa_IsFormatSupported to fail if the underlying device can't provide the exact format requested by the user instead of executing the heuristic.
4. Side note 1: I've found some function in pa_utils very useful, even for the end user. it would be great to export functions into this header while installing portaudio with CMake?
5. Side note 2: I jumped into Portaudio CMakeLists.txt. It does not look like a "modern cmake". Would it be accepted by the community if I update the CMakeLists? Maybe these 2 last questions deserve another thread in the mailing list though...

BR,

Louis-Paul

Le 10/07/2018 Ã 08:47, Axel Holzinger a Ã©crit :

I can confirm that via WASAPI in exclusive mode on Windows (tested only with
Windows 10) bit transparent operation with 24 bits per sample with PortAudio
is working well.

Anyhow a function to really get the device capabilities would be very
useful. This was also missing in the native (Windows) APIs, which in the
past made me write Windows code that really tries to open the device in all
thinkable formats to really find out, if it's supporting some format. So it
might be hard to add such a function in PortAudio.

Just my 0.02$
Axel

-----Original Message-----
From: portaudio-***@lists.columbia.edu <mailto:portaudio-***@lists.columbia.edu> [mailto:portaudio-
***@lists.columbia.edu <mailto:***@lists.columbia.edu> ] On Behalf Of Chris
Sent: Tuesday, July 10, 2018 3:30 AM
To: ***@lists.columbia.edu <mailto:***@lists.columbia.edu> ; ***@dynamixyz.com <mailto:***@dynamixyz.com>
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

-----Original Message-----
From: Ross Bencina <mailto:rossb-***@audiomulch.com> <rossb-***@audiomulch.com>
To: portaudio list <mailto:***@lists.columbia.edu> <***@lists.columbia.edu>; Louis-Paul CORDIER
<mailto:***@dynamixyz.com> <***@dynamixyz.com>
Sent: Mon, Jul 9, 2018 5:49 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

"Your only option is to use paInt32 and check whether the low bits are

zero."

If he fetches 32-bit samples from a 24-bit device, I would think his

samples will

be padded with 8 zeroes.

Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry

and I

put a lot of hours into making WASAPI work on PortAudio so why not use it?

I

assume the O.P. is not running Windows XP or prior.

Nick Appleton

2018-07-10 09:30:32 UTC

Permalink

Hi Louis-Paul,

I did the last major rework of the CMake support in Portaudio. There are a few things that are missing (I think I stuffed up the INSTALL() usage). If you have proposed changes, feel free to email me directly with your thoughts or just submit a patch and I’ll/we'll have a look over it.

Nick

Post by Louis-Paul CORDIER
Hi everybody,
Thank you all for your quick replies. Ross no worries, my first-name is being crushed since my childhood ;)
• Opening the stream as PaInt32 is not acceptable for my use case, as I need to know at opening if it's 24bits or not.
• I will give a try to Wasapi exclusive mode, but still portaudio can silently do a conversion to my understanding of the code.
• I digged into the source code this morning and to my understanding of the Windows SDK doc, it would be possible to determine if the audio format is supported or not by the device. (from https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient-isformatsupported)
"For shared mode, if the audio engine supports the caller-specified format, IsFormatSupported sets *ppClosestMatch to NULL and returns S_OK. If the audio engine does not support the caller-specified format but does support a similar format, the method retrieves the similar format through the ppClosestMatch parameter and returns S_FALSE. If the audio engine does not support the caller-specified format or any similar format, the method sets *ppClosestMatch to NULL and returns AUDCLNT_E_UNSUPPORTED_FORMAT."
After reading into the PA wasapi code, it seems that you developed an heuristic for selecting the right audio format. So even in shared mode, we could add a flag that will make Pa_IsFormatSupported to fail if the underlying device can't provide the exact format requested by the user instead of executing the heuristic.
• Side note 1: I've found some function in pa_utils very useful, even for the end user. it would be great to export functions into this header while installing portaudio with CMake?
• Side note 2: I jumped into Portaudio CMakeLists.txt. It does not look like a "modern cmake". Would it be accepted by the community if I update the CMakeLists? Maybe these 2 last questions deserve another thread in the mailing list though...
BR,
Louis-Paul

Post by Chris
-----Original Message-----
-
] On Behalf Of Chris
Sent: Tuesday, July 10, 2018 3:30 AM
Subject: Re: [Portaudio] "Real" 24 bits with portaudio
-----Original Message-----
From: Ross Bencina
To: portaudio list
; Louis-Paul CORDIER
Sent: Mon, Jul 9, 2018 5:49 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio
"Your only option is to use paInt32 and check whether the low bits are

zero."

Post by Chris
If he fetches 32-bit samples from a 24-bit device, I would think his

samples will

Post by Chris
be padded with 8 zeroes.
Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry

and I

Post by Chris
put a lot of hours into making WASAPI work on PortAudio so why not use it?

_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Louis-Paul CORDIER

2018-07-10 09:50:13 UTC

Permalink

Hey Nick,

Is the latest CMakeLists.txt on master on this git? It seems that it
still for CMake 2.8 https://app.assembla.com/spaces/portaudio/git/source

*Best Regards/ *

*Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/*

Post by Nick Appleton
Hi Louis-Paul,
I did the last major rework of the CMake support in Portaudio. There are a few things that are missing (I think I stuffed up the INSTALL() usage). If you have proposed changes, feel free to email me directly with your thoughts or just submit a patch and Iâll/we'll have a look over it.
Nick

Post by Louis-Paul CORDIER
Hi everybody,
Thank you all for your quick replies. Ross no worries, my first-name is being crushed since my childhood ;)
â¢ Opening the stream as PaInt32 is not acceptable for my use case, as I need to know at opening if it's 24bits or not.
â¢ I will give a try to Wasapi exclusive mode, but still portaudio can silently do a conversion to my understanding of the code.
â¢ I digged into the source code this morning and to my understanding of the Windows SDK doc, it would be possible to determine if the audio format is supported or not by the device. (from https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient-isformatsupported)
"For shared mode, if the audio engine supports the caller-specified format, IsFormatSupported sets *ppClosestMatch to NULL and returns S_OK. If the audio engine does not support the caller-specified format but does support a similar format, the method retrieves the similar format through the ppClosestMatch parameter and returns S_FALSE. If the audio engine does not support the caller-specified format or any similar format, the method sets *ppClosestMatch to NULL and returns AUDCLNT_E_UNSUPPORTED_FORMAT."
After reading into the PA wasapi code, it seems that you developed an heuristic for selecting the right audio format. So even in shared mode, we could add a flag that will make Pa_IsFormatSupported to fail if the underlying device can't provide the exact format requested by the user instead of executing the heuristic.
â¢ Side note 1: I've found some function in pa_utils very useful, even for the end user. it would be great to export functions into this header while installing portaudio with CMake?
â¢ Side note 2: I jumped into Portaudio CMakeLists.txt. It does not look like a "modern cmake". Would it be accepted by the community if I update the CMakeLists? Maybe these 2 last questions deserve another thread in the mailing list though...
BR,
Louis-Paul

zero."

Post by Chris
If he fetches 32-bit samples from a 24-bit device, I would think his

samples will

Post by Chris
be padded with 8 zeroes.
Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry

and I

Post by Chris
put a lot of hours into making WASAPI work on PortAudio so why not use it?

_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Nick Appleton

2018-07-10 11:07:22 UTC

Permalink

Hi Louis-Paul,

Yes, the most recent CMakeLists.txt is on master.

We are not making use of new CMake features (there was no need) and so the minimum required version is still at 2.8. If there are "modern" features which make the build scripts clearer, then we should use them - but PortAudio is a relatively simple project and I’m keen to not introduce complexity unless it makes things more-readable. By all means, if you have ideas, I’m very happy to discuss them with you - but there are several people relying on PortAudio's CMake support in their own projects now and so it would be good to keep things backwards-compatible.

Ta!

Nick

Post by Louis-Paul CORDIER
Hey Nick,
Is the latest CMakeLists.txt on master on this git? It seems that it still for CMake 2.8 https://app.assembla.com/spaces/portaudio/git/source
Best Regards/
Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/

Post by Louis-Paul CORDIER
Hi everybody,
Thank you all for your quick replies. Ross no worries, my first-name is being crushed since my childhood ;)
• Opening the stream as PaInt32 is not acceptable for my use case, as I need to know at opening if it's 24bits or not.
• I will give a try to Wasapi exclusive mode, but still portaudio can silently do a conversion to my understanding of the code.
• I digged into the source code this morning and to my understanding of the Windows SDK doc, it would be possible to determine if the audio format is supported or not by the device. (from
https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient-isformatsupported
)
"For shared mode, if the audio engine supports the caller-specified format, IsFormatSupported sets *ppClosestMatch to NULL and returns S_OK. If the audio engine does not support the caller-specified format but does support a similar format, the method retrieves the similar format through the ppClosestMatch parameter and returns S_FALSE. If the audio engine does not support the caller-specified format or any similar format, the method sets *ppClosestMatch to NULL and returns AUDCLNT_E_UNSUPPORTED_FORMAT."
After reading into the PA wasapi code, it seems that you developed an heuristic for selecting the right audio format. So even in shared mode, we could add a flag that will make Pa_IsFormatSupported to fail if the underlying device can't provide the exact format requested by the user instead of executing the heuristic.
• Side note 1: I've found some function in pa_utils very useful, even for the end user. it would be great to export functions into this header while installing portaudio with CMake?
• Side note 2: I jumped into Portaudio CMakeLists.txt. It does not look like a "modern cmake". Would it be accepted by the community if I update the CMakeLists? Maybe these 2 last questions deserve another thread in the mailing list though...
BR,
Louis-Paul

zero."

Post by Chris
If he fetches 32-bit samples from a 24-bit device, I would think his

samples will

Post by Chris
be padded with 8 zeroes.
Why not simply use 24-bit WASAPI as I explained in a previous post? Dmitry

and I

Post by Chris
put a lot of hours into making WASAPI work on PortAudio so why not use it?

_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Ross Bencina

2018-07-12 06:52:44 UTC

Permalink

Hi Louis-Paul,

Post by Louis-Paul CORDIER
1. Opening the stream as PaInt32 is not acceptable for my use case, as
I need to know at opening if it's 24bits or not.

You'll need some host-api-specific magic to detect whether the hardware
natively supports 24-bit and that the path between hardware and your
code is bit-transparent.

Post by Louis-Paul CORDIER
2. I will give a try to Wasapi exclusive mode, but still portaudio can
silently do a conversion to my understanding of the code.

Yes, that is the normal and expected behavior of the PortAudio API.

Post by Louis-Paul CORDIER
3. I digged into the source code this morning and to my understanding
of the Windows SDK doc, it would be possible to determine if the
audio format is supported or not by the device. (from
https://docs.microsoft.com/en-us/windows/desktop/api/audioclient/nf-audioclient-iaudioclient-isformatsupported)
"For shared mode, if the audio engine supports the caller-specified
format, *IsFormatSupported* sets **ppClosestMatch* to *NULL* and
returns S_OK. If the audio engine does not support the
caller-specified format but does support a similar format, the
method retrieves the similar format through the /ppClosestMatch/
parameter and returns S_FALSE. If the audio engine does not support
the caller-specified format or any similar format, the method sets
/*ppClosestMatch/ to *NULL* and returns AUDCLNT_E_UNSUPPORTED_FORMAT."

I'm not sure what "support" means in that context. In my reading, it
doesn't necessarily mean that the hardware natively uses that format. I
guess you can try it and see.

Post by Louis-Paul CORDIER
After reading into the PA wasapi code, it seems that you developed
an heuristic for selecting the right audio format. So even in shared
mode, we could add a flag that will make Pa_IsFormatSupported to
fail if the underlying device can't provide the exact format
requested by the user instead of executing the heuristic.

If that is technically possible, you could add it as a host-api-specific
extension flag, for sure.

Post by Louis-Paul CORDIER
4. Side note 1: I've found some function in pa_utils very useful, even
for the end user. it would be great to export functions into this
header while installing portaudio with CMake?

These functions are intentionally left private so that we have the
freedom to change their interfaces. Keeping the public API stable is
enough work without needing to keep our internal APIs stable too.

That said, you can always make a copy of any files and use them in your
own code. The MIT licence is not viral and there's no problem doing this.

Post by Louis-Paul CORDIER
5. Side note 2: I jumped into Portaudio CMakeLists.txt. It does not
look like a "modern cmake". Would it be accepted by the community if
I update the CMakeLists? Maybe these 2 last questions deserve
another thread in the mailing list though...

Nick is the Cmake guy. The only thing I'd add would be that not all
patforms have recent versions of Cmake available, we wouldn't want to
require "bleeding edge" versions, but maybe there's some room to move.

Ross.

Alberto di Bene

2018-07-10 09:33:33 UTC

Permalink

Post by Axel Holzinger
I can confirm that via WASAPI in exclusive mode on Windows (tested only with
Windows 10) bit transparent operation with 24 bits per sample with PortAudio
is working well.

This brings back a problem I have ever had... is there a way to set programmatically WASAPI
in exclusive mode ? Not all the users of my application are so technically savvy to be able to
open the Control Panel and do that manually...

73Â AlbertoÂ I2PHD

Axel Holzinger

2018-07-10 09:54:21 UTC

Permalink

Ciao Alberto,

it works the other way round: your application has to specifiy exclusive mode. With PortAudio this is a PortAudio WASAPI host API setting.

Un caro saluto

Axel

From: portaudio-***@lists.columbia.edu [mailto:portaudio-***@lists.columbia.edu] On Behalf Of Alberto di Bene
Sent: Tuesday, July 10, 2018 11:34 AM
To: ***@lists.columbia.edu
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

On 2018-07-10 8:47, Axel Holzinger wrote:

I can confirm that via WASAPI in exclusive mode on Windows (tested only with
Windows 10) bit transparent operation with 24 bits per sample with PortAudio
is working well.

This brings back a problem I have ever had... is there a way to set programmatically WASAPI
in exclusive mode ? Not all the users of my application are so technically savvy to be able to
open the Control Panel and do that manually...

73 Alberto I2PHD

Alberto di Bene

2018-07-10 14:10:40 UTC

Permalink

Post by Axel Holzinger
Ciao Alberto,
it works the other way round: your application has to specifiy exclusive mode. With PortAudio this is a PortAudio
WASAPI host API setting.
Un caro saluto
Axel

Louis-Paul CORDIER

2018-07-10 14:55:44 UTC

Permalink

Hi again,

So I tried to enable the exclusive mode with Wasapi. Looking at Windows
recording tab (Im' under Windows 7), it says 2 channel, 24 bit, 44100 Hz
(Studio Quality).

When I try to use Pa_IsFormatSupported(), with paInt24 or paFloat32,
44100Hz and number of channel = 2, the function returns that the format
is not supported.

Any clues?

*Best Regards/ *

*Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/*

Post by Alberto di Bene

Post by Axel Holzinger
Ciao Alberto,
it works the other way round: your application has to specifiy
exclusive mode. With PortAudio this is a PortAudio WASAPI host API
setting.
Un caro saluto
Axel

Ciao Axel,
Â thanks for your answer. But something escapes me... what happens if
the application specifies exclusive mode, but in the Sound applet of
the Control Panel the mode is set as shared ? Will it be reverted to
exclusive ?
Cari saluti,
73Â AlbertoÂ I2PHD
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

R0b0t1

2018-07-11 16:11:02 UTC

Permalink

Post by Ross Bencina
Hello Louis,
From the code that you're quoting, it sounds like you're using the PA/WMME
back-end. I don't think 24-bit I/O is implemented for PA/WMME.
You need to select the ASIO or perhaps WASAPI back-ends to get 24-bit I/O.
In any case, PortAudio provides no way to tell you whether the device itself
supports 24-bit (few native APIs do provide this). In general PortAudio will
up-convert if it can only get 16-bit from the device. IsFormatSupported is
more like
PaWillNotFailWithAFormatErrorIfYouTryToOpenTheStreamWithThatFormat. In the
case of sample rate and channel count, the system needs to support those
values, in the case of sample format, PA does the formtat conversion itself.

That seems kind of unhelpful. The user could just pick a different
format. Is there any chance this can be changed?

It looks like this the thread after this message was discussing workarounds.

Post by Ross Bencina
I can confirm that via WASAPI in exclusive mode on Windows (tested only with
Windows 10) bit transparent operation with 24 bits per sample with PortAudio
is working well.
Anyhow a function to really get the device capabilities would be very
useful. This was also missing in the native (Windows) APIs, which in the
past made me write Windows code that really tries to open the device in all
thinkable formats to really find out, if it's supporting some format. So it
might be hard to add such a function in PortAudio.
Just my 0.02$
Axel

If the information can't be found that makes sense, but usually it can
be found. If it is not buried in the audio interface somewhere, is it
not in WMI? Granted, sometimes the WMI classes are specified to have
the information you want, but not filled in...

Cheers,
R0b0t1

Ross Bencina

2018-07-12 06:30:33 UTC

Permalink

Hi R0b0t1,

Post by R0b0t1

Post by Ross Bencina
In any case, PortAudio provides no way to tell you whether the device itself
supports 24-bit (few native APIs do provide this). In general PortAudio will
up-convert if it can only get 16-bit from the device. IsFormatSupported is
more like
PaWillNotFailWithAFormatErrorIfYouTryToOpenTheStreamWithThatFormat. In the
case of sample rate and channel count, the system needs to support those
values, in the case of sample format, PA does the formtat conversion itself.

That seems kind of unhelpful. The user could just pick a different
format. Is there any chance this can be changed?

Pa_IsFormatSupported provides a way to check which formats are
*supported* by PortAudio (i.e. which formats should succeed when passed
to Pa_OpenStream). In other words, which formats the PA client can use.

What exactly do you think is unhelpful?

Post by R0b0t1
If the information can't be found that makes sense, but usually it can
be found.

To move this forward you'd need to provide supporting evidence for all
of our supported host APIs. The usual way forward for anything like this
is to provide host API-specific implementations, then we can think about
how to make something portable in the main PA API.

In any case, I think at this stage the meaning of IsFormatSupported is
baked-in: it means that you can open a stream with that format. It says
nothing about how samples in that format are transformed from the
source. That might not be in line with your requirements, but I think
it's consistent with the API design of making things easy for clients
(i.e. the sample format is the thing that the client wants to use, not
necessarily the thing that the hardware uses natively).

Ross.

Chris

2018-07-10 18:50:44 UTC

Permalink

There are two checkboxes below the drop-down list that allows you to select the recording mode. They control Exclusive Mode for that device. With those boxes checked you can ignore the list of recording modes.

-----Original Message-----
From: Louis-Paul CORDIER <***@dynamixyz.com>
To: portaudio <***@lists.columbia.edu>
Sent: Tue, Jul 10, 2018 7:56 am
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

Hi again,

So I tried to enable the exclusive mode with Wasapi. Looking at Windows recording tab (Im' under Windows 7), it says 2 channel, 24 bit, 44100 Hz (Studio Quality).

When I try to use Pa_IsFormatSupported(), with paInt24 or paFloat32, 44100Hz and number of channel = 2, the function returns that the format is not supported.

Any clues?

Best Regards/

Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/

Le 10/07/2018 à 16:10, Alberto di Bene a écrit :

On 2018-07-10 11:54, Axel Holzinger wrote:

Ciao Alberto,

it works the other way round: your application has to specifiy exclusive mode. With PortAudio this is a PortAudio WASAPI host API setting.

Un caro saluto

Axel

Ciao Axel,

thanks for your answer. But something escapes me... what happens if the application specifies exclusive mode, but in the Sound applet of the Control Panel the mode is set as shared ? Will it be reverted to exclusive ?

Cari saluti,

73 Alberto I2PHD

_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

Axel Holzinger

2018-07-11 05:30:34 UTC

Permalink

My understanding was that if the mode specified in the control panel matches the mode you specify as format for WASAPI and you choose (in your app) exclusive mode and no other app is using the device then WASAPI exclusive mode is working even without the checkbox in control panel checked. Sometimes there is a process "using" (keeping it open) a device in the background and it can be really hard to find out which it is.

HTH
Axel

-----Original Message-----
From: portaudio-***@lists.columbia.edu [mailto:portaudio-***@lists.columbia.edu] On Behalf Of Chris
Sent: Tuesday, July 10, 2018 8:51 PM
To: ***@lists.columbia.edu
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

There are two checkboxes below the drop-down list that allows you to select the recording mode. They control Exclusive Mode for that device. With those boxes checked you can ignore the list of recording modes.

-----Original Message-----
From: Louis-Paul CORDIER <***@dynamixyz.com>
To: portaudio <***@lists.columbia.edu>
Sent: Tue, Jul 10, 2018 7:56 am
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

Hi again,

So I tried to enable the exclusive mode with Wasapi. Looking at Windows recording tab (Im' under Windows 7), it says 2 channel, 24 bit, 44100 Hz (Studio Quality).

When I try to use Pa_IsFormatSupported(), with paInt24 or paFloat32, 44100Hz and number of channel = 2, the function returns that the format is not supported.

Any clues?

Best Regards/

Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/

Le 10/07/2018 à 16:10, Alberto di Bene a écrit :

On 2018-07-10 11:54, Axel Holzinger wrote:

Ciao Alberto,

it works the other way round: your application has to specifiy exclusive mode. With PortAudio this is a PortAudio WASAPI host API setting.

Un caro saluto

Axel

Ciao Axel,

thanks for your answer. But something escapes me... what happens if the application specifies exclusive mode, but in the Sound applet of the Control Panel the mode is set as shared ? Will it be reverted to exclusive ?

Cari saluti,

73 Alberto I2PHD

_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

Chris

2018-07-11 08:25:03 UTC

Permalink

By "mode" do you mean "exclusive mode" or things such as bit depth, sample rate, no. of channels, etc.?

Those checkboxes are there for a reason. Exclusive means exclusive, i.e. no other process can use that device. That's how they avoid using KMixer from the old-fashioned Windows audio architecture.

-----Original Message-----
From: Axel Holzinger <***@gmx.de>
To: 'portaudio list' <***@lists.columbia.edu>
Sent: Tue, Jul 10, 2018 10:32 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

My understanding was that if the mode specified in the control panel matches the mode you specify as format for WASAPI and you choose (in your app) exclusive mode and no other app is using the device then WASAPI exclusive mode is working even without the checkbox in control panel checked. Sometimes there is a process "using" (keeping it open) a device in the background and it can be really hard to find out which it is.HTHAxel

Axel Holzinger

2018-07-11 10:03:38 UTC

Permalink

Sorry, I was not precise. I meant bit depth, sample rate, no. of channels,
etc..

-----Original Message-----
From: portaudio-***@lists.columbia.edu
[mailto:portaudio-***@lists.columbia.edu] On Behalf Of Chris
Sent: Wednesday, July 11, 2018 10:25 AM
To: ***@lists.columbia.edu
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

By "mode" do you mean "exclusive mode" or things such as bit depth, sample
rate, no. of channels, etc.?

Those checkboxes are there for a reason. Exclusive means exclusive, i.e. no
other process can use that device. That's how they avoid using KMixer from
the old-fashioned Windows audio architecture.

-----Original Message-----
From: Axel Holzinger <***@gmx.de>
To: 'portaudio list' <***@lists.columbia.edu>
Sent: Tue, Jul 10, 2018 10:32 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

My understanding was that if the mode specified in the control panel matches
the mode you specify as format for WASAPI and you choose (in your app)
exclusive mode and no other app is using the device then WASAPI exclusive
mode is working even without the checkbox in control panel checked.
Sometimes there is a process "using" (keeping it open) a device in the
background and it can be really hard to find out which it is.HTHAxel

Louis-Paul CORDIER

2018-07-11 14:27:55 UTC

Permalink

Ok I have found the issue. It seems it's a bug in wasapi implementation
in portaudio.

File pa_win_wasapi:2213 (current commit:
8dc6d59877f2d102065871c3ef3020f3b98fd6b1) in function
MakeWaveFormatFromParams:

Changing:

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

Into

old->wBitsPerSample = bitsPerSample

Solves the problem for IAudioClient_IsFormatSupported returning an
error. Is there any reason for forcing 32 bits? I think this function
need a rework as it can break other part in portaudio...

*Best Regards/ *

*Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/*

Post by Axel Holzinger
Sorry, I was not precise. I meant bit depth, sample rate, no. of channels,
etc..
-----Original Message-----
Sent: Wednesday, July 11, 2018 10:25 AM
Subject: Re: [Portaudio] "Real" 24 bits with portaudio
By "mode" do you mean "exclusive mode" or things such as bit depth, sample
rate, no. of channels, etc.?
Those checkboxes are there for a reason. Exclusive means exclusive, i.e. no
other process can use that device. That's how they avoid using KMixer from
the old-fashioned Windows audio architecture.
-----Original Message-----
Sent: Tue, Jul 10, 2018 10:32 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio
My understanding was that if the mode specified in the control panel matches
the mode you specify as format for WASAPI and you choose (in your app)
exclusive mode and no other app is using the device then WASAPI exclusive
mode is working even without the checkbox in control panel checked.
Sometimes there is a process "using" (keeping it open) a device in the
background and it can be really hard to find out which it is.HTHAxel
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio
_______________________________________________
Portaudio mailing list
https://lists.columbia.edu/mailman/listinfo/portaudio

Chris

2018-07-11 19:31:22 UTC

Permalink

I have forwarded this change directly to Dmitry, who has written most (almost all) of the WASAPI code for PortAudio.

-----Original Message-----
From: Louis-Paul CORDIER <***@dynamixyz.com>
To: portaudio list <***@lists.columbia.edu>; Axel Holzinger <***@gmx.de>
Sent: Wed, Jul 11, 2018 7:28 am
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

Ok I have found the issue. It seems it's a bug in wasapi implementation in portaudio.

File pa_win_wasapi:2213 (current commit: 8dc6d59877f2d102065871c3ef3020f3b98fd6b1) in function MakeWaveFormatFromParams:

Changing:

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

Into

old->wBitsPerSample = bitsPerSample

Solves the problem for IAudioClient_IsFormatSupported returning an error. Is there any reason for forcing 32 bits? I think this function need a rework as it can break other part in portaudio...

Best Regards/

Louis-Paul CORDIER
Product Engineer - Dynamixyz
http://dynami.xyz/

Le 11/07/2018 à 12:03, Axel Holzinger a écrit :

Sorry, I was not precise. I meant bit depth, sample rate, no. of channels,
etc..

-----Original Message-----
From: portaudio-***@lists.columbia.edu
[mailto:portaudio-***@lists.columbia.edu] On Behalf Of Chris
Sent: Wednesday, July 11, 2018 10:25 AM
To: ***@lists.columbia.edu
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

By "mode" do you mean "exclusive mode" or things such as bit depth, sample
rate, no. of channels, etc.?

Those checkboxes are there for a reason. Exclusive means exclusive, i.e. no
other process can use that device. That's how they avoid using KMixer from
the old-fashioned Windows audio architecture.

-----Original Message-----
From: Axel Holzinger <***@gmx.de>
To: 'portaudio list' <***@lists.columbia.edu>
Sent: Tue, Jul 10, 2018 10:32 pm
Subject: Re: [Portaudio] "Real" 24 bits with portaudio

My understanding was that if the mode specified in the control panel matches
the mode you specify as format for WASAPI and you choose (in your app)
exclusive mode and no other app is using the device then WASAPI exclusive
mode is working even without the checkbox in control panel checked.
Sometimes there is a process "using" (keeping it open) a device in the
background and it can be really hard to find out which it is.HTHAxel
_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio

_______________________________________________
Portaudio mailing list
***@lists.columbia.edu
https://lists.columbia.edu/mailman/listinfo/portaudio