[Portaudio] Do I need to care about overflow/underflow when using the read/write API?

sqweek sqweek at gmail.com
Sun Mar 20 08:02:29 EDT 2016

On 20 March 2016 at 11:46, Spencer Russell <sfr at media.mit.edu> wrote:
> The issue here is that I’d want the portaudio buffer to be large to cover
> pauses (several seconds), but then when my user calls `write(sink,
> audiobuffer)`, they’re going to experience the buffer-length of delay
> before they hear the audio.

Yeah, its hard for a language binding to decide what the buffer-length
should be. I don't think this aspect of audio can be abstracted away;
ultimately the programmer needs to understand the pros and cons of low vs.
high latency and decide for themselves.

> So I guess the question probably comes down to:
> When PortAudio experiences an underflow, does it feed zeros to the
> underlying Host API, or does the Host API “know” about the underflow? Based
> on my experience lurking on this list I’m guessing the answer is “it
> depends on the host API”.
> If the underflow is passed to the Host API, in practice are there APIs in
> the wild that react poorly, or is it OK?

JACK on linux comes to mind; it is likely to kick clients out of the audio
graph if their callback doesn't provide samples quickly enough (ie. the
stream is automatically stopped). But this shouldn't happen for a portaudio
stream in blocking mode, since portaudio's JACK host API implementation
feeds zeros to JACK if the ring buffer doesn't contain enough data.

I haven't checked other host APIs, but ultimately if julia leaves you with
unpredictable unbounded delays then there doesn't seem much choice but to
rely on portaudio's blocking API. As you said, having a
ring-buffer/callback on the julia side doesn't do much to guarantee
portaudio's buffer will remain full...

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.columbia.edu/pipermail/portaudio/attachments/20160320/5b21fa8d/attachment-0001.html>

More information about the Portaudio mailing list