Endings

It is since 2009 that RAI broadcasting company employs a 3D VMS system in show production, and if the first times the task was, in fact, an experimental application of a research project, now the system has gained in stability and re-liability, becoming a sort of acoustic swiss knife that really can save some tens of meters of cables and the placement of other real microphones in non movable positions and with static polar shapes. Now, when, for example, the audio editing team has available the 32 raw recorded signals from array capsules, they can place the virtual microphones and decide the better polar pattern in post-production, and if something doesn’t sound good, they simply have to modify virtual micro-phone position and order.

Or also it is possible to take full advantage of the realtime features for a live broadcast production, using 3D VMS virtual microphone in place of 7 physical microphones: the first RAI production that employed this technology was the opera Lucia di Lammermoor broadcast live by Rai-Radio3 from Theater Regio of Turin the 21th of March 2011.

To achieve these results, the software part requested an accurate and long work, as described in chapter 5 because if it’s certainly true that BruteFIR, Eca-sound, GStreamer are excellent and intrinsically robust programs, to manage the concurrent execution of them and to maintain the entire system in a consistent state in case of failure of one of the subprocesses - that are always independent

Figure 6.1: Example of post-processing with 7 fixed microphones (La Bohème - The-ater Regio, Turin, 20 May 2010 ).

- it is absolutely not easy: still today some issues are not completely resolved, mainly in cases of incompatible startup setup.¹ Currently the system watches all running processes and when an error status is detected, the activity is paused or stopped and the user is warned, then a rearm is tried, but there are cases in which the behavior of a process in error status is not completely predictable and the safer way to restore a consistent state is to restart the main process.

In general terms, the program restart as an error recover procedure is a bad solu-tion, plus 3D VMS can have a long initialization phase on startup: what has been done to avoid these uncomfortable status is a careful software architecture design aimed to minimize runtime error status and numerous controls on Graphical User Interface options to prevent status with unpredictable behavior.

The feedback from RAI technicians are always very precious in this sense,² show-ing that the road taken was right, thus now it is possible to consider 3D VMS maybe still beta, but reliable, also in very chaotic situations like a mobile live broadcast set.

1For example: the user tries to start a cylindrical array setup when a camera with different resolution than expected is connected to the laptop. Actually the system warns the user about the incompatibility, and if one activity is launched, not always the video frame adaptation is successful.

2Especially when some time is given to work on bugs. . .

6.1 Future developments 85

6.1 Future developments

In the next future, there are a lot of feature requests for 3D VMS, here a partial list:

• addition of other polar shapes for virtual microphones, for example the figure-of-eight;

• addition of recording system related information in the output files as meta-data;

• increase the number of available virtual microphones;

• VST version of the system;

• version for iOS^®/Android™ based portable devices of the playback appli-cation.

Whilst the first and the second are already intrinsically available in the fil-tering engine and the audio file manager library respectively,³ the others require a much more radical action: as described in section 5.1.2, the limit of 7 virtual microphones is due to a limit of the software BruteFIR, therefore increase this number implies the complete replacement of the filtering engine. The extension of BruteFIR engine is not taken in account because its multiprocess based archi-tecture is to be considered obsolete, too much memory consuming and slow to setup⁴ compared to modern multithreaded applications.

An attempt was done in 2012 with the software Jconvolver⁵ by Fons Adriaensen, a JACK based multithreaded library that features up to 64 inputs and 64 outputs, quite easily embeddable in the 3D VMS architecture, but the needing of a more portable solution and the needing, at the time, to strengthen the mainstream system rather than writing new modules stopped the tests.

An apparently good alternative is represented by the filtering engine of XVolver⁶

3For W64 file format the library used is libsndfile by Eric de Castro Lopo (http://www.mega-nerd.com/libsndfile).

4The time needed to start a new process is effectively longer than the amount of time needed to start a new thread.

5http://kokkinizita.linuxaudio.org

6http://www.desknotes.it/siten/Software.html

software by Carlo Chiari, already written with portability in mind and for this reason can be a valuable base for a VST version of the software. The cons is the absence of a dynamic filter change feature that has to be implemented.

With portable devices, the computational power available and storage space are limited, for some kinds of devices very limited: in this case the challenge is to individuate a good trade-off between resources available on-device and online, for example pre-filtered tracks, balancing streaming and CPU loads in order to obtain a responsive feedback for the user.