diff options
Diffstat (limited to 'thesis')
| -rw-r--r-- | thesis/thesis.tex | 282 |
1 files changed, 146 insertions, 136 deletions
diff --git a/thesis/thesis.tex b/thesis/thesis.tex index fbd5343..23f35d1 100644 --- a/thesis/thesis.tex +++ b/thesis/thesis.tex @@ -77,10 +77,16 @@ parskip=never]{paper} \newacronym{raii}{RAII}{Ressource acquisition is initialization} \newacronym{ssr}{SSR}{SoundScape Renderer} \newacronym{tcp}{TCP}{Transmission Control Protocol} +\newacronym{tu-berlin}{TU Berlin}{Technische Universität Berlin} \newacronym{udp}{UDP}{User Datagram Protocol} \newacronym{vbap}{VBAP}{Vector Based Amplitude Panning} \newacronym{wfs}{WFS}{Wave Field Synthesis} \newacronym{xml}{XML}{Extensible Markup Language} +\newglossaryentry{ascii}{ + name={ASCII}, + description={American Standard Code for Information Interchange --- a + character encoding standard} +} \newglossaryentry{sclang}{ name={sclang}, description={Name of the SuperCollider programming language and the @@ -230,10 +236,10 @@ parskip=never]{paper} With the rise of dynamic two and three-dimensional rendering algorithms (see~\ref{subsec:spatialaudiorenderingalgorithms}), the need for specialized software, implementing them, grew. Opposed to encoding of - spatial information of sources in only two channels - static in the case of - commercially produced audio for radio and film - encoding for massive multi - loudspeaker systems would not be feasible, when done statically, or not - applicable in the case of dynamic setups, reacting to user input in + spatial information of sources in only two channels --- static in the case + of commercially produced audio for radio and film --- encoding for massive + multi loudspeaker systems would not be feasible, when done statically, or + not applicable in the case of dynamic setups, reacting to user input in realtime.\\ Generally, software can be divided into two groups: One, which is developed @@ -251,11 +257,11 @@ parskip=never]{paper} renderers, currently in use, were evaluated and compared, of which one was chosen for extension.\\ - The \gls{ssr} is a multi-purpose spatial audio renderer, developed at - Technical University of Berlin. To improve its usability and networking - capabilities, a new networking extension was developed, facilitating a - \gls{osc} based messaging system, that incorporates features for - distributed processing in massive multi-loudspeaker setups.\\ + The \gls{ssr} is a multi-purpose spatial audio renderer, developed at the + \gls{tu-berlin}. To improve its usability and networking capabilities, a + new networking extension was developed, facilitating a \gls{osc} based + messaging system, that incorporates features for distributed processing in + massive multi-loudspeaker setups.\\ \cleardoublepage \section{Free and open-source spatial audio renderers} @@ -263,39 +269,39 @@ parskip=never]{paper} To date there exist five (known of) free and open-source spatial audio renderers, which are all \gls{jack} \citep{website:jackaudio2016} clients: \begin{itemize} - \item sWONDER \citep{website:swonder2016}, developed by Technische - Universität Berlin, Germany + \item sWONDER \citep{website:swonder2016}, developed at the + \gls{tu-berlin} , Germany \item WFSCollider \citep{website:wfscollider}, developed by the Game Of Life Foundation \citep{website:gameoflife}, The Hague, Netherlands \item HoaLibrary for \gls{pd} \citep{github:hoalibraryforpd} developed at - \gls{cicm}, Paris, France + the \gls{cicm}, Paris, France \item 3Dj for \gls{supercollider} \citep{thesis:perezlopez3dj2014}, - developed at Universitat Pompeu Fabra, Barcelona - \item \gls{ssr} \citep{website:ssr2016}, developed by Quality \& - Usability Lab, Telekom Innovation Laboratories, TU Berlin and Institut - für Nachrichtentechnik, Universität Rostock and Division of Applied - Acoustics, Chalmers University of Technology + developed at the Universitat Pompeu Fabra, Barcelona + \item \gls{ssr} \citep{website:ssr2016}, developed at the Quality \& + Usability Lab, Telekom Innovation Laboratories, \gls{tu-berlin} and + Institut für Nachrichtentechnik, Universität Rostock and Division of + Applied Acoustics, Chalmers University of Technology \end{itemize} Different concepts and contexts apply to all of the renderers, which are - about to be explained briefly in the following sections, prefixed by a - section about spatial audio rendering algorithms and followed by one about - free software and its pitfalls. + briefly explained in the following sections, prefixed by a section about + spatial audio rendering algorithms and followed by one about free software + and its pitfalls. \subsection{Spatial audio rendering algorithms} \label{subsec:spatialaudiorenderingalgorithms} - In the following subsubsections several spatial audio rendering + In the following subsections several spatial audio rendering algorithms are introduced briefly. - As they serve as a mere introductory, they are merged where applicable. + As they serve as a mere introduction, they were merged where applicable. \subsubsection{Dynamic Binaural Synthesis and Dynamic Binaural Room Synthesis} \label{subsubsec:binaural} - \gls{bs} describes a stereophonic audio reproduction, in which - - usually using headphones - acoustic signals are recreated at the ears + \gls{bs} describes a stereophonic audio reproduction, in which --- + usually using headphones --- acoustic signals are recreated at the ears of the listener.\\ For humans, sound source localization and distance estimation takes place according to auditory cues from each ear. The signals perceived - by inner and outer ear, are correlated by the brain, to account for + by inner and outer ear are correlated by the brain, to account for locations in all three dimensions and their distances from the listener.\\ The differences between the cues perceived by each ear can be measured @@ -308,10 +314,10 @@ parskip=never]{paper} alongside the room's acoustic characteristics. This way, recordings from real rooms can be reproduced authentically.\\ \glspl{hrir} and \glspl{brir} are by default applied seperately for - each ear, therefore, if a resolution of 1\textdegree~is desired, it - can be achieved by a set of 720 impulse responses, that are applied to - the source with the help of a head tracker, measuring the azimuth of - the listener towards it. + each ear. Therefore, if a resolution of 1\textdegree~is desired, it can + be achieved by a set of 720 impulse responses, that are applied to the + source with the help of a head tracker, measuring the azimuth of the + listener towards it. \subsubsection{(Higher Order) Ambisonics Amplitude Panning and Near-field-compensated Higher Order Ambisonics} @@ -343,7 +349,7 @@ parskip=never]{paper} field formed by loudspeakers in an arbitrary three-dimensional placement“, while being ”computationally efficient and accurate“ \citep[p. 464]{VillePulkki1997-05-31}.\\ - However, according to \citep{MatthiasGeier1888} ”\gls{vbap} has a very + However, according to \citet{MatthiasGeier1888} ”\gls{vbap} has a very small sweet spot, out of which localization of sources is distorted towards the nearest active loudspeaker“ and ”works best for circular setups“. @@ -354,9 +360,9 @@ parskip=never]{paper} Huygens-Fresnel principle. It states that any wave front can be synthesized by the superposition of elementary spherical waves.\\ Setups mainly focus on horizontal, preferably spatially discrete, - speaker arrays of rectangular or circular shape, as the human hearing - is most capable to localize acoustic sources in this this plane.\\ - According to \citep{HagenWierstorf1899}, localization is accurately and + speaker arrays of rectangular or circular shape as the human hearing is + most capable to localize acoustic sources in this this plane.\\ + According to \citet{HagenWierstorf1899}, localization is accurately and evenly distributed in the listening area with loudspeaker spacings of up to 40cm.\\ Although \gls{wfs} does not suffer from a pronounced sweet spot and @@ -386,17 +392,19 @@ parskip=never]{paper} that was specifically designed for it.\\ Sound sources can be moved dynamically, or according to a \gls{xml} based score.\\ - sWONDER has been in use for the medium and large scale \gls{wfs} systems - in the Electronic Music Studio \citep{website:tu-electronic_studio} and - lecture hall H0103 \citep{website:tu-wfs} at Technical University of - Berlin and a medium scale system at the Wave Field Synthesis Lab at HAW - in Hamburg \citep{Fohl2013}.\\ - The included convolution engine fWonder has found application in - “Assessing the Authenticity of Individual Dynamic Binaural Synthesis” - \citep[pp. 223-246]{lindau2014}.\\ + For example sWONDER has been in use for the medium and large scale + \gls{wfs} systems in the Electronic Music Studio + \citep{website:tu-electronic_studio} and lecture hall H0103 + \citep{website:tu-wfs} at \gls{tu-berlin} and a medium + scale system at the Wave Field Synthesis Lab at HAW in Hamburg + \citep{Fohl2013}.\\ + The included convolution engine fWonder is applied in “Assessing the + Authenticity of Individual Dynamic Binaural Synthesis” \citep[pp. + 223-246]{lindau2014}.\\ Unfortunately, the spatial audio renderer has not been actively - maintained for several years, is limited to its two rendering algorithms - and has many bugs, that are not likely to get fixed in the future.\\ + maintained for several years. Hence it is limited to its two rendering + algorithms and has many bugs, that are not likely to get fixed in the + future.\\ \subsection{HoaLibrary (PureData extension)} \label{subsec:hoalibrary_puredata_extension} @@ -419,7 +427,7 @@ parskip=never]{paper} \citep{thesis:perezlopez3dj2014} for interactive performance live spatialization purposes. It implements \gls{hoa} and \gls{vbap} rendering \citep[p 45]{thesis:perezlopez3dj2014} and uses a specific scene format - \citep[pp. 45-46]{thesis:perezlopez3dj2014} to allow sound sources to + \citep[pp. 45--46]{thesis:perezlopez3dj2014} to allow sound sources to have static, linear, random, brownian, simple harmonic and orbital motion.\\ Due to being a language extension to \gls{sclang}, 3Dj can be used in @@ -432,10 +440,10 @@ parskip=never]{paper} \label{subsec:wfscollider} WFSCollider was built on top of \href{https://supercollider.github.io}{SuperCollider} 3.5 - \citep{website:supercollider} and as its name suggests, is an application - for \gls{wfs} reproduction. It “allows soundfiles, live input and - synthesis processes to be placed in a score editor where start times, and - durations can be set and trajectories or positions assigned to each + \citep{website:supercollider} and as its name suggests, it is an + application for \gls{wfs} reproduction. It “allows soundfiles, live input + and synthesis processes to be placed in a score editor where start times, + and durations can be set and trajectories or positions assigned to each event. It also allows realtime changement of parameters and on the fly starting and stopping of events via \gls{gui} or \gls{osc} control. Each event can be composed of varous objects (“units”) in a processing chain“ @@ -446,7 +454,7 @@ parskip=never]{paper} of the Game Of Life Foundation“ \citep{website:gameoflife}. In multi-computer setups, it can synchronize the involved processes and a dynamic latency can be introduced to account for high network throughput - \citep[p. 22]{manual:wfscollider}. WFSCollider by nature is \gls{osc} + \citep[p. 22]{manual:wfscollider}. By nature WFSCollider is \gls{osc} capable and extendable by what \gls{sclang} has to offer. Its scores are saved as \gls{supercollider} code, as well.\\ It is currently only tested on MacOSX and is based upon a several year @@ -544,10 +552,10 @@ parskip=never]{paper} \subsection{Outline} \label{subsec:outline} - Initially it was aimed at extending the \gls{ssr}'s features in the scope + Initially, it was aimed to extend the \gls{ssr}'s features 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. - The approach appeared too narrow however, as the application offers many + However, the approach appeared too narrow, as the application offers many different rendering algorithms. A networking extension therefore would have to be available to all of them with an equal feature set. Additionally, extending a rendering framework by a networking feature, @@ -566,30 +574,31 @@ parskip=never]{paper} \label{subsubsec:preliminaries} 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 + setup of the Electronic Studio at \gls{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 + 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 + 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.\\ + kernel and software features on a regular basis. It is essential to + find the most stable and secure setup possible involving realtime + enabled kernels and building new versions of (spatialisation) + software.\\ + The hardware of the large scale setup at \gls{tu-berlin} in lecture + hall 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 the features described in the following sections and subsections, as they can be tested using two @@ -602,7 +611,7 @@ parskip=never]{paper} reproduction setup is supposed to have a set of \textit{n} (pre-)assigned clients. Generally, controlling it should be possible through either \gls{udp} or \gls{tcp}. - Every message sent to it, should be distributed to all of its clients + Every message sent to it should be distributed to all of its clients (if applicable), preferably using the same protocol used to communicate with the server. The messaging system should be flexible and scriptable.\\ @@ -637,10 +646,10 @@ parskip=never]{paper} \label{subsec:publisher_subscriber_interface} The \gls{ssr} internally uses a \gls{pubsub}, which is a design pattern, to implement control through and over several parts of its components.\\ - In \gls{oop} \gls{pubsub} - also called observer, listener messaging - is - usually comprised of a publisher class, handling the messages, without - explicitely implementing how they will be used and a subscriber class, - that allows for its implementations to subscribe to the messages + In \gls{oop} \gls{pubsub} --- also called observer, listener messaging + --- is usually comprised of a publisher class, handling the messages, + without explicitely implementing how they will be used and a subscriber + class, that allows for its implementations to subscribe to the messages provided. Filtering takes place to enable subscribers to only receive a certain subset of the messages.\\ The \gls{ssr} implements a content-based filtering system, in which each @@ -697,11 +706,11 @@ parskip=never]{paper} port, called “\gls{ip} interface”. This has the benefit of reusing the same \gls{xml} parser code in use for scene and reproduction description.\\ - A downside is however, that - from the perspective of other software - it - is complicated to use, as a conversion to \gls{xml} has to be attempted - before sending a message to the \gls{ssr}. Additionally the message has - to be linted (error checked) before sending and again parsed, after - receiving an answer from the application.\\ + A downside is however, that --- from the perspective of other software + --- it is complicated to use, as a conversion to \gls{xml} has to be + attempted before sending a message to the \gls{ssr}. Additionally, the + message has to be linted (error checked) before sending and parsed again, + after receiving an answer from the application.\\ The \gls{ip} interface achieves to offer more or less direct access to the \nameref{subsec:publisher_subscriber_interface}. However, it has no notion of a networked setup and could therefore be described as a @@ -723,9 +732,8 @@ parskip=never]{paper} \subsubsection{Sending and receiving} \label{subsubsec:sending_and_receiving} - As mentioned in - section~\nameref{subsec:publisher_subscriber_interface}, the - \mintinline{c++}{NetworkSubscriber} class (part of the \gls{ip} + As mentioned in section~\ref{subsec:publisher_subscriber_interface}, + the \mintinline{c++}{NetworkSubscriber} class (part of the \gls{ip} interface) implements the \mintinline{c++}{Subscriber} interface. This means: The network interface subscribes to the messages the \mintinline{c++}{Publisher} (the \mintinline{c++}{Controller} instance) @@ -753,8 +761,8 @@ parskip=never]{paper} 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 + setups and to 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}} @@ -795,7 +803,7 @@ parskip=never]{paper} The class \mintinline{c++}{OscClient} implements the representation of a client (or server) to the message interface. It holds information about the client's address and port, along with its - \mintinline{c++}{MessageLevel} (a concept elaborated upon + \mintinline{c++}{MessageLevel} (a concept elaborated in~\ref{subsubsec:message_levels}) and its alive counter (used to check, whether a given client is still available on the network).\\ As shown in Figure~\ref{fig:ssr-publisher-with-all-subscribers}, the @@ -806,8 +814,8 @@ parskip=never]{paper} as well. With \mintinline{c++}{OscReceiver} the \gls{osc} interface has direct access to the \mintinline{c++}{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 + In its implementation approach the \gls{osc} interface follows that of + the \textbf{\nameref{subsec:ip-interface}}. However, it expands in creating a client-server architecture, controlled by \textbf{\nameref{subsubsec:message_levels}}, using a unified \textbf{\nameref{subsubsec:message_interface}}.\\ @@ -867,7 +875,7 @@ parskip=never]{paper} \texttt{d} & 64 bit (“double”) IEEE 754 floating point number\\ \texttt{S} & Alternate type represented as an \gls{osc}-string (for example, for systems that differentiate “symbols” from “strings”)\\ - \texttt{c} & an ascii character, sent as 32 bits\\ + \texttt{c} & An \gls{ascii} character, sent as 32 bits\\ \texttt{r} & 32 bit RGBA color\\ \texttt{m} & 4 byte \gls{midi} message. Bytes from MSB to LSB are: port id, status byte, data1, data2\\ @@ -896,7 +904,7 @@ parskip=never]{paper} and \gls{osc}-blob are considered standardized. Most of the remaining non-standard types are however implemented and used by many different clients. For implementing the \gls{ssr} \gls{osc} interface, described - in the following subsubsections, it was necessary to use the + in the following subsections, it was necessary to use the non-standard types \textit{True} and \textit{False} alongside the standard-types. @@ -906,7 +914,7 @@ parskip=never]{paper} protocol for \gls{posix} systems. It was initially developed by Steve Harris and is now actively maintained by Stephen Sinclair.\\ The library, written in C, offers a C++ abstraction layer and is - released under the \gls{lgpl} v2.1 or greater. Additionally there are + released under the \gls{lgpl} v2.1 or greater. Additionally, there are wrappers for the Perl and \gls{python} programming languages.\\ Due to its long standing availability and usage in many small and large-scale software projects, alongside its fairly straight forward @@ -923,28 +931,29 @@ parskip=never]{paper} class, at the core of the C++ side of the library, is responsible for assigning a network port to listen to for incoming messages, listening for messages, executing code on their arrival (i.e.\ callback handling) - and sending messages to clients. As most applications, facilitating - liblo, use \gls{osc} only as a messaging system, it usually means, that - the application itself is not single-purpose and is busy computing - something else most of the time. Therefore it makes sense to run a - Server instance on a separate background thread, to not interfere with - the executional flow of the rest of the program.\\ + and sending messages to clients. Many applications, facilitating + liblo, use \gls{osc} only as a messaging system. This usually means, + that such an application itself is not single-purpose and is busy + computing something else most of the time. Therefore it makes sense to + run a Server instance on a separate background thread, to not interfere + with the executional flow of the rest of the program.\\ The \mintinline{c++}{ServerThread} class is able to free its ressources - upon going ot of scope, known as \gls{raii}. For this reason, the + upon going ot of scope (i.e.\ their ressources are not used by any + object or function anymore), known as \gls{raii}. For this reason, the latest development version, instead of the current stable version of - liblo was chosen for the implementation. + liblo, was chosen for the implementation. \subsubsection{Starting the SSR} \label{subsubsec:starting-the-ssr} The \gls{ssr} can be started with a rendering engine preselected (an executable postfixed by the supported rendering algorithm is provided - by the software - e.g. \textbf{ssr-wfs}), or by selecting one through + by the software --- e.g. \textbf{ssr-wfs}), or by selecting one through the configuration file, when using the standard executable named \textbf{ssr}. This way \gls{aap}, \gls{bs}, \gls{brs}, generic, \gls{nfc-hoa}, \gls{vbap}, \gls{wfs} renderers become available.\\ Additional features can be activated with the help of several flags to the executables. The customized ones, belonging to the \gls{osc} - interface will be discussed in the following paragraphs. More + interface will be discussed in the following subsections. More information on the interplay between \gls{osc} messaging and the \nameref{subsec:publisher_subscriber_interface} can be found in \textbf{\nameref{subsubsec:message_interface}}. @@ -981,7 +990,7 @@ ssr-binaural -p “50002” \pdfcomment[color=red,icon=Note]{Make -N start server, client is default anyways}, it is possible to start the \gls{ssr} as an \gls{osc} server. In Listing~\ref{lst:ssr-binaural-server-start} - additionally flag \textbf{-C} is used to specify an initial client + additionally, flag \textbf{-C} is used to specify an initial client \gls{ip} and its port (the flag actually accepts a comma-separated list of \gls{ip}-port pairs).\\ The \textbf{-p} flag, for setting a specific port is also available, @@ -1002,7 +1011,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” When the server instance starts, it instantly starts sending out poll messages to all of its active clients. Clients provided by the \textbf{-C} flag are considered instantly active.\\ - Additionally it's possible for clients (\gls{ssr} client instances, + Additionally, it is possible for clients (\gls{ssr} client instances, or \gls{osc} capable applications) to subscribe to the server instance, or be subscribed to it by another client, using a message level system further explained in~\ref{subsubsec:message_levels}. @@ -1011,8 +1020,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002” the aforementioned message level system.\\ If a client instance has not answered the sent out poll message of a server 10 times, it is considered to be unavailable and will be - deactivated. No messages will be sent to it anymore, until the client - subscribes/ is subscribed again. + deactivated\pdfcomment[color=red,icon=Note]{Implement this!}. No + messages will be sent to it anymore, until the client subscribes/ is + subscribed again. \paragraph{Verbosity} \label{para:verbosity} @@ -1031,14 +1041,14 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \label{subsubsec:setups} The \gls{ssr} offers the possibility for many different \gls{osc} enabled client-server and client-only setups. They will be explained in - the following paragraphs.\\ + the following subsections.\\ All examples provide audio input via a \gls{jack} client, which can be local (on each client's or server's host computer) or provided through external audio inputs from another host computer (e.g.\ through - \gls{adat} or \gls{madi}). This however is not mandatory, as the + \gls{adat} or \gls{madi}). However, this is not mandatory, as the \gls{ssr} is capable of playing back audio files directly.\\ The differences between server and client messaging is further - elaborated upon in \textbf{\nameref{subsubsec:message_interface}}.\\ + elaborated in \textbf{\nameref{subsubsec:message_interface}}.\\ A special networked setup, in which the server instance is not rendering any audio, is discussed in \textbf{\nameref{subsubsec:non-renderer}}. @@ -1218,11 +1228,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \label{lst:ssr_global.h} \end{listing}\\ - \noindent\gls{ssr} client instances subscribe to (\gls{ssr}) server instances - with the \mintinline{c++}{MessageLevel} \mintinline{c++}{CLIENT} by - default. Server instances get the \mintinline{c++}{MessageLevel} - \mintinline{c++}{SERVER} assigned to by each client on subscribing to - it.\\ + \noindent\gls{ssr} client instances subscribe to \gls{ssr} server + instances with the \mintinline{c++}{MessageLevel} + \mintinline{c++}{CLIENT} by default. Server instances get the + \mintinline{c++}{MessageLevel} \mintinline{c++}{SERVER} assigned to by + each client on subscribing to it.\\ In the \gls{osc} interface it is implemented as follows: A (recycable and reconfigurable) list of clients is held by a server instance, which enables for the \mintinline{c++}{MessageLevel} to change for each @@ -1246,7 +1256,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” instance to receive the above mentioned performance heavy \gls{osc} messages. How the setting up of message levels is achieved, is further elaborated - upon in the following section. + in the following section. \subsubsection{Message interface} \label{subsubsec:message_interface} @@ -1255,9 +1265,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002” messages only understood by client or server (or a context dependant meaning), most of the messages understood by the \nameref{subsec:ip-interface} are implemented. Additional features, - related to server-client and client-only functionality were integrated + related to server-client and client-only functionality, were integrated as well.\\ - Generally it can be distinguished between \textit{direct} messages - + In general, it can be distinguished between \textit{direct} messages - sent from a server (or an application mimicking one) to a client or a server to trigger processing (see Table~\ref{tab:ssr-osc-processing-tracker-transport}), reference (see @@ -1266,8 +1276,8 @@ ssr-aap -N “server” -C “127.0.0.1:50002” Table~\ref{tab:ssr-osc-source}), tracker (see Table~\ref{tab:ssr-osc-processing-tracker-transport}) or transport (see Table~\ref{tab:ssr-osc-processing-tracker-transport}) related - operations in the \gls{ssr} - and \textit{update} messages (see - Table~\ref{tab:ssr-osc-update}) - sent from a client to a server upon + operations in the \gls{ssr} --- and \textit{update} messages (see + Table~\ref{tab:ssr-osc-update}) --- sent from a client to a server upon successful processing an operation related to a \textit{direct} message.\\ @@ -1336,11 +1346,11 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \textit{message level} (see Table~\ref{tab:ssr-osc-subscribe}) and \textit{poll} and \textit{message level} (see Table~\ref{tab:ssr-osc-client-poll-message-level}) messages. The former - - understood only by \gls{ssr} server instances - enable clients to + --- understood only by \gls{ssr} server instances --- enable clients to subscribe (with a certain message level) or subscribe other clients (with a predefined message level) and set their own message level or - that of another client. The latter set - only understood by clients - - enables servers (or applications mimicking one) to poll yet + that of another client. The latter set --- only understood by clients + --- enables servers (or applications mimicking one) to poll yet unsubscribed clients to have them subscribe and subscribed clients to reply with an alive message. Similar to the \textit{message level} message understood by server instances, the one understood by clients @@ -1663,10 +1673,10 @@ ssr-aap -N “server” -C “127.0.0.1:50002” Figure~\ref{fig:ssr-external-clients-only-separate-output}), it is necessary to send a poll message to the client instance to make it subscribe (which sets the server's address and port up internally).\\ - Afterwards - similar to the example in the paragraph - \nameref{para:clients_only} - all \textit{direct} \gls{osc} messages - are accepted by the client instance, when coming from the server - address and port.\\ + Afterwards --- similar to the example in the subsection + \nameref{para:clients_only} --- all \textit{direct} \gls{osc} + messages are accepted by the client instance, when coming from the + server address and port.\\ An interesting concept here is to (temporarily) set a different \mintinline{c++}{MessageLevel} for the application acting as a server (e.g.\ to \mintinline{c++}{GUI_SERVER}), to receive \gls{gui} @@ -1695,9 +1705,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002” 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 + where appropriate. Additionally, an open client-server architecture has been created, according to a message level system, further elaborated - upon in~\ref{subsubsec:message_levels}. An attempt at giving extensive + in~\ref{subsubsec:message_levels}. An attempt at giving extensive examples on the various setup possibilities, that are now available, is made in~\ref{subsubsec:setups}, some of which are still dependant on various missing features (see~\ref{subsec:future_work}).\\ @@ -1755,7 +1765,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” processed action by the server, the latter will. This is explained by \gls{sclang} not being a subscribed client with a \mintinline{c++}{MessageLevel} of \mintinline{c++}{SERVER} or higher in - the first case. In the second test however \gls{sclang} subscribes to + the first case. However, in the second test \gls{sclang} subscribes to the \gls{ssr} server instance, which is why the \gls{osc} messages are evaluated in this case.\\ @@ -1827,7 +1837,9 @@ ssr-aap -N “server” -C “127.0.0.1:50002” internally to cast the value of the message data type (\textit{unsigned int}) to the one expected by the \gls{ssr}'s Controller implementation (\textit{signed int}) and the outcome of said operation is - implementation dependant (depending on the \gls{os} in use).\\ + implementation dependant (depending on the \gls{os} in + use)\pdfcomment[color=red,icon=Note]{Fix this for all unsigned + integers!}.\\ The second example, if not checked for empty string, would lead to the \gls{osc} interface trying to create a possibly defective address and send poll messages out to it.\\ @@ -1894,7 +1906,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \caption{A diagram displaying a \gls{ssr} client/server setup, in which only the clients render audio collectively (e.g.\ medium or large-scale \gls{wfs}). The server instance is not controlled via - \gls{osc}, but controls its clients through it. Additionally its + \gls{osc}, but controls its clients through it. Additionally, its rendering engine does not have any outputs.\\ {\color{osc-in}\textbf{--}} \gls{osc} input {\color{osc-out}\textbf{--}} \gls{osc} output @@ -1930,7 +1942,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \caption{A diagram displaying a \gls{ssr} client/server setup, in which only the clients render audio to separate outputs (e.g.\ multiple \glspl{bs} renderers). The server instance is not controlled - via \gls{osc}, but controls its clients through it. Additionally its + via \gls{osc}, but controls its clients through it. Additionally, its rendering engine does not have any outputs.\\ {\color{osc-in}\textbf{--}} \gls{osc} input {\color{osc-out}\textbf{--}} \gls{osc} output @@ -1957,7 +1969,7 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \gls{ssr} has to be extended to show the networking specific information and be able to use the \gls{osc} interface through the \gls{pubsub} interface (which itself would probably have to be extended - as well). Additionally a renderer should be conceived, that does not + as well). Additionally, a renderer should be conceived, that does not render audio, but still uses the \gls{pubsub}, so the internal functionality of the \gls{ssr} can be reused, leading to a relatively light-weight \gls{ssr} \gls{gui} variant, only for controlling @@ -2030,16 +2042,13 @@ ssr-aap -N “server” -C “127.0.0.1:50002” host-specific loudspeakers have to be taken into account. Listing~\ref{lst:asdf.xsd} shows an attempt at providing a unique attribute for each part of the setup, that is referencing a loudspeaker - - the hostname or \gls{ip} address of the host - by extending the - \gls{asdf}.\\ + --- the hostname or \gls{ip} address of the host --- by extending the + \gls{asdf}.\\ More work has to be put into implementing this feature, or rather improvement however, as it also requires tests in medium and large scale setups, to ensure a discrete rendering, as if only using one host. - \subsubsection{Automatic client discarding} - \label{subsubsec:automatic_client_discarding} - \subsubsection{Status messages} \label{subsubsec:status_messages} When reflecting about different use-cases for networking setups @@ -2052,11 +2061,12 @@ ssr-aap -N “server” -C “127.0.0.1:50002” \gls{supercollider}, while only relying on \gls{osc} for communication between the parts. Another would be the case, where certain aspects of a client or server instance should be monitored (e.g.\ \gls{cpu} - usage). Both examples should allow a (\gls{gui}) process to be - subscribed, after the active \gls{ssr} instances started rendering.\\ + usage). Both examples should allow a \gls{gui} (or any other + monitoring) process to be subscribed, after the active \gls{ssr} + instances started rendering.\\ To be able to retrieve information from a \gls{ssr} instance, its \gls{pubsub} interface has to be extended and \mintinline{c++}{get} - functions implemented - where applicable - to return the desired + functions implemented --- where applicable --- to return the desired information. A special case of this feature is described in~\ref{subsubsec:scene_transfer}. @@ -2199,8 +2209,8 @@ ssr-aap -N “server” -C “127.0.0.1:50002” whereas 3Dj and WFSCollider use a unique format or even \gls{supercollider} code as score files.\\ Schema validated input is less error-prone and should generally be - preferred over single-purpose or self-conceived formats. It would - therefore be a good step to consolidate the \gls{asdf} schema part + preferred over single-purpose or self-conceived formats. Therefore, it + would be a good step to consolidate the \gls{asdf} schema part responsible for dynamic elements, while keeping in mind the overall message throughput as discussed in~\ref{subsubsec:interpolation_of_moving_sources} and thus enable the |