Commands generally don't buffer their input. They would do a
read() for a large chunk, but when reading from a pipe, if there aren't that many bytes in the pipe, the
read() system call will return with as many characters there are and the application will generally work with that if it can.
A notable exception to that is
mawk which will keep re-
read()ing until the input buffer is full.
Applications do buffer their output (stdout) though. The usual behaviour is that if the output is going to a tty, then the buffering will be line-wise (that is, it won't start writing to stdout until it has a full line to output, or a block-full for very long line), while for every other type of file, the buffering is by blocks (that is, it won't start writing until is has one block full to write (something like 4KiB/8KiB... depends on the software and system)).
So in your case
LongRunningCommand likely buffers its output by blocks (since its output is a pipe and not a tty), and
tr likely buffers its output by line since its output is probably the terminal.
But, since you remove every newline character from its output, it will never output a line, so the buffering will be by block.
So here you want to disable buffering for both
tr. On GNU or FreeBSD systems:
stdbuf -o0 LongRunningCommand | stdbuf -o0 tr '\n' ,
Note that if you want to join the lines with a comma, a better approach is to use
paste -sd , -. That way the output will be terminated by a newline character (you'll probably still need to disable buffering).