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
100
101
102
103
104
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
*/
|
