engine-features.md

Aura Engine Features

This page gives a more detailed overview of the Aura Engine features and how to configure them.

• Aura Engine Features
  • Multi-channel Input (Filesystem, Stream, Analog)
  • Multi-channel output
    • Analog line-out
    • Stream to Icecast
  • Scheduling
  • Fallback Handling
    • Silence Detector
  • Monitoring
    • Send mails on errors and warnings
    • Engine Health Information via Engine API
    • Engine Heartbeat
    • Logging
  • Read more

Multi-channel Input (Filesystem, Stream, Analog)

It's possible to schedules playlists with music or pre-recorded show stored on the filessystem, via external streams or live from an analog input in the studio. All types of sources can be mixed in a single playlist.

Note: Any live sources or streams not specifing a length property, are automatically expanded to the left duration of the timeslot.

The switching between types of audio source is handled automatically. To learn more check out the Scheduling section.

Multi-channel output

Analog line-out

In most scenarios it might be sufficient to broadcast via only one analog stereo output. If needed you can configure up to five stereo pairs.

Stream to Icecast

Engine allows to stream to multiple Icecast Servers simultaniousely. It is also sending meta information to the streaming server, using the Icy protocol.

To configure your Icecast connectivity check-out the [stream] section in your configuration.

Scheduling

Engine provide a scheduling functionality by polling external API endpoints frequently.

Scheduling is split into multiple phase. Below you see a timline with one schedule planned at a certain point in time and the involved phase before:

================= [   Scheduling Window   ] ============ [        Timeslot Play-out                 ] ====

== (FILESYSTEM A) ========================== [ Preload ] [  Play 4  ] ====================================
== (STREAM A) ========================================== [ Preload ] [ Play 1 ] ==========================
== (LIVE 1) ====================================================== [ Preload ] [ Play 1 ] ================
== (FILESYSTEM B) ========================================================== [ Preload ] [  Play 4  ] ====

• Scheduling Window: Within the scheduling window any commands for controlling the mixer of the soundsystem are prepared and queued.

  Until the start of the window, timeslot can be added or removed via external API Endpoints (e.g. using Steering or Dashboard). Until here any changes on the timeslot itself will be reflected in the actual play-out. This only affects the start and end time of the "timeslot" itself. It does not involve related playlists and their entries. Those can still be modified after the scheduling window has started.

  The start and the end of the window is defined by the start of the schedule minus a configured amount of seconds (see scheduling_window_start and scheduling_window_end in engine.ini).

  During the scheduling window, the external API Endpoints are pulled continiously, to check for updated schedules and related playlists. Also, any changes to playlists and its entries are respected within that window (see fetching_frequency in engine.ini).

  Important: It's vital that the the scheduling window is wider than the fetching frequency. Otherwise one fetch might never hit a scheduling window, hence not being able to schedule stuff.

• Queuing and Pre-Loading: Before any playlist entries of the schedule can be turned into sound, they need to be queued and pre-loaded. Ideally the pre-loading happens somewhat before the scheduled play-out time to avoid any delays in timing. Set the maximum time reserved for pre-loading in your configuration (compare preload_offsetin engine.ini).

  Important: The offset should not exceed the time between the end of the scheduling-window and the start of the actual schedule playout.

• Play-out: Finally the actual play-out is happening. The faders of the virtual mixers are pushed all the way up, as soon it's "time to play" for one of the pre-loaded entries. Transitions between playlist entries with different types of sources (file, stream and analog inputs) are performed automatically. At the end of each schedule the channel is faded-out, no matter if the total length of the playlist entries would require a longer timeslot.

  If for some reason the playout is corrupted, stopped or too silent to make any sense, then this triggers a fallback using the silence detector (see chapter below).

Fallback Handling

Engine is able to react to common community radio scenarios, like the upload of some pre-recorded show has been forgotten, or some live show is actually not taking place. Usually in such cases the broadcast might end up with some timeslot filled with silence. To avoid this, Engine provides multiple levels of fallback handling.