summaryrefslogtreecommitdiff
path: root/AudioManagerDaemon/docx/05_unique.dox
diff options
context:
space:
mode:
authorchristian mueller <christian.ei.mueller@bmw.de>2012-03-07 10:15:47 +0100
committerchristian mueller <christian.ei.mueller@bmw.de>2012-03-07 10:15:47 +0100
commit62773dc7e9076d57764f3e823366697eb8a19060 (patch)
treeae7fca7c0e8f44d18fc4f9da11b8b0a5557e3bfe /AudioManagerDaemon/docx/05_unique.dox
parentf23f9c3ecf40636f176107f6098c308f72fdbd5d (diff)
downloadaudiomanager-62773dc7e9076d57764f3e823366697eb8a19060.tar.gz
* forgot to check in the documentation
Diffstat (limited to 'AudioManagerDaemon/docx/05_unique.dox')
-rw-r--r--AudioManagerDaemon/docx/05_unique.dox37
1 files changed, 37 insertions, 0 deletions
diff --git a/AudioManagerDaemon/docx/05_unique.dox b/AudioManagerDaemon/docx/05_unique.dox
new file mode 100644
index 0000000..0dc249b
--- /dev/null
+++ b/AudioManagerDaemon/docx/05_unique.dox
@@ -0,0 +1,37 @@
+ /*
+ * 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 uniquepage About unique IDs : Static vs Dynamic IDs
+
+ \section why Why having two different kinds of ids?\n
+ The complexity of up-to-date IVI-systems demand to support sources and sinks dynamically added and removed in order to support the variety of CE products,
+ but parts of the system are never going to change - to start a dynamic registration here is a waste of system capacity.\n
+ \section setup The setup
+ The AudioManagement is capable of handling static, dynamic or mixed setups. In case of a dynamic setup, all elements of the system like domains, sinks,
+ sources, gateways etc are registered at system start-up. In a static setup, the IDs of the elements are known and fixed - no further registration is needed.
+ The start-up for static elements works as follows:\n
+ when a domain known as static (this is knowledge of the AudioManagerController, recognized by the unique name of the domain) registers, the
+ AudioManagerController enters all elements of this domain in the database. Still, this domain can register additional elements during runtime.
+ In case of static setups, the RoutingAdapter needs to ensure that all static elements are ready to be used when the domain registers.\n
+ In order to ensure the uniqueness of IDs, there exist two separate ID areas (for each of sources, sinks, gateways and crossfaders):\n\n
+ Fixed area (from 1..100)\n
+ Variable area (starting from 101)\n\n
+ In case of dynamic added elements, the audiomanagerdaemon ensures the uniqueness of the ID's, in case of the static setup, the project has to ensure the
+ uniqueness by assigning the IDs wisely. The knowledge of the static IDs need to be in the AudioManagerController, the RoutingAdapters and in the HMI
+ (optional because IDs will be reported anyway).\n
+ Domains cannot be static because registering them is the trigger for the AudioManagerController to enter the static values into the database.
+*/ \ No newline at end of file