This backs out commit 40c37b5c (use arc4random) except for the header include. Crappy old rand(3) is fine for this program. It's just bad form on OpenBSD and its linker spews an annoying warning about it. FWIW, Linux finally got arc4random(3) with glibc >= 2.36 (2022) so it could actually be considered fairly portable now. However, for the time being, I'd like to still support older systems. NB, the closest "native" alternative, getentropy(3), appears in glibc >= 2.25 (2017), so even it is not exactly ancient, yet. Thus, instead of mucking around with wrappers, feature flags and conditional compilation, rand() is still it for portable.

(Empty for now.)

GNU make does not have $> (.ALLSRC) but $^ instead. The trick is to just use both since each implementation defines one but not the other. XD

While crappy old rand(3) is fine for this program and uses arc4random(3) on OpenBSD anyway, the linker spews a warning about it and the noise during compilation is annoying me. FWIW, Linux finally got arc4random(3) with glibc >= 2.36 (2022) so it could actually be considered fairly portable now. However, for the time being, I'd like to still support older systems. NB, the closest "native" alternative, getentropy(3), appears in glibc >= 2.25 (2017), so even it is not exactly ancient, yet. Thur, instead of mucking around with wrappers, feature flags and conditional compilation, rand() is still it for portable.

This is a workaround to guard against the possibility that the onmove callback is not called at all. This happens if playback has not started before cwstop(), and hence sio_stop(), is called.

Measure and take into account the "return latency" of cwstop(), i.e. the time it took between playback stopping ang cwstop() returning, usually negative.

This is an intermediate commit of some experimental changes: - playback in synchronous mode (par.xrun = SIO_SYNC) - tracking of play position via sio_onmove() and total frames written - (broken/ignored) reporting of "time remaining" from sound() and friends - debug instrumentation (#ifdef DEBUGTIME)

Turns out my times were measured in centiseconds rather than milliseconds as advertised. Oops. Only discovered when looking to make them exact for the first time. Had mostly ignored the values as "probably way off anyway". That appears to have been an accurate assessment. X) It does show nicely how the algorithm doesn't care about absolute values. It operated just fine on centiseconds.