On Fri, Sep 4, 2015 at 11:28 AM Ian Esten <i...@ianesten.com> wrote: > 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. >
It is if you're using a low latency backend. But if you have a reasonably large buffer and the backend gives you control over that buffer, then it might sense to not fulfill all possible frames. For example, in a music player, the device buffer might already have 1 second of audio but then it catches up to the decoding thread. At this point it makes sense to let the device buffer take the hit for a bit while the decoding thread catches up. > > >> > >> 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. > I'm going to look carefully into this. I think you brought up a potential flaw in the libsoundio API, in which case I'm going to figure out how to address the problem and then update the API.
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
