Fifo Length

Audio processing typically uses buffers or "blocks" to scoop up data and feed it through the program. This avoids hundreds of hard drive or input stream accesses, or, if the hard drive or stream is busy or compromised by other demands, it avoids drop outs. The same thing happens on the output side, but the down side is the enemy of all audio processing – latency.
This means that it might take several seconds to fill up the buffers, and the same time to empty them, creating a gap between the real time audio and the processed audio. This can be most noticeable when processing music, because the lip sync or things like hitting a drum snare does not line up with the audio. In radio, the announcer's spoken word if fed through a processor, comes back to him delayed by milliseconds, making it very hard to monitor your own voice.

Generally, leave the fifo settings at the defaults, but, if you can reduce them and not get dropouts or glitches, this may improve latency. Conversely, if, at the default, there are still glitches, increasing the size may improve, but at the expense of higher latency.

No, I don't believe that is the case. Your announcers should be listening to the source (straight out of the mixing desk, or wherever your mic processing output is). In the good old days, before all the processing that occurs these days, we used to listen "off air", meaning that we heard what the listeners heard. However, that only works if the STL is not far away and therefore the difference between the input signal and the returned (broadcast) signal is only milliseconds, which our brain cannot detect. This was an advantage because we could detect instantly if the broadcast chain went down (as in a transmitter or STL failure).

Nowadays, there are many delays between the studio and, in the case of (say) a terrestrial FM broadcast (which might be almost straight out of the studio console) but also streamed through (say) Icecast, listening off the Internet would confuse even the most seasoned broadcaster.