How much bandwidth is used? What connectivity do I need?
For some examples of bandwidth used refer to the “Bandwidth examples” section in this guide. In general, 1GbE between
switch and device should sufficient for many audio applications, 10GbE for SD; HD and 3G video and higher bandwidths
(25, 40, 50, 100GbE) for many video streams and 4K resolutions.

What cabling shall I use?
For short distances you can use copper cables (CAT6 or better) for 1GbE. For other connections we recommend fiber;
multimode vs. singlemode depends on the distance you need to cover.
For short distances and higher bandwidths (10GbE+) we recommend the use of Active Optical Cables (AOCs) to reduce
cabling cost.

Can I combine multimode and singlemode SFPs?
For every connection only one type of SFPs can be used. A multimode SFP on a sending device needs multimode fiber
and a multimode SFP on the receiving device. However, if a device offers multiple SFP connections, you can mix multimode
and singlemode as long as the individual connection uses only one.

What multicast scheme shall I use?
We recommend using the administratively-scoped multicast range as described in IETF RFC2365 ( That
should avoid collisions with other multicast addresses used in e.g. routing protocols.
In order to structure your multicast range, apply a logical pattern, e.g. separating building areas or essence types (Audio,
Video, Data).
Also take a look at the section “Multicast Address Considerations” in this guide.

Do I need to worry about oversubscription?
Oversubscription describes the situation that a link, either between a device and the switch or between switches, has more
data to transport then it has capacity. In the case of time-critical data such as audio and video an oversubscription usually
means loss of signal and should thus be avoided. At the moment this requires careful network design. In the future more
advanced network control mechanisms such as Arista MCS, Cisco DCNM, et.al. will handle oversubscription scenarios is
a better way.


Which switch types does Lawo support?
The networking guide lists a number of switches we have worked with in various projects. The list also details whether the
switch has been used for audio or video and whether was used with PTP E2E or Boundary clock. This list is updated with
the guide.

Which switch types does Lawo recommend?
The switch requirements vary a lot with the application, size of the system and the potential integration into an existing
infrastructure. Considering these variables, we cannot recommend a particular switch model, but we are happy to discuss
the requirements after understanding the concrete needs.

Can you provide switch configs?
The switch configuration equally varies with the application, size of the system and the potential integration into an existing
infrastructure. We thus cannot provide more than the configuration examples listed in this guide. For more details, please
contact your local LAWO representative to discuss a solution that meets your specific needs.


Does Lawo support SMPTE ST2022-7 redundancy?
Most of Lawo’s equipment supports essence stream redundancy according to SMPTE ST2022-7.


What is the difference between the One-Step mode and the Two-Step mode in PTP?
For almost every PTP message that is exchanged between the master and the slave the timestamp can either be placed
directly into the message (one step) or a separate message containing the time when the first message was sent can be
transmitted (two step). Since the PTPv2 standard IEEE1588-2008 defines that slaves must be able to cope with both
modes there is no need to run all PTP devices with the same mode.
A more detailed explanation can be found in the blog of the PTP equipment manufacturer Meinberg:

Do I need PTP or can I work without it?
In IT networks PTP replaces the known synchronization methods such as Black Burst, Tri-Level or Word Clock and the
new SMPTE standards such as ST2110 mandate the use of PTP for essence synchronization. It is perfectly suited to
provide phase-accurate audio and video.
Many Lawo products are still capable of using the traditional synchronization methods, but we recommend to complement
existing infrastructures by PTP – which, with the correct synchronization equipment can run alongside e.g. the established
black burst.

Which PTP Grandmasters do we work with?
The networking guide lists a number of PTP Grandmasters we have worked with in various projects. This list is updated
with the guide.

How many Grandmasters do I need in a system?
As with traditional synchronization methods you need multiple generators, if you need redundancy. We recommend using
at least two Grandmasters.
If you use PTP in a redundant network setup (SMPTE ST2022-7), each Grandmaster should be connected to both networks
in order to avoid different times in the two networks (e.g. in case only one GM loses its GPS connection).

My Grandmaster does not support enough clients / how do I scale PTP?
Scaling PTP requires careful system design and adjustment to the application. However, speaking generally, you can use
PTP boundary clock on the switch (if supported). Then, the only client to the Grandmaster is the switch, which in turn
handles all other clients. Please bear in mind that there are also limits on the number of PTP clients a switch can support.
We also recommend the usage of PTP “hybrid mode” in which the DelayRequest/DelayRespsone messages between the
client and the Grandmaster are exchanged using unicast, thus lessening the load on the network and devices.


What is the Payload?
When you create a TX stream, the resultant network packet size is determined by three parameters which are
collectively known as the payload:

  • Frame Size = the number of samples per channel per network packet. The smaller the frame size, the moreoften the sender transmits packets. This results in a lower sending latency, but also a higher demand on the network's bandwidth. In LAWO devices, the frame size limits the number of TX streams which can be created by each device
  • Codec = the encoding method used for the digital audio. For example: L16 = 16-bit linear PCM; L24 = 24-bit linear PCM; AM824 = 24-bit linear PCM + 8-bit metadata, a non-standard format commonly used in AES/EBU
  • Channel count = the number of channels to be encoded: mono, stereo, 8-channel, etc

It is the payload which forms the bulk of the RAVENNA network packet size. In short, the more channels per stream, the bigger the payload.

To calculate the payload:
payload (bits) = channel count * bits per sample * number of samples per packet
e.g. the payload of a stereo stream using the L24 codec and frame size of 48 samples per packet = 2 x 24 x 48 = 2304

Do I need to stick to the Payload Presets?
No, but if you choose a custom setup, you MUST remain within the maximum network packet size, and understand how
the packet size affects the sending latency and network bandwidth requirements.

How does the Payload affect Latency?

The bigger the payload, the bigger the network packet size, and the longer it takes to assemble the data before each
packet is sent. This delay is known as the sending latency.
To calculate the sending latency:
Sending Latency (s) = Number of samples per packet (frame size) / sample rate
e.g. the sending latency of a stream using 48 samples per packet at 48kHz = 48 / 48,000 = 0.001s (1 millisecond)
Note that this figure is a nominal amount, as the actual delay will be subject to other factors such as jitter within the
sending device.

What is the Network Packet Size?
In the Ethernet standard, every network packet consists of two parts: header + payload

  • the header contains key IP information such as the address and is a fixed size (in the Ethernet standard) = 82 Bytes
  • the payload varies in size (see above)

The Ethernet standard defines a maximum network packet size of 1460 bytes, otherwise known as the MTU (Maximum
Transmission Unit). To comply with this, RAVENNA packets must not exceed the MTU. Therefore, it is important to know
the network packet size and which parameters affect it. When you create a TX stream in the RAVENNA Web UI, the
resultant network packet size is displayed. If the size exceeds the MTU, a warning appears, and you must take steps to
reduce it (see Creating a TX Stream).
Note: RAVENNA does not support jumbo frames.
The network packet size of a RAVENNA stream is calculated as follows:
packet size (bits) = header size (82 Bytes x 8) + payload (number of channels * bits per sample * number of
samples per packet)
e.g. the packet size of a stereo stream using the L24 codec and 48 samples per packet = (656) + (2 x 24 x 48) = 2960
Bits (or 370 Bytes).

What if the Network Packet Size is too big?
When you create a TX stream in the RAVENNA Web UI, the resultant network packet size is displayed in the “Source
Properties” window. If the size exceeds the MTU, a warning appears.
To deal with this, you will need to reduce one of the payload variables - for example, change the codec from L24 to L16,
or reduce the frame size if it is possible to do so (the frame size limits the number of TX streams).
Usually the easiest solution is to reduce the channel count and split the audio into multiple streams. This works well
providing phase coherence is not required.

Calculating the Bandwidth of a Stream
The math for the bandwidth calculation is as follows:
Nominal bandwidth per stream (Mbit/s) = packet rate (packets per second) * packet size (bits) * 10-6
The packet rate is the nominal number of packets per second sent out by a device = sample rate / number of samples
per packet.
For a stereo stream (24-bit, 48kHz, 48 samples per IP packet):
Packet Rate = 48,000 / 48 = 1000
Packet Size (Bits) = (656) + (2 * 24 * 48) = 2960
Therefore, the nominal bandwidth per stream (Mbit/s) = 1000 * 2960 * 10-6 = 2.96 Mbit/s (or around 3 Mbit/s)

How does the Network Bandwidth affect RAVENNA Streaming?
If the amount of streaming traffic gets close to or exceeds the network bandwidth, then you may find that audio streams
start to drop-out during playback.

How does jitter affect RAVENNA streaming?
Lawo's RAVENNA devices use a receiving buffer to deal with network jitter. For example, if packet 3 of an audio stream
arrives before packets 1 and 2, the buffer holds packet 3 until packets 1 and 2 have arrived; the packets can then be
played out in the correct order, resulting in a successful playout of the audio stream.
Too much jitter becomes a problem if the size of the receiving buffer cannot cope with the length of delay. For example, if
packet 3 has fallen out of the receiving buffer before packets 1 and 2 arrive, then an audio drop-out may occur while
playing out the audio stream.
Jitter can be introduced by any component in the network including the sending and receiving node. For example, in
Lawo products, the amount of jitter introduced by the dedicated RAVENNA IO cards is negligible compared to that of a
R3LAY PC (as RAVENNA streaming depends on other processes within the computer). Jitter is one of the main reasons
why the number of RAVENNA streaming channels are much lower for R3LAY software applications, than for a console
or router using dedicated RAVENNA hardware.

How long will it take for my audio stream to reach its destination?
It depends! Unlike a fixed point-to-point analogue or digital audio connection, the transport latency of an audio stream is
variable, and is affected by the frame size, sample rate and amount of network jitter.
The total delay from sender to receiver (known as the total connection latency), is calculated as follows:
Total connection latency = sending latency + network latency + receiving buffer

  • The sending latency is the nominal amount of time it takes the sender to assemble the data into network packets. This is affected by the number of samples per packet and sample rate (see sending latency). For example, the nominal sending latency of a stream using 48 samples per packet at 48kHz = 48 / 48,000 = 0.001s (1 millisecond)
  • The network latency in data networks is usually very short in local area networks; in wide area networks it depends on the distance travelled.
  • A receiving buffer is used in Lawo's RAVENNA devices to deal with network jitter. As a general "rule of thumb" the receiving buffer should be at least two times the sending latency.

For our example stream (using 48 samples per packet at 48kHz), the total connection latency would be just over 3

Ho do I integrate RAVENNA/AES67 and DANTE?
The integration of RAVENNA/AES67 and DANTE requires some special attention in the network structure / design. Please
get in contact with you Lawo representative for more details.

Continue ...