From dace63180cf78c6cd1b4300c7a71701b0ebe3491 Mon Sep 17 00:00:00 2001 From: Mike Brady Date: Tue, 19 Feb 2019 11:18:56 +0000 Subject: [PATCH] Update RELEASENOTES.md --- RELEASENOTES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/RELEASENOTES.md b/RELEASENOTES.md index 0e3928d6..6ce03503 100644 --- a/RELEASENOTES.md +++ b/RELEASENOTES.md @@ -1,7 +1,7 @@ Version 3.3d54 to Version 3.3d40 ==== **New Features** -* Two new external program/script hooks – `run_this_before_entering_active_state` and `run_this_after_exiting_active_state` are provided for when the system becomes active and when it becomes inactive. Background: Many users use the `run_this_before_play_begins` program hook to turn on an amplifier and the `run_this_after_play_ends` hook to turn it off. A big problem is when another play session starts immediately afterwards. This happens, for example, when a YouTube clip ends and the next one begins, and the time interval can be very short. All this switching can stress electronics and speakers. To get around this, the concept of an *active state* covering a sequence of play sessions is introduced. An active state begins when a play session starts. When the play session ends, the system stays in the active state for a period called the `active_state_timeout`, 10 seconds by default. If another play session starts before that timeout elapses, the system remains in the active state; otherwise the system leaves the active state. +* Two new external program/script hooks – `run_this_before_entering_active_state` and `run_this_after_exiting_active_state` are provided for when the system goes active or inactive. Background: Many users use the `run_this_before_play_begins` program hook to turn on an amplifier and the `run_this_after_play_ends` hook to turn it off. A big problem is when another play session starts immediately afterwards. This happens, for example, when a YouTube clip ends and the next one begins, and the time interval can be very short. All this switching can stress electronics and speakers. To get around this, the concept of an *active state* covering a sequence of play sessions is introduced. An active state begins when a play session starts. When the play session ends, the system stays in the active state for a period called the `active_state_timeout`, 10 seconds by default. If another play session starts before that timeout elapses, the system remains in the active state; otherwise the system leaves the active state. * A new `alsa`-only `disable_standby_mode` setting, for controlling the Disable Standby feature, can be set to: `always`, `while_active` or `never`. The `always` setting is recommended for systems where the output device is dedicated to Shairport Sync. The "Disable Standby" state iself can be set or cleared via the D-Bus interface `DisableStandby` property. * A new command-line option, `-u`, directs logging to STDERR rahter than the system log. Useful when you compile Shairport Sync without `libdaemon` using the `--without-libdaemon` configuration option.