> So when you
> disconnect, suddenly all the music will come rushing out (do they get
> played in the correct time, or do you hear all the notes literally at the
> same time?).
All at once.
OK, so FS is probably trying to play all the notes at a certain time offset from the start of the piece, but can't do anything. When you "unclog the pipe", every note that should have played during that time suddenly has a timestamp less than the current time, so it is played. Am I right in guessing that it doesn't play the entire rest of the song, only the notes that should have been played up until that point (if you wait 20 seconds before killing it, you hear all the notes from the first 20 secs of the song, but then the song continues as normal from that point?)
While it's true that all the connections from the first instance of my program
will crash, connections from subsequent instances do not - provided it's still
the same instance of fluidsynth. Maybe once a crash has occurred (i.e. the
buffer has become full), fluidsynth stops writing to stdout?
Hmm. I can't really explain that.
Nail on the head once again. Thank you.
(If fact I seem to get the same effect by simply calling close() on the stdout
file, as soon as it is opened, although that worries me - where is the output
going now?)
Great. Well what you are probably seeing there is C's terrible error handling capabilities. All the stdio writing functions (such as putc) are defined as returning some error code if they fail. putc returns EOF (-1) on error, or the character written on success. So if you (FS) attempt to putc to a blocked pipe, the call to putc will block until the pipe is read from or closed. If the pipe is closed, it will immediately return EOF (which you described above). If you attempt to putc a closed pipe, it will not block or crash. It will simply return -1 and continue happily on its way. Most programs, FS included, will not bother to check if every single write to stdout returns a success code -- would you bother!? Most people would just assume stdout is open. Therefore, closing stdout doesn't phase FS -- it will just continue sending characters there and every single one of them will fail, but that won't mess up anything. Still, it's not ideal to rely on it since in theory someone could come along and check if it returns an error. The devnull technique I suggested (forgive me if you already know) just opens a pipe to /dev/null (or your OS equivalent, e.g. in Windows, NUL), which is a special file that can be written to forever and simply discards all the bytes -- precisely the purpose you are after.
Matt