diff options
| -rw-r--r-- | thesis/thesis.tex | 116 |
1 files changed, 98 insertions, 18 deletions
diff --git a/thesis/thesis.tex b/thesis/thesis.tex index b2adedd..cd02e1f 100644 --- a/thesis/thesis.tex +++ b/thesis/thesis.tex @@ -39,7 +39,7 @@ parskip=never]{paper} \usepackage[authoryear]{natbib} % glossary -\usepackage[acronym,nonumberlist,toc]{glossaries} +\usepackage[acronym,nonumberlist,toc,xindy]{glossaries} \newacronym{aap}{AAP}{Ambisonics Amplitude Panning} \newacronym{adat}{ADAT}{Alesis Digital Audio Tape} \newacronym{alsa}{ALSA}{Advanced Linux Sound Architecture} @@ -74,7 +74,12 @@ parskip=never]{paper} \newacronym{vbap}{VBAP}{Vector Based Amplitude Panning} \newacronym{wfs}{WFS}{Wave Field Synthesis} \newacronym{xml}{XML}{Extensible Markup Language} -\makeindex +\newglossaryentry{sclang}{ + name={sclang}, + description={Name of the SuperCollider programming language and the + interpreter executable of the SuperCollider programming language} +} + \makeglossaries \graphicspath{{../images//}} @@ -176,6 +181,7 @@ parskip=never]{paper} \pagestyle{empty} { + \setcounter{tocdepth}{4} \renewcommand{\thispagestyle}[1]{} \tableofcontents \newpage @@ -268,8 +274,8 @@ parskip=never]{paper} to each node, WFSCollider usually uses the audio files to be played on all machines simultaneously and synchronizes between them.\\ It has a feature-rich \gls{gui} in the \textit{many window} style, making available - time lines and movement of sources through facilitating what the sclang - (SuperCollider programming language) has to offer.\\ + time lines and movement of sources through facilitating what the + \gls{sclang} has to offer.\\ As WFSCollider basically is SuperCollider plus extra features, it is also an \gls{osc} enabled application and can thus also be used for mere multi-channel playback of audio.\\ @@ -373,6 +379,7 @@ parskip=never]{paper} renderers, will not be problematic, as master and nodes can communicate through their builtin TCP/IP sockets directly and the master can, if needed, be controlled via \gls{osc}. + \subsection{Prelimenaries} \label{subsec:preliminaries} In preparation to this work, an implemention of a side-by-side @@ -405,6 +412,7 @@ parskip=never]{paper} described in \nameref{sec:implementation}, as they can be tested using two machines running Linux, \gls{jack} and a development version of the \gls{ssr}.\\ + \subsection{Outline} \label{subsec:outline} As described in \nameref{sec:implementation}, initially extending the @@ -414,10 +422,13 @@ parskip=never]{paper} \subsubsection{Remote controlling a server} \label{subsubsec:remote_controlling_a_server} + \subsubsection{Remote controlling clients} \label{subsubsec:remote_controlling_a_client} + \subsubsection{Rendering on dedicated speakers} \label{subsubsec:rendering_on_dedicated_speakers} + \subsection{Publisher/Subscriber interface} \label{subsec:publisher_subscriber_interface} The \gls{ssr} internally uses a \gls{pubsub}, which is a design pattern, @@ -431,18 +442,20 @@ parskip=never]{paper} The \gls{ssr} implements a content-based filtering system, in which each subscriber evaluates the messages received and acts depending on its own constraints to implement further actions upon it.\\ + \begin{figure}[!htb] \centering - \includegraphics[scale=0.6, trim = 6mm 91mm 12mm 10mm, clip] - {ssr-publisher-with-all-subscribers.pdf} + \includegraphics[scale=0.6, trim = 6mm 130mm 12mm 4mm, clip] + {ssr-publisher-with-legacy-subscribers.pdf} \caption{A diagram depicting a simplified version of the \gls{pubsub} used within the \gls{ssr}.\\ {\color{pubsub-in}\textbf{--}} Calls from Publisher to Subscriber {\color{controller-in}\textbf{--}} Calls from Subscribers to Controller (Publisher) } - \label{fig:ssr-publisher-with-all-subscribers} + \label{fig:ssr-publisher-with-legacy-subscribers} \end{figure} + The abstract class Publisher defines the messages possible to send and provides means to subscribe to them. The global Controller class is its only implementation within the \gls{ssr}.\\ @@ -454,7 +467,7 @@ parskip=never]{paper} out messages to all of its subscribers.\\ Depending on the design of an application, \gls{pubsub} is not necesarily a one-way-road. As showin in - Figure~\ref{fig:ssr-publisher-with-all-subscribers}, subscribers can also + Figure~\ref{fig:ssr-publisher-with-legacy-subscribers}, subscribers can also be able to call functions of the Publisher, if the implementation permits it.\\ In the \gls{ssr} this is possible, because each Subscriber holds a @@ -462,7 +475,7 @@ parskip=never]{paper} public functions.\\ According to the principle of encapsulation in \gls{oop}, this type of functionality is handled by a separate class. In - Figure~\ref{fig:ssr-publisher-with-all-subscribers}, the OscHandler and + Figure~\ref{fig:ssr-publisher-with-legacy-subscribers}, the OscHandler and Server instances delegate calls to Controller functionality to their utilities OscReceiver and CommandParser (respectively). @@ -497,10 +510,68 @@ parskip=never]{paper} its subscribers, too.\\ \cleardoublepage - \section{Results} - \label{sec:results} + \subsection{Open Sound Control interface} \label{subsec:osc-interface} + The networking interface conceived in the course of this work was + developed in several branches, using the git version control system + (written by Linus Torvalds, now maintained by Junio + Hamano\footnote{\href{https://git-scm.com}{https://git-scm.com}}), + publicly on Github\footnote{\href{https://github.com/dvzrv/ssr} + {https://github.com/dvzrv/ssr}}. Internally the liblo library (further + explained in~\ref{subsubsec:liblo}) was harnessed to implement \gls{osc} + functionality (see~\ref{subsubsec:open-sound-control}) for the + \gls{ssr}.\\ + After initial conversations with the current maintainer Matthias Geier + through the project's Github issue + tracker\footnote{ \href{https://github.com/soundscaperenderer/ssr} + {https://github.com/soundscaperenderer/ssr}}, different ideas were worked + out to achieve a broad solution to the server-client and client-only + setups and get a better understanding of the underlying design. Initial + attempts, such as the mapping of a networking setup in the scene + description\footnote{ + \href{https://github.com/dvzrv/ssr/tree/distributed\_reproduction} + {https://github.com/dvzrv/ssr/tree/distributed\_reproduction}} + proved too restrictive though, as it would allow the networking + functionality only to renderers, that use loudspeakers and mix scene + description with networking description.\\ + A nearly configuration-less approach, based on subscribing clients on + sending poll messages to them proved more open (in the sense that it can + be interfaced with by any \gls{osc}-capable application or programming + language) and have less configuration overhead.\\ + + \begin{figure}[!htb] + \centering + \includegraphics[scale=0.6, trim = 6mm 91mm 12mm 10mm, clip] + {ssr-publisher-with-all-subscribers.pdf} + \caption{A diagram depicting a simplified version of the \gls{pubsub} + used within the \gls{ssr}.\\ + {\color{pubsub-in}\textbf{--}} Calls from Publisher to Subscriber + {\color{controller-in}\textbf{--}} Calls from Subscribers to + Controller (Publisher) + } + \label{fig:ssr-publisher-with-all-subscribers} + \end{figure} + + The main implementations of the interface, further described in the + following subsections, can be found in the classes OscHandler (handling + the \gls{osc} server), OscReceiver (handling incoming \gls{osc} + messages and acting upon them in the context of the \gls{ssr} instance) + and OscSender (responsible for reacting to calls from the + \textbf{\nameref{subsec:publisher_subscriber_interface}} and sending of + \gls{osc} messages to clients and server).\\ + As shown in Figure~\ref{fig:ssr-publisher-with-all-subscribers}, the + OscSender is another implementation of the Subscriber interface. This + way, every call made through the Publisher (i.e.\ the Controller), will + be made on the corresponding function in OscSender as well. + With OscReceiver the \gls{osc} interface has direct access to the + Controller and can make calls to it, on receiving a message. + In its implementation approach the \gls{osc} interface therefore follows + that of the \textbf{\nameref{subsec:ip-interface}}, expanding however in + creating a client-server architecture, controlled by + \textbf{\nameref{subsubsec:message_levels}}, using a unified + \textbf{\nameref{subsubsec:message_interface}}. + \subsubsection{Open Sound Control} \label{subsubsec:open-sound-control} \gls{osc} is an “open, transport-independent, message-based protocol @@ -515,6 +586,7 @@ parskip=never]{paper} SuperCollider \citep{website:supercollider}) since then.\\ \gls{osc}'s syntax is defined by several parts, which are discussed briefly in this section.\\ + \begin{itemize} \item Atomic data types, which are also reflected in type tags (see Table~\ref{tab:ssr-osc-data-type-acronyms} for details) @@ -528,6 +600,7 @@ parskip=never]{paper} \item Packets, the unit of transmission (sent over \gls{udp} or \gls{tcp}), consisting of a message or a bundle. \end{itemize} + According to the specification, applications sending \gls{osc} packets are considered a client and the ones receiving packets a server. Applications can therefore be client and server at the same time.\\ @@ -1251,8 +1324,8 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \label{subsubsec:workflow_examples} Using any \gls{osc} capable programming language or application enables for communication with the \gls{ssr}. The following examples illustrate - simple workflows using sclang (the SuperCollider programming language) - and should therefore be \gls{os} agnostic.\\ + simple workflows using \gls{sclang} and should therefore be \gls{os} + agnostic.\\ \paragraph{Controlling a server} \label{para:controlling_a_server} @@ -1262,7 +1335,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \inputminted[numbers=left, firstline=3, lastline=29, fontsize=\footnotesize]{supercollider}{../../ssr/supercollider/workflows.scd} \end{mdframed} - \caption{supercollider/workflows.scd: sclang as client + \caption{supercollider/workflows.scd: \gls{sclang} as client controlling a \gls{ssr} server instance} \label{lst:ssr-workflow-sclang-controls-server} \end{listing}\\ @@ -1285,7 +1358,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \inputminted[numbers=left, firstline=31, lastline=61, fontsize=\footnotesize]{supercollider}{../../ssr/supercollider/workflows.scd} \end{mdframed} - \caption{supercollider/workflows.scd: sclang mimics server, + \caption{supercollider/workflows.scd: \gls{sclang} mimics server, controlling a \gls{ssr} client instance} \label{lst:ssr-workflow-sclang-is-server-controls-client} \end{listing}\\ @@ -1304,11 +1377,18 @@ ssr-aap -N “server” -C “127.0.0.1:50002” to \textit{GUI\_SERVER}), to receive \gls{gui} relevant messages, as explained in \nameref{subsubsec:message_interface}.\\ - \cleardoublepage + \subsection{Automated tests} + \label{subsec:automated_tests} + To probe the \gls{osc} interface's robustness automatically, a set of + tests were written (as there exists no test framework for the \gls{ssr} + itself) in \gls{sclang}, to use all of the available messages (especially when + they should not be allowed - in the case of not being a subscribed client + or a setup server). + + + \cleardoublepage \section{Discussion} \label{sec:discussion} - \subsection{Stress testing the \gls{osc} interface} - \label{subsec:stress_testing_the_osc_interface} \cleardoublepage \subsection{Implementing a NullRenderer} \label{subsec:implementing_a_nullrenderer} |