From 8fdf987352fb24636ad24016e5fdef7bec439d96 Mon Sep 17 00:00:00 2001 From: David Trattnig <david@subsquare.at> Date: Fri, 5 Aug 2022 09:29:46 +0200 Subject: [PATCH] style(docs): auto-formatting --- docs/developer-guide.md | 75 ++++++++++++++++++++--------------------- 1 file changed, 37 insertions(+), 38 deletions(-) diff --git a/docs/developer-guide.md b/docs/developer-guide.md index 9b3132fe..cd187cd7 100644 --- a/docs/developer-guide.md +++ b/docs/developer-guide.md @@ -27,7 +27,7 @@ Starting development of engine can be quite tedious, as it requires all most all For example: - Steering, to get the main incredient of an play-out engine: schedules (or "timeslots" in Steering terms), - which hold the actual information on playlists and their entries. + which hold the actual information on playlists and their entries. - Dashboard, to have a neat interface, being able to programme the timeslots - Tank, to get the references to audio files and other audio sources. Plus the actual files. @@ -39,7 +39,7 @@ There's a convenience script to start all of the three main dependencies (Steeri ## Engine Components -*...TBD...* +_...TBD..._ ## Running for Development @@ -65,7 +65,7 @@ Now run the Engine: ~/code/aura/engine$ ./run.sh ``` -If your IDE of choice is *Visual Studio Code*, then there are launch settings provided in `.vscode/launch.json`. +If your IDE of choice is _Visual Studio Code_, then there are launch settings provided in `.vscode/launch.json`. ## Testing @@ -97,53 +97,52 @@ point in time and the involved phase before: ``` - **Scheduling Window**: Within the scheduling window any commands for controlling - the mixer of the soundsystem are prepared and queued. + the mixer of the soundsystem are prepared and queued. - Only until the start of the window, timeslots can be updated 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. + Only until the start of the window, timeslots can be updated 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 timeslot minus - a configured amount of seconds (see `scheduling_window_start` and `scheduling_window_end` - in `engine.ini`). The actual start of the window is calcuated by (timeslot start - window start) - and the end by (timeslot end - window end) + The start and the end of the window is defined by the start of the timeslot minus + a configured amount of seconds (see `scheduling_window_start` and `scheduling_window_end` + in `engine.ini`). The actual start of the window is calcuated by (timeslot start - window start) + and the end by (timeslot end - window end) - During the scheduling window, the external API Endpoints are pulled continuously, to - check for updated timeslots and related playlists. Also, any changes to playlists and - its entries are respected within that window (see `fetching_frequency` in `engine.ini`). + During the scheduling window, the external API Endpoints are pulled continuously, to + check for updated timeslots and related playlists. Also, any changes to playlists and + its entries are respected within that window (see `fetching_frequency` in `engine.ini`). - > Important: It is 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. + > Important: It is 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. - > Note: If you delete any existing timeslot in Dashboard/Steering this is only reflected in Engine until the start - of the scheduling window. The scheduling window is defined by the start of the timeslot minus a configured offset - in seconds. This is limitation is required to avoid corrupted playout in case audio content has been - preloaded or started playing already. + > Note: If you delete any existing timeslot in Dashboard/Steering this is only reflected in Engine until the start + > of the scheduling window. The scheduling window is defined by the start of the timeslot minus a configured offset + > in seconds. This is limitation is required to avoid corrupted playout in case audio content has been + > preloaded or started playing already. - **Queuing and Pre-Loading**: Before any playlist entries of the timeslot 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_offset`in `engine.ini`). + 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_offset`in `engine.ini`). - If there is not enough time to reserve the given amount of time for preloading (i.e. some entry - should have started in the past already) the offset is ignored and the entry is played as soon as possible. + If there is not enough time to reserve the given amount of time for preloading (i.e. some entry + should have started in the past already) the offset is ignored and the entry is played as soon as possible. - > Important: To ensure proper timings, the offset should not exceed the time between the start of - the scheduling-window and the start of the actual timeslot playout. Practically, of course there - are scenario where playout start later than planned e.g. during startup of the engine during a timeslot - or due to some severe connectivity issues to some external stream. + > Important: To ensure proper timings, the offset should not exceed the time between the start of + > the scheduling-window and the start of the actual timeslot playout. Practically, of course there + > are scenario where playout start later than planned e.g. during startup of the engine during a timeslot + > or due to some severe connectivity issues to some external stream. - **Play-out**: Finally the actual play-out is happening. The faders of the virtual mixers are pushed - all the way up, as soon it is "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 timeslot 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 <u>triggers a fallback using the silence detector</u>. + all the way up, as soon it is "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 timeslot 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 <u>triggers a fallback using the silence detector</u>. ## Docker -- GitLab