From 5dfabcd0effd31e25dd72e10329f775096a41c0b Mon Sep 17 00:00:00 2001
From: David Runge <dave@sleepmap.de>
Date: Wed, 7 Jun 2017 13:49:30 +0200
Subject: thesis/thesis.tex: Adding extended titlepage. Adding tableofcontents.
 Adding section stubs. Adding statutory declaration. Fixing line wraps.
 Setting images location to global images location.

---
 thesis/thesis.tex | 246 +++++++++++++++++++++++++++---------------------------
 1 file changed, 121 insertions(+), 125 deletions(-)

(limited to 'thesis/thesis.tex')

diff --git a/thesis/thesis.tex b/thesis/thesis.tex
index b1d78b8..ea4414a 100644
--- a/thesis/thesis.tex
+++ b/thesis/thesis.tex
@@ -22,22 +22,43 @@
 \floatstyle{boxed}
 \restylefloat{figure}
 \usepackage{color}
-\usepackage{bbding}
+%\usepackage{bbding}
 \usepackage{hyperref}
 \usepackage[font=scriptsize]{caption}
 \usepackage[numbers]{natbib}
-\graphicspath{{images//}}
+\graphicspath{{../images//}}
+\renewcommand\thesection{\arabic{section}}
+\makeindex
 
 \begin{document}
-  \title{Master Thesis: SoundScape Renderer Networking}
-  \author{David Runge\\
-    Audiokommunikation und -technologie\\
-    Fachgebiet Audiokommunikation\\
-    Technische Universität Berlin\\
+  \begin{titlepage}
+    \centering
+    \includegraphics[width=0.3\textwidth]{tu-berlin-logo.pdf}\par\vspace{1cm}
+    {\scshape\LARGE Technische Universität Berlin\par}
+    \vspace{1cm}
+    {\scshape\Large Master Thesis\par}
+    \vspace{1.5cm}
+    {\huge\bfseries A Networking Extension for the SoundScape Renderer\par}
+    \vspace{2cm}
+    {\Large\itshape David Runge\par}
     \href{dave@sleepmap.de}{dave@sleepmap.de}
-  }
-  \date{\today}
-  \maketitle
+    \vfill
+    supervised by\par
+    Henrik von Coler and Stefan Weinzierl
+    \vfill
+    {\large \today\par}
+  \end{titlepage}
+
+  \section*{Eidesstattliche Erklärung}
+  \vspace{1cm}
+  Hiermit erkläre ich, dass ich die vorliegende Arbeit selbstständig und
+  eigenhändig sowie ohne unerlaubte fremde Hilfe und ausschließlich unter
+  Verwendung der aufgeführten Quellen und Hilfsmittel angefertigt habe.\\
+  Berlin, den \today\par\\
+  \vspace{2cm}
+  \noindent\ldots\ldots\ldots\ldots\ldots\ldots\ldots\ldots\ldots\ldots\ldots\\
+  David Runge
+
   \begin{abstract}
     Wave Field Synthesis (WFS) as a technological concept has been around for
     many years now and all over the world several institutions run small and
@@ -54,12 +75,17 @@
     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 WFS setups.
-\end{abstract}
-  \section{Introduction}
-    Wave Field Synthesis (WFS) describes a spatial technique for rendering audio. As
-    such it aims at synthesizing a sound field of desired acoustic preference
-    in a given listening area, assuming a planar reproduction to be most
-    suitable for most applications.\\
+  \end{abstract}
+
+  \setcounter{tocdepth}{3}
+  \tableofcontents
+  \pagebreak
+
+  \section*{Introduction}
+    Wave Field Synthesis (WFS) describes a spatial technique for rendering
+    audio. As such it aims at synthesizing a sound field of desired acoustic
+    preference in a given listening area, assuming a planar reproduction to be
+    most suitable for most applications.\\
     WFS is typically implemented using a curved or linear loudspeaker array
     surrounding the listening area.\\
     Several free and open-source renderer applications exist for WFS
@@ -67,32 +93,40 @@
     The proposed work will focus on one of them and its extension towards WFS
     on large scale systems.
 
-  \section{Free and open-source wave field synthesis renderers}
-    To date there exist three (known of) free and open-source Wave Field
-    Synthesis renderers, which are all \href{http://jackaudio.org/}{JACK Audio
-    Connection Kit (JACK)} \citep{website:jackaudio2016} clients: 
+  \section{Spatial audio renderers and their appliance}
+    \subsection{Wave Field Synthesis}
+    \subsection{Higher Order Ambisonics and Vector Amplitude Panning}
+    \subsection{Binaural synthesis}
+
+  \section{Free and open-source spatial audio renderers}
+    To date there exist three (known of) free and open-source spatial audio
+    renderers, which are all \href{http://jackaudio.org/}{JACK Audio Connection
+    Kit (JACK)} \citep{website:jackaudio2016} clients: 
     \begin{itemize}
-      \item \href{https://sourceforge.net/projects/swonder/}{sWONDER} \citep{website:swonder2016},
-      developed by Technische Universität Berlin, Germany 
-      \item \href{https://github.com/GameOfLife/WFSCollider}{WFSCollider} \citep{website:wfscollider2016},
-        developed by \href{http://gameoflife.nl/en}{Game Of Life Foundation} \citep{website:gameoflife2016},
-        The Hague, Netherlands
-      \item \href{http://spatialaudio.net/ssr/}{SoundScape Renderer (SSR)} \citep{website:ssr2016},
-        developed by Quality \& Usability Lab, Deutsche Telekom Laboratories
-        and TU Berlin and Institut für Nachrichtentechnik, Universität Rostock 
+      \item \href{https://sourceforge.net/projects/swonder/}{sWONDER}
+        \citep{website:swonder2016}, developed by Technische Universität
+        Berlin, Germany 
+      \item \href{https://github.com/GameOfLife/WFSCollider}{WFSCollider}
+        \citep{website:wfscollider2016}, developed by
+        \href{http://gameoflife.nl/en}{Game Of Life Foundation}
+        \citep{website:gameoflife2016}, The Hague, Netherlands
+      \item \href{http://spatialaudio.net/ssr/}{SoundScape Renderer (SSR)}
+        \citep{website:ssr2016}, developed by Quality \& Usability Lab,
+        Deutsche Telekom Laboratories and TU Berlin and Institut für
+        Nachrichtentechnik, Universität Rostock 
     \end{itemize}
     Currently only WFSCollider and the SSR are actively maintained and
-    developed, thussWONDER, although used in some setups, loses significance.
+    developed, thus sWONDER, although used in some setups, loses significance.
     Generally it can be said, that different concepts apply to the three
     renderers, which are about to be explained briefly in the following
     sections.
 
     \subsection{WONDER}
-      sWONDER \citep{baalman2007} consists of a set of C++ applications that provide binaural and
-      WFS rendering. In 2007 it was specifically redesigned
-      \citep{baalmanetal2007} to cope with large scale WFS setups in which
-      several (computer) nodes, providing several speakers each, drive a system
-      together.\\
+      sWONDER \citep{baalman2007} consists of a set of C++ applications that
+      provide binaural and WFS rendering. In 2007 it was specifically
+      redesigned \citep{baalmanetal2007} to cope with large scale WFS setups in
+      which several (computer) nodes, providing several speakers each, drive a
+      system together.\\
       In these setups each node receives all available audio streams (which
       represent one virtual audio source respectively) redundantly and a master
       application signals which node is responsible for rendering what source
@@ -104,12 +138,13 @@
       has a complex setup chain and many bugs, that are not likely to get fixed
       any time soon.
 
+    \subsection{HOA-Pd}
     \subsection{WFSCollider}
       WFSCollider was built on top of
       \href{https://supercollider.github.io}{SuperCollider} 3.5
       \citep{website:supercollider2016} and is also capable of driving large
       scale systems. It uses a different approach in
-      doing so, though: Whereas withsWONDER all audio streams are distributed
+      doing so, though: Whereas with sWONDER all audio streams are distributed
       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 GUI in the ``many window'' style, making available
@@ -131,8 +166,8 @@
       It can be used with a GUI or headless (without one), depicting the
       virtual sources, their volumes and positions, alongside which speakers
       are currently used for rendering a selected source.
-      SSR uses TCP/IP sockets for communication and thus is not directly OSC
-      enabled. This functionality can be achieved using the capapilities of
+      SSR uses TCP/IP sockets for communication and is therefore not directly
+      OSC enabled. This functionality can be achieved using the capapilities of
       other applications such as \href{http://puredata.info}{PureData}
       \citep{website:puredata2016} in combination with it though.\\
       Unlike the two renderers above, the SSR is not able to run large-scale
@@ -142,9 +177,9 @@
 
   \section{Extending Sound Scape Renderer functionality}
     The SSR, due to its diverse set of rendering engines, which are made
-    available through an extensible framework, and its clean codebase, is a
-    good candidate for future large scale WFS setups. These type of features
-    are not yet implemented though and will need testing.\\
+    available through an extensible framework, and its relatively clean
+    codebase, is a good candidate for future large scale WFS setups. These type
+    of features are not yet implemented though and will need testing.\\
     Therefore I propose the implementation and testing of said feature, making
     the SSR capable of rendering on large scale WFS setups with many nodes,
     controlled by a master instance.\\
@@ -155,12 +190,13 @@
     one of the several rendering engines.
     \begin{figure}[!htb]
       \centering
-      \includegraphics[scale=0.9, trim = 31mm 190mm 24mm 8mm, clip]{ssr-networking.pdf}
+      \includegraphics[scale=0.9, trim = 31mm 190mm 24mm 8mm, clip]
+      {ssr-networking.pdf}
       \caption{A diagram displaying the SSR master/node setup with TCP/IP
-        socket connections over network (green lines), audio channels (red dashed
-        lines) and OSC connection (blue dashed line). Machines are indicated as red
-        dashed rectangles and connections to audio hardware as outputs of SSR
-        nodes as black lines below them.} 
+        socket connections over network (green lines), audio channels (red
+          dashed lines) and OSC connection (blue dashed line). Machines are
+          indicated as red dashed rectangles and connections to audio hardware
+          as outputs of SSR nodes as black lines below them.}
       \label{fig:ssr-networking}
     \end{figure}
     While the SSR already has an internal logic to know which loudspeaker will
@@ -179,87 +215,47 @@
     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 OSC.
+    \subsection{Prelimenaries}
+      In preparation to the exposé I tried to implement a side-by-side
+      installation, using Arch Linux on a medium scale setup, facilitating the
+      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 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, JACK and the development
+      version
+      of 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 SSR features.
+    \subsection{Outline}
+      \subsubsection{Remote controlling a server}
+      \subsubsection{Remote controlling clients}
+      \subsubsection{Rendering only on dedicated speakers}
+    \subsection{Publisher/Subscriber interface}
+    \subsection{IP interface}
+      \subsubsection{PureData integration}
+    \subsection{OSC interface}
+      \subsubsection{liblo}
+      \subsubsection{Client-Server setup}
+      \subsubsection{Multi-layered clients}
+      \subsubsection{Message interface}
+  \section{Future Work}
+    \subsection{Stress testing the OSC interface}
+    \subsection{Implementing a NullRenderer}
+    \subsection{Implementing AlienLoudspeaker}
+    \subsection{Interpolation of moving sources}
 
-  \section{Prelimenaries}
-    In preparation to the exposé I tried to implement a side-by-side
-    installation, using Arch Linux on a medium scale setup, facilitating the
-    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 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, JACK and the development version
-    of 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 SSR features.
-
-  \section{Schedule}
-    I propose a six month schedule for the implementation and testing of the
-    changes to the source code and writing of an accompanying thesis. The
-    following rough schedule should serve as a guideline for the realization of
-    the work:\\
-    \begin{tabular}{|l|l|l|l|}
-      \hline
-      \multicolumn{4}{|c|}{\textbf{Schedule}}\\
-      \hline
-      \textbf{Week} & \textbf{Implementation} & \textbf{Tests} & \textbf{Thesis} \\
-      \hline
-      1 & Reading into codebase & & \\
-      \hline
-      2 & Reading into codebase & & \\
-      \hline
-      3 & Reading into codebase & & \\
-      \hline
-      4 & Reading into codebase & & \\
-      \hline
-      5 & Assessing changes & & Documentation \\
-      \hline
-      6 & Assessing changes & & Documentation \\
-      \hline
-      7 & Implementing changes & & \\
-      \hline
-      8 & Implementing changes & & \\
-      \hline
-      9 & Implementing changes & & \\
-      \hline
-      10 & Implementing changes & & \\
-      \hline
-      11 & Implementing changes & & \\
-      \hline
-      12 & Implementing changes & & \\
-      \hline
-      13 & Implementing changes & & Preparation\\
-      \hline
-      14 & Implementing changes & & Preparation\\
-      \hline
-      15 & & Small scale setup & Writing\\
-      \hline
-      16 & & Large scale setup & Writing\\
-      \hline
-      17 & & Large scale setup & Writing\\
-      \hline
-      18 & & Large scale setup & Writing\\
-      \hline
-      19 & Large scale setup (scripts) & & Writing\\
-      \hline
-      20 & Large scale setup (scripts) & & Writing\\
-      \hline
-      21 & Large scale setup (scripts) & & Writing\\
-      \hline
-      22 & & & Writing\\
-      \hline
-      23 & & & Writing\\
-      \hline
-      24 & & & Writing\\
-      \hline
-    \end{tabular}
+  \pagebreak
+  \listoffigures
+  \listoftables
   \pagebreak
   \bibliographystyle{plainnat}
-  \bibliography{bib/ssr-networking}
+  \bibliography{../bib/ssr-networking}
 \end{document}
-- 
cgit v1.2.3-70-g09d2

