diff options
| -rw-r--r-- | thesis/thesis.tex | 107 |
1 files changed, 82 insertions, 25 deletions
diff --git a/thesis/thesis.tex b/thesis/thesis.tex index 4afc5d3..3af48f2 100644 --- a/thesis/thesis.tex +++ b/thesis/thesis.tex @@ -25,6 +25,8 @@ \definecolor{osc-in}{RGB}{0,0,255} \definecolor{audio-in}{RGB}{255,0,0} \definecolor{audio-out}{RGB}{0,206,0} +\definecolor{pubsub-in}{RGB}{128,0,0} +\definecolor{controller-in}{RGB}{0,128,0} \usepackage{hyperref} \hypersetup{hidelinks, colorlinks = false} @@ -33,16 +35,22 @@ % glossary \usepackage[acronym,nonumberlist,toc]{glossaries} +\newacronym{adat}{ADAT}{Alesis Digital Audio Tape} +\newacronym{alsa}{ALSA}{Advanced Linux Sound Architecture} +\newacronym{api}{API}{Application programming interface} \newacronym{asdf}{ASDF}{Audio Scene Description Format} \newacronym{bs}{BS}{Binaural Synthesis} \newacronym{brs}{BRS}{Binaural Room Synthesis} \newacronym{cnmat}{CNMAT}{Center for New Music and Audio Technologies} \newacronym{gpl}{GPL}{GNU General Public License} \newacronym{lgpl}{LGPL}{GNU Lesser General Public License} +\newacronym{lts}{LTS}{Long Term Support} \newacronym{hoa}{HOA}{Higher Order Ambisonics} \newacronym{ip}{IP}{Internet Protocol} \newacronym{jack}{JACK}{JACK Audio Connection Kit} +\newacronym{madi}{MADI}{Multichannel Audio Digital Interface} \newacronym{oop}{OOP}{Object-oriented Programming} +\newacronym{os}{OS}{Operating System} \newacronym{osc}{OSC}{Open Sound Control} \newacronym{posix}{POSIX}{Portable Operating System Interface} \newacronym{pubsub}{PubSub}{Publish-subscribe message pattern} @@ -57,7 +65,8 @@ \makeindex \makeglossaries - +\usepackage{tocloft} +\setcounter{secnumdepth}{4} \graphicspath{{../images//}} @@ -72,7 +81,8 @@ {\huge\bfseries A Networking Extension for the SoundScape Renderer\par} \vspace{2cm} {\Large\itshape David Runge\par} - \href{dave@sleepmap.de}{dave@sleepmap.de} + {\large (340592)}\\ + \href{dave@sleepmap.de}{dave@sleepmap.de}\\ \vfill supervised by\par Henrik von Coler and Stefan Weinzierl @@ -109,6 +119,25 @@ to turn it into a networking application for large scale \gls{wfs} setups. \end{abstract} + \renewcommand{\abstractname}{Zusammenfassung} + \begin{abstract} + \gls{wfs} as a technological concept has been around for + many years now and all over the world several institutions run small and + some even large scale setups ranging from single speaker lines to those + facilitating a couple of hundred loudspeakers respectively.\\ + The still evolving implementations are driven by several rendering + engines, of which two free and open-source ones, namely sWONDER and + SoundScape Renderer, have (partially) been developed at TU Berlin.\\ + The latter due to its current design is not yet able to render for large + scale setups, ie.\ those using several computers to render audio on a + loudspeaker setup, due to the high amount of channels.\\ + Its solid codebase however, which additionally offers a framework for many + more renderering types, and the ongoing development, deems further work on + this application a good future investment.\\ + This work is about the extension of the SoundScape Renderer's functionality + to turn it into a networking application for large scale \gls{wfs} setups. + \end{abstract} + \tableofcontents \cleardoublepage \pagestyle{headings} @@ -221,8 +250,8 @@ available loudspeakers. \cleardoublepage - \section{Methods} - \label{sec:methods} + \section{Implementation} + \label{sec:implementation} The \gls{ssr}, due to its diverse set of rendering engines, which are made available through an extensible framework, and its relatively clean codebase, is a good candidate for future large scale \gls{wfs} setups. These type @@ -264,26 +293,43 @@ needed, be controlled via \gls{osc}. \subsection{Prelimenaries} \label{subsec:preliminaries} - In preparation to the work an implement a side-by-side - installation, using Arch Linux on a medium scale setup, facilitating the - \gls{wfs} system of the Electronic Studio at TU Berlin. Unfortunately the - proprietary Dante driver, that is used in that system is very complex to be - built, as well as underdeveloped and thus keeps the system from being - easily updated, which is needed for testing purposes (finding a suitable - real-time, low-latency Linux kernel), trying out new software features, - building new software and keeping a system safe. The driver will most - likely require changes to the hardware due to implemention of hardware - branding by the vendor and dire testing before usage.\\ - Although eventually using a proper \gls{wfs} setup for testing will be necessary, - it is luckily not needed for implementing the features, as they can already - be worked out using two machines running Linux, \gls{jack} and the development - version of \gls{ssr}.\\ - The hardware of the large scale setup at TU Berlin in H0104 is currently - about to be updated and therefore a valuable candidate for testing of the - sought after \gls{ssr} features. + In preparation to this work, an implemention of a side-by-side + installation to the \gls{os} currently driving the \gls{wfs} system setup + of the Electronic Studio at TU Berlin + \citep{website:tu-electronic_studio} was attempted for testing + purposes.\\ + Arch Linux \citep{website:archlinux} was installed and configured to run + the medium scale setup. Unfortunately the proprietary Dante + \citep{website:audinate} driver for Linux, offered by Four Audio + \citep{website:fouraudio}, creates non-trivial circumstances for using it + on an up-to-date Linux kernel, due to \gls{alsa} \gls{api} changes not + accounted for.\\ + While the current \gls{os} - an Ubuntu \citep{website:ubuntu} Studio + 2012 \gls{lts} - still runs well in its own parameters, its support has run + out and it is therefore becoming harder, if not impossible, to build + newer software on it, using newer versions of free software compilers.\\ + For research purposes however, it is desirable to be able to try new + kernel and software features, finding the most stable and secure setup + possible involving realtime enabled kernels and building new versions of + (spatialisation) software on a regular basis.\\ + The hardware of the large scale setup at TU Berlin in room H0104 was + being updated and unusable at the time of writing. In the future it will + however become a valuable candidate for testing of the sought after + \gls{ssr} features, as its setup involves no Dante network, but is + instead run by several rendering computers connected to \gls{madi} and + \gls{adat} lightpipe enabled speaker systems.\\ + Although a \gls{wfs} setup for testing purposes was eligible, it + generally is not needed for implementing (a subset of) the features + 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} - Initially extending the \gls{ssr}'s features was aimed at + As described in \nameref{sec:implementation}, initially extending the + \gls{ssr}'s features was aimed at in the scope of creating a replacement + for the aging sWONDER software, enabling it to run networked instances to + drive a medium or large scale \gls{wfs} setup.\\ + \subsubsection{Remote controlling a server} \label{subsubsec:remote_controlling_a_server} \subsubsection{Remote controlling clients} @@ -312,6 +358,17 @@ This system enables a versatile messaging layout, in which components can call the publisher functionality in Controller, which in turn will send out messages to all of its subscribers. + \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 Subscribers to Controller (Publisher) + } + \label{fig:ssr-publisher-with-all-subscribers} + \end{figure} \subsection{IP interface} \label{subsec:ip-interface} @@ -360,7 +417,7 @@ SuperCollider \citep{website:supercollider}) since then.\\ \gls{osc}'s syntax is defined by several parts, which are discussed briefly in this section.\\ - /begin{itemize} + \begin{itemize} \item Atomic data types, which are also reflected in type tags (see Table~\ref{tab:ssr-osc-data-type-acronyms} for details) \item Address patterns (a \gls{osc}-string starting with a “/”) @@ -372,7 +429,7 @@ \item Bundles, consisting of a set of Messages. \item Packets, the unit of transmission (sent over \gls{udp} or \gls{tcp}), consisting of a message or a bundle. - /end{itemize} + \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. @@ -870,7 +927,7 @@ Table~\ref{tab:ssr-osc-processing-tracker-transport}, Table~\ref{tab:ssr-osc-scene} and Table~\ref{tab:ssr-osc-source}. } - \label{tab:ssr-osc-source} + \label{tab:ssr-osc-update} \end{table} \cleardoublepage |