comparison docs/WAC2016/WAC2016.tex @ 322:4cf9d989d77c WAC2016

Added some Architecture parts

         	\item Can't get channel data, hardware input/output... 
         \end{itemize}
 
 	
 \section{Architecture}  % title? 'back end'? % NICK
+    WAET utilises the Web Audio API for audio playback and uses a sparse subset of the Web Audio API functionality, however the performance of WAET comes directly from the Web Audio API. Listening tests can convey large amounts of information other than obtaining the perceptual relationship between the audio fragments. WAET specifically can obtain which parts of the audio fragments were listened to and when, at what point in the audio stream did the participant switch to a different fragment and what new rating did they give a fragment. Therefore it is possible to not only evaluate the perceptual research question but also evaluate if the participant performed the test well and therefore if their results are representative or should be discarded as an outlier.
+    
+    One of the key initial design parameters for WAET is to make the tool as open as possible to non-programmers and to this end the tool has been designed in such a way that all of the user modifiable options are included in a single XML document. This document is loaded up automatically by the web page and the JavaScript code parses and loads any extra resources required to create the test.
+    
+    The specification document also contains the URL of the audio fragments for each test page. These fragments are downloaded asynchronously and decoded offline by the Web Audio offline decoder. The resulting buffers are assigned to a custom Audio Objects node which tracks the fragment buffer, the playback bufferSourceNode, the XML information including its unique test ID, the interface object(s) associated with the fragment and any metric or data collection objects. The Audio Object is controlled by an over-arching custom Audio Context node (not to be confused with the Web Audio Context), this parent JS Node allows for session wide control of the Audio Objects including starting and stopping playback of specific nodes.
+    
+    The only issue with this model is the bufferNode in the Web Audio API, which is implemented as a 'use once' object which, once the buffer has been played, the buffer must be discarded as it cannot be instructed to play the buffer again. Therefore on each start request the buffer object must be created and then linked with the stored bufferSourceNode. This is an odd behaviour for such a simple object which has no alternative except to use the HTML5 audio element, however they do not have the ability to synchronously start on a given time and therefore not suited.
+    
+    The media files supported depend on the browser level support for the initial decoding of information and is the same as the browser support for the HTML5 audio element. Therefore the most widely supported media file is the wave (.WAV) format which can be accpeted by every browser supporting the Web Audio API. The next best supported audio only formats are MP3 and AAC (in MP4) which are supported by all major browsers, Firefox relies on OS decoders and therefore its support is predicated by the OS support.
+    
+    All the collected session data is returned in an XML document structured similarly to the configuration document, where test pages contain the audio elements with their trace collection, results, comments and any other interface-specific data points.
+    
 	A slightly technical overview of the system. Talk about XML, JavaScript, Web Audio API, HTML5. 
 	Describe and/or visualise audioholder-audioelement-... structure. 
 
 	% see also SMC12 - less detail here
 

 	The following features allow easy and effective remote testing: 
 	\begin{itemize}[noitemsep,nolistsep]
 		\item PHP script to collect result XML files
 		\item Randomly pick specified number of audioholders
 		\item Calibration
+		% In theory calibration could be applied anywhere??
 		\item Functionality to participate multiple times
 			\begin{itemize}[noitemsep,nolistsep]
 				\item Possible to log in with unique ID (no password)
 				\item Pick `new user' (need new, unique ID) or `already participated' (need already available ID)
 				\item Store XML on server with IDs plus which audioholders have already been listened to
 				\item Don't show `post-test' survey after first time
 				\item Pick `new' audioholders if available
 				\item Copy survey information first time to new XMLs
 			\end{itemize}
 		\item Intermediate saves
-		\item Collect IP address information (privacy issues?) --> geo-related API? 
-		\item Time measurement - see before or 
+		\item Collect IP address information (privacy issues?) --> geo-related API?
+		\item Collect Browser and Display information 
 	\end{itemize}
 
 	
 \section{Interfaces} % title? 'Front end'? % Dave