diff options
Diffstat (limited to 'AudioManagerDaemon/docx/04_components.dox')
| -rw-r--r-- | AudioManagerDaemon/docx/04_components.dox | 105 |
1 files changed, 105 insertions, 0 deletions
diff --git a/AudioManagerDaemon/docx/04_components.dox b/AudioManagerDaemon/docx/04_components.dox new file mode 100644 index 0000000..4735740 --- /dev/null +++ b/AudioManagerDaemon/docx/04_components.dox @@ -0,0 +1,105 @@ + /* + * 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 Mueller (christian.ei.mueller@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 + + \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. + \n + 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. + \n + 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 + \n + 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 + + \page elementspage Elements of the AudioManagement + + The audiomanagement in principle consists of the following elements: + + \section source Sources + This is where audio comes from, for examples tuner, mediaplayer. But sources can also be part of a building block that processes audio, examples + are here crossfaders or gateways. Several Sinks can be connected to one source.\n + \subsection sourceattributes Attributes + - am::am_SourceType_s describes the attributes that are accessible from the AudioManagerCommandPlugins.\n + - am::am_Source_s describes the general attributes.\n + + \section sinks Sinks + This is where audio flows to, for examples amplifier, headphones. But sources can also be part of a building block that processes audio, + examples are here crossfaders or gateways. Several Sources can be connected to one sink.\n + \subsection sinkattributes Attributes + - am::am_SinkType_s describes the attribiutes that are accessible form the AudioManagerCommandPlugins.\n + - am::am_Sink_s describes the general attributes.\n + + \section gw Gateways + Gateways are described here: \ref gateway + A specialitry of a gateways is the convertionmatrix. It indicates which sinksoundformats can be transferred in which sourcesoundformats. A convertion + matrix looks like this: + \image html GatewayMatrix.png + \subsection gwattributes Attributes + - am::am_Gateway_s describe the attribiutes of a gateway\n + + \section crossfaders Crossfaders + Cross-faders are special elements that can perform cross-fading between two sources connected to the sinks of the crossfader. The audio of either source + or both (mixed, during the fade) is put out at the source of the fader. Cross-fading within a source (for example from one song to another) is out of + scope audio management and must be performed in the source.\n + A crossfader has two sinks and one source, where one sink is the "hot" one. It is in the duty of the AudioManagerController to connect the correct + sources to the sinks in order to perform a cross-fade. When fading is started, the hotSink changes from either HS_SINKA or HS_SINKB to HS_INTERMEDIATE, + when the fading is finished, it changes to HS_SINKA or HS_SINKB (the sink that was "cold" before).Fading itself is done in the RoutingAdapters, the + implementation has to ensure the smooth and synchronous change of volumes. With different rampTypes, different kinds of cross-fade ramps can be supported. + The actual status of the "hot" sink is reported by the routingAdapter. Care has to be taken that the correct "hot" end of the crossfader is given + at registration time.\n + \subsection cfattributes Attributes + - am::am_Crossfader_s describes the attribiutes of a Crossfader +*/
\ No newline at end of file |