Live Sources And Streams

Live sources are used when the station needs to include an external signal in the broadcast. This can be a remote broadcast, a live show from another location, a hardware codec or an internet stream.

Common sources include:

  • Barix or Comrex codec outputs.
  • Icecast or Shoutcast streams.
  • Other remote or studio contribution sources that are reachable from the on-air computer.

Power Studio distinguishes between Live input sources and Web stream sources. A live input is normally tied to a device or studio route. A web stream is normally tied to a stream URL and network behavior.

Prepare The Source

Before adding a live source to a format, check:

  • The URL, device address or input route is stable.
  • The on-air computer can reach the source.
  • Audio level and channel layout are correct.
  • The source is available before the scheduled join time.
  • There is a fallback if the source is late or unavailable.

If the source depends on the public internet, test it during the same time window and under similar network conditions as the real broadcast.

Define sources in Options and Settings > Live sources before using them in Clock Formats or adding them to a playlist. Give each source a name that operators recognize during live operation.

For web streams, confirm the default duration, retry behavior and reconnect behavior match the broadcast. A short bulletin stream should fail fast enough for an operator to recover; a long remote broadcast may need more tolerant reconnect behavior.

Power Studio can retry and reconnect web streams when the connection is interrupted. If a stream is invalid or disabled, playout should continue with silence for that source instead of blocking the players. This gives the operator time to recover without freezing the rest of the playout workflow.

Use In Clock Formats

Add the live source at the correct line in the Clock Format. Treat a scheduled live stream like other fixed content: review what plays before it, what happens after it and whether the hour should float.

For exact joins, use a non-floating hour or design the format so the stream line is reached at the intended time. For looser remote programming, floating behavior may give a more natural transition.

Operators can also add a live source or web stream directly from the playlist context menu. Use this for planned ad-hoc programming or recovery, and then review the playlist timing afterward.

Fallback Planning

A live source should always have a fallback plan. Common approaches are:

  • Keep normal playlist items after the live source.
  • Prepare a static emergency item.
  • Use carts for immediate manual recovery.
  • Keep a known-good local program or music block available.

For unattended broadcasts, test the failure behavior deliberately before using the source for real programming.

When using internet streams, test both normal playback and failure recovery:

  • Disconnect the source during a maintenance test and confirm reconnect behavior.
  • Disable or mistype a test stream and confirm the players remain usable.
  • Check what the playlist does after the planned stream duration ends.
  • Confirm the next item after the stream is available locally or through the normal audio storage.

Operator Checks

Before the live segment:

  1. Load and review the correct playlist.
  2. Confirm the source is already active or expected to become active on time.
  3. Preview the source where possible.
  4. Confirm the next item after the source.
  5. Confirm who decides when to leave the live source.

After the broadcast, review logs and operator notes if the source joined late, dropped out or had incorrect audio level.