- * Firstly the loop is terminated when the parent process exits. Therefore the
- * speaker process has the same lifetime as the main server. This and the
- * reading of data from decoders is comprehensible enough.
- *
- * The playing of audio is more complicated however.
- *
- * On the first run through when a track is ready to be played, @ref ready and
- * @ref forceplay will both be zero. Therefore @c beforepoll is not called.
- *
- * @c afterpoll on the other hand @b is called and will return nonzero. The
- * result is that we call @c play(0). This will call activate(), setting
- * @ref ready nonzero, but otherwise has no immediate effect.
- *
- * We then deal with stdin and the decoders.
- *
- * We then reach the second place we might play some audio. @ref forceplay is
- * 0 so nothing happens here again.
- *
- * On the next iteration through however @ref ready is nonzero, and @ref
- * forceplay is 0, so we call @c beforepoll. After the @c poll() we call @c
- * afterpoll and actually get some audio played.
- *
- * This is surely @b far more complicated than it needs to be!
- *
- * If at any call to play(), activate() fails, or if there aren't enough bytes
- * in the buffer to satisfy the request, then @ref forceplay is set non-0. On
- * the next pass through the event loop @c beforepoll is not called. This
- * means that (if none of the other FDs trigger) the @c poll() call will block
- * for up to a second. @c afterpoll will return nonzero, since @c beforepoll
- * wasn't called, and consequently play() is called with @ref forceplay as its
- * argument.
- *
- * The effect is to attempt to restart playing audio - including the activate()
- * step, which may have failed at the previous attempt - at least once a second
- * after an error has disabled it. The delay prevents busy-waiting on whatever
- * condition has rendered the audio device uncooperative.