summaryrefslogtreecommitdiff
path: root/AudioManagerDaemon/docx/04_components.dox
blob: 7c8f9b4bc56a2b27ae8f50d5ac31e38e6021ba34 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
 /*
 * Copyright (C) 2012, BMW AG
 *
 * This file is part of GENIVI Project AudioManager.
 *
 * Contributions are licensed to the GENIVI Alliance under one or more
 * Contribution License Agreements.
 *
 * \copyright
 * This Source Code Form is subject to the terms of the
 * Mozilla Public License, v. 2.0. If a  copy of the MPL was not distributed with
 * this file, You can obtain one at http://mozilla.org/MPL/2.0/.
 *
 * \\author Christian Linke (christian.linke@bmw.de)
 *
 */
 
 /*!
 \page audiomanagercomponentspage AudioManager Components
 \image html AudioManagement.png

 The AudioManager is the central managing instance of the Audio architecture. It is designed as an OwnedComponent, this means that the
 software is maintained within GENIVI as open source component. The AudioManager consists of 4 central components.\n


 \section audiomanagercomponents AudioManagerDaemon

 This component is owned and maintained by Genivi. It is the central audio framework component. There can be only one daemon in a system (singleton).\n
 The AudioManagerDaemon is subject to this documentation.
 \subsection daemonover Daemon Overview
 Here is an class overview of the AudioManagerDaemon:
 \image html daemon_insight.png

 \section commander AudioManagerCommandPlugin

 This describes the interface towards the Commanding Instances of the AudioManagerDaemon. This is the HMI and interrupt sources that use this
 interface to start their interrupt and stop it again. The interface shall be asynchronous. Via this interface all user interactions are handled.
 This component is designed to be a dynamic linked library that will be loaded on the startup of the AudioManager. There can be more than one
 CommandPlugin at a time.
 Since the implementation of this component is project specific, only examples are included.\n
 An example Dbus Implementation can be found in the folder PluginCommandInterfaceDbus.

 \subsection commandIface Interfaces
 All commands that must be fulfilled by an AudioManagerCommandPlugin are described in am::IAmCommandSend.\n
 All commands that are presented to AudioManagerCommandPlugin by the AudioManagerDaemon are described in am::IAmCommandReceive.\n

 \section controller AudioManagerController
 The controller is the intelligent "heart" of the AudioManager and it is project specific. In principle, the controller gets commands from the command
 interface or events from outside and reacts to them. For this purpose, some basic commands are in the "toolbox" of the Controller that he can use
 to interact with the rest of the system.\n
 Among this there are commands to read/write the database and to perform actions on the Audiodomains like connect or disconnect. There must be only one
 Controller in the system at a time, like the AudioManagerCommandPlugins, the Controller is loaded at startup by the daemon\n
 A simple example Implementation can be found in the folder PluginControlInterface.

 \subsection controlIface Interfaces
 All commands that must be fulfilled by an AudioManagerController are described in am::IAmControlSend.\n
 All commands that are presented to AudioManagerController by the AudioManagerDaemon are described in am::IAmControlReceive.\n

 \section router Routing AudioManagerRoutingPlugin

 The AudioManagerRoutingPlugins are used to abstract the actual Hard- and Software that does the routing. There can be more than one plugins at a
 time, they are loaded at startup time like the commandplugins. \n
 The AudioManager expects a bus-like structure behind each plug-in, so that a plug-in can implement a bus interface and proxy the messages to the
 routing adapters - the AudioManager is capable of addressing more than one adapter one each plug-in. The AudioManagerController does not have to
 know anything about the real system plugins - he sends his commands to sources and sinks. The daemon does the dispatching of these commands.
 The interface is mainly asynchronous.\
 Sample plugins can be found in the directory, for example PluginRoutingInterfaceAsync.\n

 \subsection routingIface Interfaces
 All commands that must be fulfilled by an AudioManagerRoutingPlugin are described in am::IAmRoutingSend.\n
 All commands that are presented to AudioManagerRoutingPlugins by the AudioManagerDaemon are described in am::IAmRoutingReceive.\n

 \subsection subrouter Bus topology
 The AudioManagerDaemon expects a bus behind each of the plugins. On one of these buses there can be several domains. In order to
 reflect this, a domain has always a bus(plugin) and a node that it belongs to. So if a message needs to be transmitted to a domain,
 it will always be sent to a node on a bus.
 Here is a diagram showing the topology from the view of the AudioManagerDaemon:
 \image html bus_topology.png
 \subsection busname Busname
 Since a plugin represents a bus for the AudioManagerDaemon, each plugin it has its unique name, the busname that is returned by
 am::IAmRoutingSend::returnBusName. The AudioManagerDaemon used this information to link a plugin with a domain. All other elements like
 sinks, sources etc are linked to domains. This is how the hierarchy looks like that is used:
 \image html routing_hierarchy.png
 
 \subsection CAPIplugins CommonAPI plugins
 As "sample code" with MIT license, PluginCommandInterfaceCAPI and PluginRoutingInterfaceCAPI are provided with the source code. The FRANCA 
 fidls have been generated out of the Enterprise architect model, so they might be used to draw project specific behavior in sequences.
 The sources in src-gen have been generated out of the provided fidl files.
 
 \image html PluginCommandInterfaceCAPI.png
 
 \image html PluginRoutingInterfaceCAPI.png
 
 There is no fixed domain associated with this plugin. So you have to implement the interface org::genivi::am::RoutingControlStub and report
 busname and path to the routingplugin on the interface org::genivi::am::RoutingControlObserverStub like this:
 
 \image html Register_Domain.png

*/