========================= SoundPlayer - description ========================= Summary ------- **Class:** SoundPlayer **Interdependencies:** None, but requires non-Karabo 'aplay' and 'espeak' sound applications, which may not be bundled with Karabo, and the instantiators account to have 'audio' group access to the host's audio system. **Deployment:** Use the recommended tag **Contact:** C.Youngman or I.Mochasci. **Known failure and recovery modes:** None known, restart device or server is unproblematic. **Synopsis:** The Text-To-Sound 'espeak' application is used to make spoken announcements via the hosts computers sound device, which can be speaker, headset or Bluetooth device. The announcement is preceded by a short pre-recorded attention beep. Announcements are triggered by evaluating conditions based on device state or property values and are repeated if the condition persists. To remain tolerable to the audience sound announcements should need be infrequent and conditions should be defined with this in mind. **Status:** The tag_and_change_log RST details changes made between different tag versions of the application. It also includes a list of improvement suggestions for the next tag version. **Tests:** For live tests use CY_SOUNDPLAYER_TEST project in CAS_TEST User view --------- The sound player overview scene shown below is divided into three vertical slices: top - command buttons and information fields, middle - text scroll console, and bottom - conditions table. Command buttons and fields are: * Mute - stops announcements producing output sound. * Unmute - immediately cancels a on-going mute period. * mute remaining - remaining mute time in seconds, counted down in 10s slices. * Sound test - generates a short announcement output sound, use to test speakers or similar are working. * Reset device - equivalent to restarting the device and useful as a method to replay current true condition announcements. * Repeat time - period after which true condition announcements are repeated. The text scroll region logs sound player activity against time. The scroll region of the figure shows a number of important features. Sound producing announcements are logged with their 'source' identified (startSound, missedDevice, soundTest, or deviceId) followed by a description of the message played and the playing time. For condition true announcements the log message consists of three or four sections: * source - the deviceId of the condition device. * beep - the name of the attention sound. * speech - the first 64 characters of the text message synthesized. * status - optionally, the state of condition device. The condition table lists the configuration used by the sound player. Each row defines a condition to be evaluated by specifying column values: * Device Ids - device ID to be monitored. * Property - property keyword. * Expression - condition expression evaluated, true produces an announcement. * Beep Enable - enable or disables the attention beep. * Beep Sound - name of the beep. * Speech Enable - enable or disable the speech. * Speech Message - text of synthesized speech. * Status Enable - enables or disables deviceId.state synthesis. .. figure:: _images/sound_player_scene.png :align: center :figclass: align-center Fig.: soundPlayer device overview scene. Conditions ---------- Each row of the condition table corresponds to a monitoring coroutine in the sound player device whose task is to evaluate the condition expression defined. A frequently used expression identifies when the state of the deviceId concerned goes to ERROR or UNKNOWN, but the expression can be freely modified to any expression yielding a boolean value with the monitored device exposed with the `dev` alias. Example expressions are: :: dev.state == State.MOVING dev.actualCurrent < 3.14 Useful tips ----------- The sound player device is simple and has a minimum of properties and commands, the default values used probably do not need to be changed. The following tips may be useful: * Not present on the overview scene, but available in the Karabo confgurator panel for the device is a 'Play beeps' command. Use this to associate beep attention names with their sounds. * As mentioned above, the 'reset' command has the same effect as stopping and starting the sound player device. This can be used as a way of playing all condition true and missedDevice messages. * The Karabo convention is that proxies monitored have their state set to UNKNOWN when the proxy device is shutdown. The sound player monitor of a device which has not been instantiated will produce a missedDevice message. The apperance in the scroll log of two different indications that a device is not present can be confusing. * The repeatPeriod cannot be changed in the scene but can be set in the range 60-300s in the device's configurator panel. A side-effect of changing the repeatPeriod is an internally triggered 'reset', which unblocks condition monitors waiting on the previously defined repeatPeriod.