Skip to content

Tuning Windows UDP reception

If joinXS Recorder receives a stream on Windows but recordings contain gaps or damaged frames, start by increasing the network adapter's receive buffers. This page covers receiver-side tuning for JPEG XS video and audio carried over RTP/UDP; it does not resolve missing sources or blocked multicast traffic.

Before you begin

  • You need administrator permissions to change network adapter settings.
  • Identify the network adapter that receives the media stream, not the adapter used only for management or internet access. Record its model, driver version, and current settings before making changes.
  • Schedule a maintenance window and stop recording. Applying driver settings can restart the adapter and interrupt all traffic on it, including remote access.
  • Use a repeatable test with the intended stream bitrate, stream count, preview settings, and recording destination. Change one setting at a time and keep a baseline for comparison.

Choosing a network adapter

For sustained high-bitrate recording, prefer a dedicated professional PCIe NIC, such as an NVIDIA/Mellanox ConnectX-5, over a low-cost USB-C Ethernet adapter or dock. USB adapters can be more susceptible to receive drops under load due to shared USB bandwidth, driver limitations, or limited receive-buffer and RSS options. Connector type and advertised link speed alone do not establish suitability: confirm Windows driver support and test the exact adapter, host, and stream workload, even with a professional NIC.

Reserving CPU capacity for recording

Avoid running CPU-intensive applications while recording, and configure Windows power settings for maximum performance. Recorder and Windows network processing compete with other applications for CPU time. As the packet rate increases, there is less time to process each packet; scheduling delays can fill receive buffers and cause packet loss or recording dropouts, even when the network link has spare bandwidth.

Before recording:

  1. Close unnecessary applications and postpone heavy workloads such as video exports, rendering, software builds, and virtual-machine workloads until recording has finished. Account for background tasks as well as visible applications.
  2. In Windows power settings, select Best performance power mode or the High performance power plan, depending on the options available on the system. Avoid energy-saving modes during capture: reduced CPU performance and power-state transitions can leave less headroom for timely packet processing.
  3. On laptops, use mains power and ensure adequate cooling. Performance-oriented power settings increase power use and heat; thermal throttling can reduce the available CPU capacity again.

Validate the intended packet rate and stream count with these settings in place. Check per-core CPU usage, not just overall CPU usage: a busy receive-processing core can limit reception even when other cores are idle. Larger receive buffers can absorb brief delays, but cannot compensate for sustained CPU contention.

Live preview under heavy load

Live preview is designed to minimize its impact on recording performance. Under severe load, disabling live preview when it is not needed may still improve performance. Repeat the recording test with preview disabled to check whether it helps.

Increasing NIC receive buffers

Increase the NIC receive-buffer setting first. Microsoft recommends the maximum receive-buffer value supported by the adapter for receive-intensive workloads. In our Windows receive tests, reported NIC discards disappeared after increasing this setting on the tested adapter. Some RTP gaps remained, so this is not a guarantee of loss-free recording.

The network interface card (NIC) uses receive buffers to hold arriving packets until Windows can process them. A small receive ring can fill during traffic bursts or brief CPU scheduling delays, causing packets to be dropped before Recorder can read them.

  1. Open Device Manager, for example by running devmgmt.msc from the Windows Run dialog.
  2. Expand Network adapters, right-click the adapter receiving the media stream, and select Properties.
  3. On the Advanced tab, find Receive Buffers. Some drivers use a name such as Receive Descriptors; check the adapter vendor's documentation if the property is unclear.
  4. Note the original value, then select the maximum value supported by that adapter and driver.
  5. Select OK and allow any required adapter restart or system reboot to complete.
  6. Recheck the setting, confirm Recorder's receiving interface, and repeat the baseline recording test.

The value usually counts buffers or descriptors, not bytes or megabytes. Supported ranges and memory costs depend on the NIC and driver; do not copy a numeric value from another adapter. If the driver does not expose this setting, it may manage the buffers automatically or use a fixed allocation. Consult the vendor rather than adding registry entries.

NIC buffers are not socket buffers

This setting controls the adapter's receive resources. It is separate from the UDP socket buffer and application queues. Enlarging a socket buffer cannot recover packets already dropped by the NIC. TCP receive-window auto-tuning does not tune UDP reception.

Checking the result

Repeat the same workload after each change, for at least as long as it previously took for the problem to appear. Check the recorded media as well as receiver statistics; a clean preview alone does not establish a complete recording.

In PowerShell, list physical adapters to find the receiving interface:

Get-NetAdapter -Physical | Format-Table Name, InterfaceDescription, Status, LinkSpeed

Replace ADAPTER-NAME below with its Name. Run the statistics command before and after each test, and compare the counter increases rather than their absolute values:

$adapter = "ADAPTER-NAME"
Get-NetAdapterStatistics -Name $adapter |
    Format-List Name, ReceivedDiscardedPackets, ReceivedPacketErrors

An adapter restart may reset counters, so take a new baseline after applying settings. Counter availability and reporting depend on the driver. Zero adapter errors or discards do not prove that every packet reached Recorder.

Compare these observations:

Observation Next action
Adapter receive discards increase Confirm the larger receive-buffer setting took effect. Check the NIC driver, link capacity, and CPU load.
Adapter errors increase Check the physical link, cabling or transceivers, and switch-port counters.
Gaps remain without adapter counter increases Check the sender and switch for loss, and investigate Windows, application, and downstream processing limits.
Gaps occur only under heavier recording load Check per-core CPU usage, preview load, and storage throughput. Larger buffers cannot fix sustained overload.

Further tuning if gaps remain

Keep the larger receive buffers in place while evaluating the following settings individually. Available options vary by adapter, driver, and Windows version.

Setting Guidance
Receive-side scaling (RSS) Enable RSS where supported to distribute receive processing across processors, particularly with multiple streams. More queues do not necessarily spread a single UDP flow across cores. Check per-core CPU usage before changing queue counts.
Interrupt moderation Start with the driver's default or adaptive setting. Moderation reduces interrupt overhead but adds latency. Disabling it can reduce latency while increasing CPU load and worsening loss under load; retain a change only if the recording test improves.
UDP checksum offload Normally leave supported receive checksum offloads enabled to reduce CPU work. Change them only to investigate a documented driver issue or a measured regression.
Power management Keep the performance-oriented power settings active throughout recording. Recheck them after changing power sources or system power policies.
RSS processor placement / NUMA On multi-socket systems, follow the NIC vendor's guidance for processors local to the adapter. Avoid applying fixed CPU-affinity or processor-count recipes to unrelated hardware.

Do not enable jumbo frames as a receiver-only fix: MTU changes require coordination with the sender and network. Do not copy unrelated TCP, UDP-send, SMB, or registry settings from general tuning guides into a UDP receive configuration.

If a change increases loss, CPU load, or latency, restore its original value and repeat the test. For unresolved gaps, provide support with the Recorder and Windows versions, NIC model and driver version, stream bitrate and count, settings changed, test duration, counter differences, and relevant logs.

References