Re: [fluid-dev] Fluidsynth stops playing when stdout is piped

[John O'Hagan]

On Mon, 31 Jan 2011, Matt Giuca wrote:
> > >  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?)

That's kind of right, but the timing of the midi commands comes from my end, 
so they must get buffered somewhere by FS. If I kill FS, I don't hear anything, 
but if I kill my program, that's when all the missing notes get played by FS, 
but the song doesn't continue.

> 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.

Possibly python closes the file on first exit? When using sockets, new program 
instances only start FS if there isn't one running, so no new  stdout file is 
created. If fact in this case, the Popen object itself no longer exists, only 
the instance of FS. This is not relevant when using pipes, in which case a new 
Popen object and FS instance must be created to get the stdin file.

> 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

Thanks, all clear now; I still have a couple of subprocess.PIPE questions, but 
they're not FS-specific so I'll ask on the python list.

Regards,

John