On Tue, Feb 09, 2021 at 07:35:12PM -0800, Elijah Stone wrote: > Hi all, > > The manual page for sndio currently says: > > > using the buffer usage to guess if sio_write() would block is false and > > leads to unreliable programs > > Why is this? Is it perhaps talking about using bufsz instead of appbufsz? Hi, As soon as the hardware consumes buffered samples, space is freed and the same amount could be transmitted with sio_write(). However the code used to transmit the samples may block (eg. network layers may block), and it's difficult to calculate in advance how many bytes could be written without blocking even if we know the amount of free buffer space. > (Additionally, is there a way to tell how much can be written without > blocking? An equivalent to alsa's snd_pcm_avail or SNDCTL_DSP_GETOSPACE?) > To answer your question, the space available in the hardware buffer is: buf_avail = sio_par.bufsz - buf_used = sio_par.bufsz - (samples_written - samples_played) The numer of samples played is the sum of "deltas" passed to the sio_onmove() call-back. If space is available, sio_write() still could block. The SNDCTL_DSP_GETOSPACE-style interfaces used to be used for two different things: (1) calculate the current play position: for instance, video players need it to synchronize video to audio. The current play position is easily obtained using sio_onmove() (2) determine how many bytes to write. There's no sndio equivalent for this, the program could use poll() and non-blocking sio_write() which is the standard unix way to implement event loops. Finally, note that network layers are fast, so if there's space available in the hardware buffer, sio_write() may block, but not for very long. This might be acceptable, depending on the program. For low-latency real-time synths it is not acceptable. For players that use large buffers it works, though that's not very elegant. If you provide more details about the program, maybe I could point you to code of a similar program HTH -- AlexandreReceived on Wed Feb 10 2021 - 12:47:21 CET
This archive was generated by hypermail 2.3.0 : Tue Aug 09 2022 - 16:23:50 CEST