[Portaudio] using paFramesPerBufferUnspecified
rossb-lists at audiomulch.com
Tue Dec 15 23:41:36 EST 2015
On 16/12/2015 4:47 AM, Gilles Barges wrote:
>>> 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.
If you expect this to regularly be the case (e.g. your users have the
option of executing time-unbounded code into the callback.) then I agree
it is can be a good idea.
> Also, it’s difficult to report errors from inside the callback.
I'm not sure what you mean by this. Usually you'd set up a lock-free
queue to log messages back to the UI thread.
> And by putting heavy calculations in a separate thread, I keep my graphic interface fluid, at least on a multicore.
I'm not sure what you mean by this. The PA callback already runs in a
> Do you mean most PA users put (possibly CPU consuming) audio generation inside the callback function ?
There are some subtleties with certain host APIs, but that's the general
idea, yes. It is often difficult and platform-specific to set up a user
thread that runs with real-time priority -- running your DSP code in the
PA callback gives you this for free.
>>> 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.
Unless you have large buffers (and you mentioned low-latency before) I/O
should not be performed in any real-time thread, whether yours or
>>> 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 ?
This is a requested feature, but it is not currently available.
More information about the Portaudio