Skip to content
Snippets Groups Projects
Commit e5fbb86b authored by David Trattnig's avatar David Trattnig
Browse files

Improved structure.

parent bad54cbd
No related branches found
No related tags found
No related merge requests found
Hide whitespace changes
Inline Side-by-side
Showing
with 35 additions and 33 deletions
docs/engine-features.md
+ 35
− 33
View file @ e5fbb86b
......@@ -11,8 +11,7 @@ This page gives a more detailed overview of the Aura Engine features and how to
- [Stream to Icecast](#stream-to-icecast)
- [Record output to filesystem](#record-output-to-filesystem)
- [Scheduling](#scheduling)
- [Fallback Stages](#fallback-stages)
- [Scheduling Stages](#scheduling-stages)
- [Fallback Handling](#fallback-handling)
- [Pro-active Fallback Handling (1st Level Fallback)](#pro-active-fallback-handling-1st-level-fallback)
- [Fallback Handling using the Silence Detector (2nd Level Fallback)](#fallback-handling-using-the-silence-detector-2nd-level-fallback)
- [API Endpoints](#api-endpoints)
......@@ -44,8 +43,8 @@ The switching between types of audio source is handled automatically. To learn m
### Analog line-out
In most scenarios it might be sufficient to broadcast via only one analog stereo output channel.
If need you can configure up to five stereo pairs.
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
......@@ -61,35 +60,9 @@ be configured to save in a different resolution in audio quality.
## Scheduling
Engine performs scheduling with some handling for extended security, to meet the requirements
of community radios. It tries to pro-actively reacted to scenarios, where the upload of some
pre-recorded show has been forgotten, or some live schedule is not taking place.
Usually in such cases the broadcast might end up with some timeslot filled with silence.
To avoid this, Engine implements multiple levels of fallback handling.
### Fallback Stages
The available fallbacks are evaluated in following order:
1. **Schedule Fallback**: If the show fallback is not assigned, a configured fallback
playlist for the related timeslot is used.
2. **Show Fallback**: If the schedule for some show has no playlist assigned, the
playlist assigned as a *show fallback* is used instead. In the dashboard this can
be done as seen in the screenshot below.
![Setting for the Show Fallback in AURA Dashboard](images/dashboard-fallback-setting.png "Show Fallback in Dashboard")
3. **Station Fallback**: If everything goes wrong, meaning all the previous fallback
playlists are missing or are invalid, the *station fallback* will be triggered. This
fallback type is specified by a playlist ID set in the Engine's configuration
(see `scheduling_station_fallback_id` in `engine.ini`)
### Scheduling Stages
Engine provide a scheduling functionality by polling external API endpoints frequently.
To understand how fallbacks are handled by Engine, it's good to know how the Engine's
scheduling is structured. Below you see a timline with one schedule planned at a certain
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:
```
......@@ -119,7 +92,7 @@ point in time and the involved phase before:
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`).
<u>Pro-active fallback handling</u> by verifying the existence of playlists is already
<u>Pro-active fallback handling</u> by verifying the existence of playlists is already
happening at this stage.
> Important: It's vital that the the scheduling window is wider than the fetching frequency.
......@@ -164,6 +137,35 @@ point in time and the involved phase before:
If for some reason the playout is corrupted, stopped or too silent to make any sense, then
this <u>triggers a 2nd level fallback using the silence detector</u> (see chapter below).
## Fallback Handling
Engine performs scheduling with some additional handling for extended security, to meet the requirements
of community radios. It tries to pro-actively reacted to scenarios, where the upload of some
pre-recorded show has been forgotten, or some live schedule is not taking place.
Usually in such cases the broadcast might end up with some timeslot filled with silence.
To avoid this, Engine implements multiple levels of fallback handling.
To understand how fallbacks are handled by Engine in detail, it's good to know how the Engine's
scheduling is executed. Read more about the scheduling approach in the chapter above.
The available fallbacks are evaluated in following order:
1. **Schedule Fallback**: If the show fallback is not assigned, a configured fallback
playlist for the related timeslot is used.
2. **Show Fallback**: If the schedule for some show has no playlist assigned, the
playlist assigned as a *show fallback* is used instead. In the dashboard this can
be done as seen in the screenshot below.
![Setting for the Show Fallback in AURA Dashboard](images/dashboard-fallback-setting.png "Show Fallback in Dashboard")
3. **Station Fallback**: If everything goes wrong, meaning all the previous fallback
playlists are missing or are invalid, the *station fallback* will be triggered. This
fallback type is specified by a playlist ID set in the Engine's configuration
(see `scheduling_station_fallback_id` in `engine.ini`)
### Pro-active Fallback Handling (1st Level Fallback)
This type of fallback handling is performed before the actual playout, within the scheduling
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment