AuPaD 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
AuPaD maintains current information about audio paths in the appliance the Streaming Board is built into. The appliance may update information about audio signal routing and parameters of elements the audio signal passes according to its internal system knowledge, and external programs may read out these information for their purposes.
After startup, AuPaD assumes nothing about the appliance or its signal paths. No guesswork is done here.
Initial audio path information are queried by AuPaD from the SPI slave by sending an according D-Bus request to dcpd, which will forward the request to the appliance via register 82. The appliance will (hopefully) react and send all audio path information in its entirety using the mechanism described below.
The SPI slave sends its audio path information to dcpd via register 82 using a simple description language (AuPaL, Audio Path Language), and dcpd turns fragments of audio path changes into equivalent JSON objects. These JSON objects are emitted as D-Bus signals. AuPaD connects to dcpd and waits for any JSON objects to be processed.
External programs may want to change audio paths or parameters (such as equalizer settings). Requests for such changes can be sent directly to AuPaD via D-Bus, which will sanitize the request and forward it to dcpd for processing by the SPI slave via register 82. dcpd turns the requests into compact AuPaL specifications so that the SPI slave doesn't have to deal with JSON.
Successful changes are reported back via the regular update mechanism.
There are D-Bus objects with predefined filtered views on the audio paths. These objects are monitor objects which are connected to AuPaD's internal filter plugins. External programs need to register themselves on a monitor object in order to receive audio path change information. AuPaD will send filtered information about changes via D-Bus signals as long as there is at least one client registered.
On any audio path changes, AuPaD emits D-Bus signals on each monitor object with at least one registered client. These signals contain JSON objects describing the changes.
External programs may request full audio path information via D-Bus method call on monitor objects. They will typically do this after successful registration with the corresponding object. Since these information may not be available the instant they are requested (especially during system initialization), clients are strongly advised to make their D-Bus call asynchronous.
The D-Bus call will fail immediately in case there is no audio path information available. In this case, the client shall not repeat its request, but instead wait for a D-Bus signal containing full information sent to all registered clients.
Clients shall ignore any audio path updates received via D-Bus signals before initialization. It is guaranteed that any change information sent before returning full information will be incorporated in the full information returned by the initialization method call.
External programs may send JSON objects containing partial or full audio path specifications via D-Bus method call. The appliance should update its internal settings accordingly. When done, the appliance reports its changes back to the Streaming Board, and AuPaD distributes the change information as described above.
Change reports must be viewed in disconnect from change request. Programs that send change requests must never assume any specific outcome of their requests; change requests may be ignored, fully or partially, and for various reasons. All that a client can do is hope for the best and react to changes reported back from the system.