Confirm proper reception of a Livewire channel on a QOR Console Engine

Updated 1 month ago by Bryan Jones

Scope

This document will show you how to confirm the reception of a Livewire channel by the QOR Engine.

Description

The QOR Engine is the DSP engine for the iQ, Radius, RAQ, and DESQ Consoles. It is responsible for receiving and decoding network audio streams (Livewire streams), so they can be mixed with other sources on the console. During troubleshooting, it can be helpful to know if a network stream is being received at all by the QOR. In other words, is the QOR getting any packets at all? Are there any errors? And finally, is there any audio in the network audio stream?

The QOR has a hidden debug information page that will show you all of this information.

View the Debug page

In this example, we will be using a console at the IP Address 192.168.2.27. Substitute your consoles IP address.
  1. Using your web browser, navigate to http://<youripaddress>/debug/lwio (for example, http://192.168.2.27/debug/lwio)
  2. Enter your username and password.

The following screen is displayed.

Interpreting the data

We want to focus on the Inputs: section of this screen. We have color-coded individual sections for clarity.

Statistics on this page do not update in real-time. You must refresh your browser to see new stats.
  • PSID (yellow) - Informational and is the actual Livewire channel number of the stream.
  • Packets (green) - These are "normal" packets of audio received by the console, and they (in most cases) will continually increment.
  • Overruns, Underruns, TS (time stamp Defects (red) - These are highlighted in red as they are generally bad.
    • Overruns - The console received more packets than it could process. In a very literal sense, the water glass was full. The remaining water you poured in spilled over the sides and on the floor.
    • Underruns - Exactly the opposite of an Overrun. We ran out of packets in the buffer to decode. To stick with our water glass analogy, we were drinking the water faster than the glass could be filled.
    • TS Defects - Each packet has a Time Stamp. TS defects indicate either, there was a gap in the packets, or the packets came out of order.

The items in red often show some network issues. A few errors are normal; no network is ever error-free; however, these should not continually increment each time you refresh the page. One exception to this might be the Axia IP-Audio driver. It can stop sending network packets if the player stops playing.
  • Peak [dB] (blue) - Is there audio in the received stream? A value of -100.0 indicates there is NO audio; in other words, the stream is received correctly but is silent. In our example, we can see that channel 2602 has peak audio indications of -13.5 dB on the left and -12.7 dB on the right. This confirms the presence of audio on this channel. 

Some final thoughts

Other columns not mentioned here are generally not a factor when trying to track down errors.

There is a "Reset Statistics" button at the bottom of the page. Click this a couple of times to clear out all statistics, so you are starting with a clean slate.

Let us know how we can help

If you have further questions on this topic or have ideas about how we can improve this document, please contact us.


How did we do?


TelosHelp

Powered by HelpDocs