CUE/IO Automatic Benchmark

Benchmark is available in the CUE/IO navigation under Benchmark. It can be started only in the IDLE state. For the duration of the test, CUE/IO blocks parallel starts of RECORD, TIMECODE, PLAYER, Scheduler, network configuration, and restart actions. Cancellation is cooperative: test threads and audio processes are stopped first, then the IDLE Art-Net monitor is restored.

What the test does

For each selected level (1, 4, 8, 16, 32, 64, 128 universes), Benchmark generates deterministic 512-channel ArtDmx packets with an independent 1…255 sequence for each universe. Depending on the scenario, it:

• record_only — sends packets to a local UDP receiver and records them;
• player_only — creates a reference file and plays it to a local UDP receiver;
• full_cycle — records packets, then plays the exact file that was recorded.

RECORD, PLAYER, and Benchmark use one shared codec for the existing artnet.dat format: a 4-byte time value in milliseconds in network byte order, a 2-byte packet length, and the unchanged UDP packet (!IH + raw packet). The file format has not changed.

Data is compared by packet count, sequence, and SHA-256. CUE/IO also measures packet loss, Art-Net sequence errors, late Player packets, network-socket errors, CPU, RAM, temperature, free disk space, and test-file size. Global CUE/IO Art-Net/audio counters are compared as the difference between their start and end values, so earlier traffic does not corrupt the result.

Audio

When audio testing is enabled, CUE/IO uses the configured ALSA input device in the RECORD stage and the configured output in the PLAYER stage. Commands run without shell=True, with a fixed argument list, timeout, and centrally registered processes. The result reports ALSA buffer underruns (underrun) and overruns (overrun).

A software process start time is not a physical audio/DMX synchronization measurement. Physical offset can be confirmed only with an audio loopback and a shared PCM/DMX marker. When such a measurement is unavailable, the result contains audio_sync_measured: false, a warning is issued, and a safe universe count is not certified for the audio profile.

Result and safe universe count

• PASS — data matches, there are no losses/errors, and resource headroom is sufficient.
• PASS WITH WARNINGS — data integrity is preserved, but a sensor is missing, the test is short, or some headroom/measurement is insufficient for certification.
• FAIL — there is a data mismatch, packet loss, a sequence, network-socket, or audio error, or critical CPU, RAM, or temperature.

The API and saved result do not change these technical judgments. The user interface presents a completed test constructively: Benchmark complete, Recommended: N universes, and, when applicable, M universes exceeded the safe limits. An exceeded level is shown in amber rather than error red; red is reserved for a test process that itself failed or ended with an error. recommended_universe_count is the highest continuously completed full-cycle level with PASS or PASS WITH WARNINGS; if it has warnings, the user interface clearly states that it is not strict safety verification. safe_universe_count remains the strict certification field, while exceeded_universe_count identifies the first level that did not meet the technical requirements.

The safe internal universe count is determined only for the full_cycle profile and only as the highest continuous level starting at 1. Every verified level requires:

• exact agreement between the RECORD and PLAYER data;
• 0 packet-loss, sequence, network, and late-packet errors;
• CPU no higher than 85% and RAM no higher than 85%;
• a measurable temperature no higher than 70 °C;
• a test of at least 10 seconds at each level;
• when audio is enabled—0 buffer underruns/overruns, available devices, and marker-measured audio/DMX offset no greater than 10 ms.

The latest result is saved atomically to benchmark_data/last_result.json. Show files are not used or changed; temporary Benchmark files exist only in benchmark_data/tmp and are removed after the test, an error, cancellation, and startup.

Important network limitation

One Raspberry Pi's internal loopback Benchmark does not fully test the physical Ethernet PHY, cable, switch, network queues, Broadcast load, or external Art-Net nodes. It tests CUE/IO, the local operating-system UDP stack, storage, and the Pi's own resources. A complete physical Ethernet test requires a second device acting as an external Art-Net sender or receiver.