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. > 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.
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
