Statistics display

The statistics display (available from from Tools->Statistics) allows you to understand how network and system performance is effecting you audio experience. Some statistics are not dependant on a link with another player and will always be displayed. Other values are specifically for a link to a specific player and can be selected in the dropdown at the top of the display.

Statistics are either timers or counters. Timer show the percentage of available time used by the activity (e.g. if the audio cycle timer is 5% then 5% of the available time is used for handling audio processing). Counters show how many of a value is being used (e.g. if the missed packets counter average is 10, then on average 10 packets are being missed per second).

Counters (all values are per second)

• Audio Cycles Missed: the number of times that the CPU was unable to complete an audio cycle within the available time. If this is high you can reduce it by increasing your buffer size.
• Missed Packets: the number of received audio packets that have been missed. This is usually a sign of an issue with the network.
• TimeStamp_Diff: number of milliseconds between subsequent packets. This covers all packets, not just audio data.
• interframe_time: number of milliseconds between subsequent audio packets. This should be related to the block size and the samling rate of the sender. The formula is

  interframe_time in ms = (buffer length)/(sampling rate kHz)

  For example, if the sampling rate is 48kHz and the buffer size is 128 samples, then the expected interframe time is 128/48 = 2.67ms. If the max value is a lot larger than the expected value then you should use the Tuning graphs to find out what the network problem is.
• ping_latency: number of milliseconds delay between you and the other player. The larger that this is, the greater the latency you will hear.
• Jitter Buffer counters: a number of counters concern the jitter buffer. The jitter buffer is used to smooth over any inconsistencies in the timing of data reception. However the jitter buffer also introduces extra latency and is constantly adjusting to achieve a compromise between quality and latency. Generally the jitter buffer will get larger when lots of data is being missed and smaller when the datastream is highly reliable.
  • jitter_cur_prefetch: this is the number of samples that the jitter buffer attempts to contain in order to maintain the desired sound quality. This will vary with network conditions.
  • jitter_cur_fill: this is the actual number of samples currently in the jitter buffer. It will usually be slightly below the jitter_cur_prefetch value.
  • jitter_cur_underflow: this should usually be 0 and will indicate how many samples the audio loop needed that the buffer was not able to provide.
  • jitter_discard: this indicates how many samples were discarded because they arrived to late to process
  • jitter_burst: sometimes a large amount of data will arrive at once, usually after a gap in reception. Most of this data will be too late to be useful. This value describes how many samples are in the data bursts.
• packets_filled: when there is audio data missing the audio processor will "make up" audio to best match what it thinks should be coming. This counter says how many frames (not samples) of audio data have been simulated in this way.

Timers (all values are percentage of available time)

• Critical Audio Cycle: time spent in the main audio loop for critical audio functions. This should never be above 30%.
• Non Critical Audio Cycle: time spent in the main audio loop for non critical audio functions. This should never be above 5%.
• Audio Cycle: total time spent in all parts of the main audio loop (this may be slightly more than the sum of the previous two timers)
• Encoder Timer: time spent encoding audio data for transmission.
• CPU usage: total CPU usage for audio processing. Note that this may be lower than the amount of time in the previous timers as there may be some wait periods in the audio loop.