[Portaudio] using paFramesPerBufferUnspecified
gbarges at free.fr
Tue Dec 15 12:47:29 EST 2015
> On 15/12/2015 5:41 PM, Gilles Barges wrote:
>> I?d like to use the paFramesPerBufferUnspecified option to shorten
>> In this case, it is said that the number of frames for each callback may
> Yes, the value may vary. For example, the value might depend on the fill
> level of a native audio buffer at the time of the callback. The callback
> will ask to fill all the empty space in the buffer.
>> So it seems that I have to wait for the callback to occur in order to
>> know how many frames I have to push on output.
>> In my architecture I have a dedicated thread (not the CB thread) to
>> prepare in advance the next chunk of audio.
> It would be unusual for there to be benefit to such a scheme, but I
> trust you know what you're doing.
I am sure that my callback will not last too long, doing only memcpy().
If the calculation of a buffer takes more than its duration, the callback will output silence, and errors are kept inside my application.
Also, it’s difficult to report errors from inside the callback.
And by putting heavy calculations in a separate thread, I keep my graphic interface fluid, at least on a multicore.
Do you mean most PA users put (possibly CPU consuming) audio generation inside the callback function ?
>> As soon as the callback occurs, I can start to prepare audio.
> Do you mean that as soon as one callback is called, you start to prepare
> for the next one?
Yes. Or save on disk recorded audio.
>> But here I don?t know how many frames the next callback will ask !
> Neither does PortAudio.
>> So, is paFramesPerBufferUnspecified only usable when the audio is
>> elaborated directly from inside the callback function ?
> You can use it however you want. But you won't know how many samples it
> needs until the callback is called.
Thank you, this is clear.
I suppose I cannot be told a superior limit ?
More information about the Portaudio