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

Spencer Russell sfr at media.mit.edu
Sat Mar 19 23:46:29 EDT 2016

I’m working on the Julia PortAudio package, so
1. Not thread-safe
2. event-loop concurrency
3. unbounded pause times due to JIT and GC

The abstraction I present to users of my library is a stream read/write API, so I have two options:

1. I could have a background task (in the event loop) running with in/out ringbuffers that is polling PortAudio and feeding it whenever there’s space/data available, feeding with zeros if my Julia-side ringbuffer is empty. The idea here is to avoid overflow/underflow on the portaudio side, but it’s still not guaranteed. 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.

2. I could Only read/write to PortAudio in my library’s read/write methods, so in between reads and writes I expect to be an an overflow/underflow condition most of the time. Then when the user calls `write` it starts writing into PortAudio until we’ve written all the data, then we stop. This is nice because it avoids having a polling task all the time (it’ll still poll during reads/writes).

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?


More information about the Portaudio mailing list