summaryrefslogtreecommitdiffstats
path: root/thesis
diff options
context:
space:
mode:
Diffstat (limited to 'thesis')
-rw-r--r--thesis/thesis.tex52
1 files changed, 51 insertions, 1 deletions
diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index 0c7c47b..7d752c3 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -244,7 +244,7 @@ parskip=never]{paper}
preferred, due to its ease of reproducability (the sources can be
retrieved, modified and used, free of charge).\\
- Spatial audio rendering software exists for different \glspl{OS}, in
+ Spatial audio rendering software exists for different \glspl{os}, in
several stages of completeness and feature richness, while covered by free
and non-free licenses. The following work will focus on free software, used
in scientific research and artistic contexts. Several spatial audio
@@ -1808,6 +1808,47 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
\subsection{Implemented Features}
\label{subsec:implemented_features}
+ The \gls{osc} interface described in~\ref{subsec:osc-interface} can be
+ seen as a full replacement (with one minor exception, detailed
+ in~\ref{subsubsec:scene_transfer}) for the \gls{ip} interface, already in
+ place. Its additional features are what set it trully apart though, when
+ not only regarding non-reliance on external software to enable \gls{osc}
+ capabilities.\\
+
+ The implementation follows the internal \gls{pubsub} interface, as
+ described in~\ref{subsec:publisher_subscriber_interface} and extends it,
+ where appropriate. Additionally an open client-server architecture has
+ been created, according to a message level system, further elaborated
+ upon in \gls{subsubsec:message_levels}. An attempt at giving extensive
+ examples on the various setup possibilities, that are now possible, is
+ made in \gls{subsubsec:setups}, some of which are still dependant on
+ various missing features (see~\ref{subsec:future_work}).\\
+ The \gls{osc} messaging system is adhering to the aforementioned
+ client-server architecture by distinguishing between client-only,
+ server-only and messages available to clients and servers alike
+ (see~\ref{subsubsec:message_interface}). Examples for different workflows
+ are given in~\ref{subsubsec:workflow_examples} to illustrate simple
+ use-cases.\\
+ This puts the \gls{osc} interface in the unique position of providing a
+ native messaging interface and a flexible architecture. It can be used
+ from single local instances up to large scale networked setups (with the
+ limitations discussed in~\ref{subsubsec:alien_loudspeaker}
+ and~\ref{subsubsec:assigning_in_and_outputs_on_the_fly}).\\
+ While with the \gls{ip} interface, multiple instances are only
+ controllable by using an \gls{osc} capable application or one, that is
+ able to send \gls{xml}-formatted strings over \gls{tcp}/\gls{ip}, the
+ \gls{osc} interface can deal with \textit{n} clients natively, while only
+ one instance has to be controlled using \gls{osc}. The behavior implies,
+ that setups are possible, in which a large collection of different types
+ of renderers can share the same scene, which is particularly useful for
+ e.g.\ auditioning different rendering algorithms over the same system, or
+ rather in the same room.\\
+ Message sending takes place over \gls{udp}, instead of \gls{tcp}, which
+ lowers the complexity of the network topology (\gls{udp} does not perform
+ handshakes for every packet sent, unlike \gls{tcp}) and thus the size of
+ each message sent.\\
+ The \gls{osc} interface therefore implements messaging using lower
+ bandwidth at a greater feature set.
\subsection{Future Work}
\label{subsec:future_work}
@@ -2161,6 +2202,15 @@ ssr-aap -N “server” -C “127.0.0.1:50002”
that could prove to be cheaper, more reliable and flexible, than the
compile-time opt-ins (i.e.\ VRPN, Polhemus Fastrak/ Patriot, InterSense
InertiaCube3).\\
+ In the specific case of setting up a large array of independent
+ \gls{brs} or \gls{bs} renderers, connected to one server instance or
+ application, it might however be needed to extend the messaging system
+ to allow passing on of messages from one client to a server only to one
+ specific other client (a type of proxy messaging). This would ensure,
+ that every renderer can be supplied with a specific stream of \gls{osc}
+ messages from its assigned head tracker. Single (and local) renderers
+ can be started as a server instance and clients can be assigned to it
+ flexibly.
\cleardoublepage
\pagestyle{empty}