summaryrefslogtreecommitdiff
path: root/AudioManagerDaemon/docx/14_misc.dox
diff options
context:
space:
mode:
Diffstat (limited to 'AudioManagerDaemon/docx/14_misc.dox')
-rw-r--r--AudioManagerDaemon/docx/14_misc.dox19
1 files changed, 10 insertions, 9 deletions
diff --git a/AudioManagerDaemon/docx/14_misc.dox b/AudioManagerDaemon/docx/14_misc.dox
index eae0caf..7b3f950 100644
--- a/AudioManagerDaemon/docx/14_misc.dox
+++ b/AudioManagerDaemon/docx/14_misc.dox
@@ -17,21 +17,22 @@
/*!
\page misc Miscellaneous
-\section connfor Connection Formats
+\section misc_connfor Connection Formats
Every flow of audio is using a format to exchange data. The format that the source and the sink uses must match together in order to have an undisturbed
experience. It is common that sources and sinks are capable of supporting more than one audioformat.\n
So all sources and sinks register with a list of connectionFormats that they support and for each connection a format must be chosen that is then used
to transport the audio data. Gateways (and Soundconverters) have the information which connectionFormat can be transformed into another one.
-- am::am_ConnectionFormat_e has all formats listed.
+am::am_ConnectionFormat_e has all formats listed.\n
+There is a special usecase that is worth showing as an example in this regard: the change of a connectionFormat when switching from one song to another. Here is an
+example of how the project specific parts could handle this:
+\image html ChangeofAudioformatduringplaytime.png
-\section pers Persistence & Lifecycle
-Details of persistence can be done when the si-team have defined the components and interfaces in the Enterprise Architect model.
-So much is clear: the persistence will be based on POSIX interfaces that can be used to read and write data.\n
-Persistence is a very system specific topic: what needs to be remembered over lifecycles, what will be reset to default? So this needs to be done via the
-AudioMangerController. The Controller will then enter the values read from the persistence and write them to the daemon.
-The lifecycle itself will be handles by the daemon which will then fire hooks in the controller to make sure appropriate actions are taken.
-\section speed Speed dependent volume
+\section misc_pers Persistence
+The persistence client library is defined as an abstract component with a c-like library interface. Since the AudioManagerController is the only one to know
+what is to be made persistent, he is the one interfacing with that library. This is the reason why there is no specific interface for the persistence here.
+
+\section misc_speed Speed dependent volume
The adjustments for the speed are done product specific in the controller. The speed information itself is retrieved by the AudioManagerDaemon, sampled and
quantified and forwarded to the controller. The interface in not yet defined !\n
Turning speed controlled volume on/off and possible settings are achieved via SinkSoundProperty settings.