SoundGrid 301 Part 5: Latency & Buffers in a SoundGrid System


Please note: Completing SoundGrid 201 is a prerequisite to taking the SoundGrid 301 test.

Any digital audio system is comprised of different sets of buffers that deliver the audio from one point to another. These buffers introduce latency to the audio signal path.
An example of such a buffer would be Analog-to-Digital conversion. This process involves a buffer used to create the digital signal, and this process introduces latency.
Another example is plugin processing. Some plugins reserve a small buffer for pre-process calculations. This buffer introduces latency when running audio through the plugin.
Check the latency of any Waves plugin here.

Types of Buffers

The SoundGrid protocol uses three main buffers to deliver and process audio over the ethernet network:

  1. SoundGrid server buffer

    Determines the number of samples used to complete a round trip from the I/O device to the SoundGrid server and back to the I/O.

    This buffer is set in the SoundGrid host application’s interface.
  2. Network driver buffer

    Determines amount of audio samples used to deliver the audio from the ASIO/Core Audio driver to the SoundGrid network.

    This buffer is also set in the SoundGrid host application’s interface.
  3. ASIO / Core Audio Buffer

    Determines the amount of audio samples used to deliver audio from the DAW to the I/O device via the ASIO/Core Audio driver.

    This buffer is set in your DAW settings.

With these two components, you have the basis of a SoundGrid system that can network audio between hardware devices as well as software devices. However, this setup does not provide low-latency monitoring as there is no SoundGrid DSP server connected.

The SoundGrid network stamps all frames it generates on the network and assigns a timestamp to each frame. This lets us:

  1. Trace every frame on the network to know if there are any drops or out-of-sync issues; and
  2. Measure your total latency by using this process.

SoundGrid is a sample-accurate system, it can alert a user if there is a drop of any frames, or if any frames are missed, indicating there is an issue that needs your attention.

When a SoundGrid audio interface sends a frame, it stamps that frame with a timestamp. It then sends it across the SoundGrid network. When the frame is sent to the DSP server, that is where the audio is processed. The frame is then sent back to the network, and then back to the I/O.

If this process happens under the SoundGrid server buffer time, it will be completed successfully. If for some reason things take longer, the result will be an audio dropout. If you experience dropouts, you should increase the SoundGrid server buffer size, or remove some plugins.

Switches & Distances Between Devices

Planning the distances between devices on a SoundGrid network is an essential part of being able to plan what type of switch will be needed. The distances for cabling listed on this page are there to help you make sure you plan and configure your setup accordingly.

The “main” switch is the switch that is closest to the SoundGrid I/O that is defined as the system clock master. The SoundGrid DSP server should be connected to this switch, not to other daisy-chained switches.

The maximum distance we support for a network cable between your main switch and the SoundGrid DSP server is 32.8 feet (or 10 meters). The maximum distance between the main switch and the SoundGrid I/O is 328 feet (or 100 meters).

If you have cable runs that exceed these suggested distances, frames may not arrive on time and will potentially result in dropouts.

For distances longer than the above, you can use an alternative to the standard 1Gb network switch. View this page to see switch configurations that can extend your distance up to 984 feet, or 300 meters.