diff options
Diffstat (limited to 'thesis')
| -rw-r--r-- | thesis/thesis.tex | 52 |
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} |