Digital Test Tools

How the Guardian Locates Incorrect Routing of Audio Channels

One of our favorite questions is:

When speaker cables are swapped...a GUI ViewCan the DxG system detect an incorrect routing of an audio channel? For example, if the center (dialog) channel were routed to the left surround channel instead, will the system report an error.
If so:
– What will the data look like?
– How will a typical tech identify the problem?

This issue was part of the original design criteria of the Digital eXperience Guardian (DXG) project. It is the reason for the 4 microphones around the edge of the case, and the physics-of-sound distance separating them – which in turn determines the size of the case (and which also leaves room for our option cards.) Position Detection is one more reason for hanging the audio portion of the system in the sound field of the auditorium.

As you probably know, the Guardian's process runs an assembled set of color and audio DCPs that match up to a DXG sequence file which runs on the client’s computer. One of those DCPs consists of ‘clicks’, one of each which is sent to each speaker set. It can run anywhere in the sequence – the standard sequence puts it in the beginning of the DXG Audio Test.

As each click is played, the system monitors the timing of that sound wave as it is received at each microphone. After the sequence is finished there is a PostProcessing step, which produces the 1st of several presentations and reports. Figure 1 shows a portion of this quick session report. 

We send these clicks at an interval of .75 second, so a system with 64 speakers would take 48 seconds. During that step, we also monitor the time during which the click should have happened – if there is no click then the system reports a ‘Timeout’ and moves on to the next. The error would be reported in all the following different report formats. 

Figure 1 – showing a section of a report that is presented onscreen immediately after a test sequence is run.Figure 1 – showing a section of a report that is presented onscreen immediately after a test sequence is run.Figure 1 – showing a section of a report that is presented onscreen immediately after a test sequence is run.Figure 1 – showing a section of a report that is presented onscreen immediately after a test sequence is run.Figure 1 – showing a section of a report that is presented onscreen immediately after a test sequence is run.

Figure 1 – showing a section of a report that is presented onscreen immediately after a test sequence is run.

Since The Guardian is a changes-based system, it is not so important that the system is hung exactly at the centerline of the screen or pointed at the exact center, which would have made the Center speaker 0.000°. What is important is how the result compares with the baseline reading, which is shown in Figure 2.

Figure 2 shows part of an in-GUI report that compares a session with the baseline, showing details of both runs and their Delta, and a green check mark – or bright red X – which makes it easy for the tech to notice data outside of the parameters that were set by the facility management. 

Compare GUI for Click Test

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 2 – This section of the report is showing THD (FFT-derived), Amplitude (Delta in dB) and Direction (in degrees) 

These details come from a report that is extracted from clicking on the GUI. Figure 3 and 4 shows the GUI and some details about the various buttons that the tech would use to get to different areas of interest. 

DXG GUI Front End
Figure 3 – DXG GUI Front End 

GUI Buttons with DescriptionFigure 4 – The buttons. Two Pop Sync not yet incorporated.

That sums up the answer about the typical tech question, explaining how they would identify the problem, either locally or via a VPN session.  

Sending Data to Remote Management Systems 

There are two other important methods that this data gets used though, basically because there are fewer and fewer ‘typical' techs. More and more, the techs are local outsourced techs who get sent to sites by remote NOCs. They get reports of problems and are asked to solve them.  In this case, we need to give the data to the NOC, hopefully before the cinema’s customers become the test tool. The more precise the data, the better prepared the tech, hopefully turning a two-trip job into one trip.  

Figure 5 shows part of the XML report as specified by a Remote Management System Group to work with their system. The actual xml file report is available to them, but the file is 2.5 meg, filled with the audio samples of all the various frequencies from all the speakers – which they don’t need. So, an abridged version of the post-processed data is created, parsing only the results that the client needs for their monitoring purposes. 

DXG Direction Report in xml
Figure 5 – The local reports are swept from a directory to a remote customer ftp site by a cron file.  

Not Shown – We also have a tool nearing completion that parses the xml data into an SQL database, which seems to be the preferred request of NOCs. 

Test Slide, Center Channel
Figure 6 – Test Slide, Center Channel

Home Digital eXperience Guardian How the Guardian Locates Incorrect Routing of Audio Channels

Quick Link

Live Support

Available: Monday - Saturday, 9 AM GMT - 6 PM PST

This email address is being protected from spambots. You need JavaScript enabled to view it.
Skype Chat 
Call us Now

Locations

1

Digital Test Tools, LLC, Chatsworth, CA

Tel: +1 818 877 61 49, Mail: [email protected]
2

Digital Test Tools, c/o Internet Marine, SARL
Sophia Antipolis, France

Tel: +1 818 877 61 49, Mail: [email protected]

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries