The current implementation unconditionally reads from the pipe when the
timer has fired. If nothing is read from the pipe, an audio message with
all PCM audio data set to zero is created. If less than the requested
packet bytes are read, the remaining bytes are filled up with zeros, too.
Even if no data is read from the pipe an audio message with zero data is
created and sent to the Receivers (unless an severe error occurs).
The Songcast OHM/OHU Protocol Specification (Version 1.0) states, that:
If no audio material is to be played because, for instance, the user has
told the sender to pause playback, then the sender should not send silence.
Rather, the sender should adorn the last Audio message with the 'halt' flag
to indicate that this continuous stream of audio has completed and that the
next continuous stream of audio will start at an arbitrary time in the future.
To do so, the commit does not generate an audio message anymore, if no
data was read from the pipe, but stills fills up an partial read buffer with
zeros.
There is still another issue to consider: to detect if the pipe sender has
stopped writing data to the pipe, so the Songcast sender can set the
halt flag properly.
As it is impossible for the Songcast sender to decide if the the audio
stream has completed, it is necessary by the producer of the audio
stream to initiate a stop of the streaming, e.g. by issueing the "stop"
user command.
After being instructed to stop the streaming, the Songcast sender needs
to empty the pipe until no data are read anymore. Otherwise, the
remaining data in the pipe will be read the next time the timer thread
starts. Therefore, read the pipe until less or no data or read from the
pipe in which case the end of the audio stream is assumed and the
Songcast Sender sets the halt flag.
