T+A Player Switch (TAPSwitch) is released under the terms of the GNU General Public License version 2 or (at your option) any later version. See file COPYING for licensing terms of the GNU General Public License version 2, or COPYING.GPLv3 for licensing terms of the GNU General Public License version 3.
Contact:
T+A elektroakustik GmbH & Co. KG
Planckstrasse 11
32052 Herford
Germany
There are multiple audio players in the Streaming Board system that need exclusive access to the sound device. Depending on the audio source, a specific audio player must be activated so that the source can be played. Since no software mixing (thus on-the-fly format conversion) shall be done, the players need to be told explicitly when they may access the audio device, and when they must release it.
The tapswitch daemon manages switching between players based on audio source. It tells the matching player that it may take the audio device, and tells other players that they may not.
Each audio player must register with tapswitch so that it can be informed when it may take the audio device. An audio player is considered active if it is allowed to take the audio device, inactive otherwise. If tapswitch tells an audio player via D-Bus method invocation to deactivate itself, then the player must release the audio device before the method invocation returns. If tapswitch tells an audio player to activate, then it is allowed (but not required) to use the audio device.
A D-Bus signal is emitted after a player has registered.
Any process may register one or more audio sources with tapswitch. An audio source is associated with a player, forming an audio path from the audio source to the audio player (and thus to the audio device). Multiple audio sources may be associated with the same player. Processes can request tapswitch to activate a player by passing the name of an audio source; then, tapswitch will coordinate players so that the correct one gets activated. The registered audio source is notified with a D-Bus method invocation when its player is ready.
Note that as far as tapswitch is concerned, an audio source is just a concept to introduce an extra level of indirection to the system, decoupling logical audio sources from audio players. This way, processes that would like to activate some audio source do not need to know which audio player is responsible for the audio source in question. To tapswitch, an audio source is simply a string ID with no further meaning.
Before the Streaming Board can play anything, the appliance the Streaming Board is built into may have to set up its audio hardware (waking up from sleep state, switching relays, switch on more appliances, warming up components, anything like that) before any audible sound can be produced. Therefore, an audio player must wait for the appliance to become ready, i.e., its activation must be synchronized to any delays introduced by the appliance.
To achieve this, tapswitch can be informed about the state of the audio hardware via D-Bus commands. As long as the hardware is not ready, it will defer the activation of any audio player. Likely, the hardware state methods will be called by dcpd.