On Fri, Sep 4, 2015 at 10:58 AM, Andrew Kelley <superjo...@gmail.com> wrote: > On Fri, Sep 4, 2015 at 10:43 AM Ian Esten <i...@ianesten.com> wrote: >> >> Thanks for sharing. Looks nice! >> >> A question: I see that the write callback supplies a minimum and maximum >> number of frames that the callback is allowed to produce. I would prefer a >> callback that instructed me to produce a given number of samples. It is >> simpler and more consistent with existing APIs. Is there a reason for the >> minimum and maximum arguments? > > > Good question. This is actually just exposing more power. You can safely > ignore `frame_count_min` and `frame_count_max` is exactly this simpler > number that you want. > > The reason the `frame_count_min` exists is that some backends support direct > control over the buffer, and for these backends, you might choose to not > write all the frames you could because maybe your input buffer is not quite > ready. Instead of writing silence and having an underrun happen you could > just wait some time for the input buffer to fill and then continue on. > > I'll update the docs to clarify this. >
Thanks! But I would say that if your input buffer is not ready, then that is an application error. >> >> And an observation: libsoundio has a read and a write callback. If I was >> writing an audio program that produced output based on the input (such as a >> reverb, for example), do I have any guarantee that a write callback will >> only come after a read callback, and that for every write callback there is >> a read callback? > > > I don't think that every sound driver guarantees this. I see that PortAudio > supports this API but I think they have to do additional buffering to > accomplish it in a cross platform manner. > > If you're writing something that is reading from an input device and writing > to an output device, I think your best bet is to use a ring buffer to store > the input. > > But, if you're creating an effect such as reverb, why bother with sound > devices at all? Sounds like a good use case for JACK or LV2. > A ringbuffer introduces a buffer's worth of delay. Not good for applications that require low latency. A DAW would be a better example than a reverb. No low-latency monitoring with this arrangement. _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
