In the cartoon description of Broadcast Output below, the primary source of audio drop outs is assumed to be network jitter (rather than limitations in local computer processing speed).
Remote audio arrives in packages with varying transit delays. Each packet is duplicated and loaded onto two conveyor belts (jitter buffers).
Using a short jitter buffer for audio destined for playback in the local performer's headphones prevents received remote audio from waiting around too long before playback at the local performer's headphones but also makes the audio in the local performer's headphones vulnerable to drop outs that result from late-arriving remote audio packets.
Using a long jitter buffer for audio destined for broadcast substantially protects against late-arriving remote audio packets resulting in audible drop outs. However, audio data passing through a long jitter buffer typically "rides along the conveyor belt" for a long time before playback, making broadcast output too laggy to listen to when trying to play together in real time.
You can route Broadcast Output to a livestreaming platform (e.g. Restream) using a virtual soundcard (e.g. Blackhole or Rogue Amoeba Loopback). A low-latency application sends audio data to a virtual soundcard "fully expecting" the virtual soundcard to act like "an actual soundcard." Do NOT turn off the virtual soundcard while the low-latency audio application is sending Broadcast Output to the virtual soundcard. The abrupt ceasing of existence of a virtual soundcard a low-latency audio application is expecting to be able to continue to send audio data to can cause the low-latency audio application to crash.
Choose equipment to use with Jamulus 
Choose equipment to use with SonoBus 
Choose equipment to use with Soundjack 
Setup instructions
Setup instructions for
1-page general reference
Troubleshooting
Legacy documentation