[Portaudio] using paFramesPerBufferUnspecified
rossb-lists at audiomulch.com
Tue Dec 15 23:35:44 EST 2015
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
That's my two cents anyhow.
More information about the Portaudio