[Portaudio] using paFramesPerBufferUnspecified

Ross Bencina rossb-lists at audiomulch.com
Tue Dec 15 23:35:44 EST 2015

Hi Rob,

On 16/12/2015 5:00 AM, Robert Bielik wrote:
> Den 2015-12-15 kl. 07:55, skrev Ross Bencina:
>> You can use it however you want. But you won't know how many samples
>> it needs until the callback is called.
> I've been thinking about this. In WDM/KS, WASAPI, ASIO, CoreAudio and
> ALSA, the number of frames in the callback will be known (to the API)
> after calling Pa_OpenStream (even with
> paFramesPerBufferUnspecified) but prior to starting the stream. It would
> make sense to perhaps add an int to PaStreamInfo with #frames ?

I don't want to define portaudio.h APIs that are only valid for a subset 
of host APIs, because it breaks portability of client code. But there 
are some related options that are feasible:

We could report an upper bound on the callback buffer size. That has 
been requested in the past (by Stephan Letz I think).

We could add a new mode paFramesPerBufferFixedButUnspecified, that would 
force the callback buffer size to be fixed. Then we could report the 
fixed size as you want. For the host APIs that you mention, there would 
be no substantial change to the implementation. For other host APIs we'd 
need to force the callback buffer size to be fixed.

Maybe this means adding two fields to the stream info:

framesPerBuffer		// zero if not fixed
maxFramesPerBuffer	// upper bound if framesPerBuffer is zero, otherwise 
equal to framesPerBuffer

I do think that it makes sense to retain the 
paFramesPerBufferUnspecified option as it is the most permissive/relaxed 
mode possible.

That's my two cents anyhow.


More information about the Portaudio mailing list