Ultrasound Engineering
NVIDIA Holoscan and Latency in Ultrasound OEM Development
How ultrasound OEM teams can distinguish frame throughput from latency, evaluate GPU-resident processing, and define meaningful pipeline measurements.
A high frame rate does not tell an ultrasound engineering team how old the displayed image is. A pipeline can deliver frames regularly while each frame spends time waiting for acquisition, processing or display. For ultrasound OEM development, throughput and latency need separate requirements and separate measurements.
New GPU platforms make this distinction more important, not less. Additional compute capacity can support a more demanding imaging workload, but the path from received echoes to the displayed image still has to be engineered and measured.
Frame throughput is not frame age
NVIDIA's Holoscan FAQ explains that multi-threaded and event-based scheduling can overlap work on successive frames. That can raise throughput without shortening the journey of an individual frame. Queues and dependencies between operators still affect its progress. This is a public software-framework example, not a measured result from an ALEVA ultrasound system. [1]
For an ultrasound product, first define the timing boundary. Does the measurement begin at the start of a transmit sequence, at receipt of an acquisition block, or when a software operator begins processing? Does it end when an image is ready in memory, submitted for rendering, or actually visible on the display? Those measurements answer different questions.
What current Holoscan tools can measure
Holoscan Data Flow Tracking measures messages along supported graph paths, including root-to-leaf latency, and reports minimum, average and maximum values. Its documented endpoints are operator execution boundaries. These do not automatically include acoustic acquisition or physical display scanout. [2]
Compatibility also matters. NVIDIA documents support for default connection configurations and warns that custom queue sizes or policies may not work as expected with tracking. An OEM team should verify the instrumentation against its chosen configuration rather than treating a profiling number as a complete system specification. [2]
GPU-resident execution is an option to evaluate
The current Holoscan documentation describes GPU-resident execution using CUDA Graphs to keep a compute pipeline on the GPU and reduce CPU-driven coordination. This provides an architectural option for compatible workloads. It is not a guarantee that every ultrasound pipeline will become faster. [3]
There are practical restrictions: the documented mode supports C++, uses a separate executor backend, and cannot be directly interconnected with GXF-backend operators or fragments. Existing host-side processing cannot simply be assumed to fit unchanged. These constraints belong in an early integration review, before selecting the platform. [3]
On the hardware side, NVIDIA's March 2026 IGX Thor announcement describes platforms intended for industrial and medical edge environments. That positioning does not establish regulatory clearance for a finished ultrasound device or suitability for every portable enclosure. Platform selection still needs a product-specific assessment. [4]
A useful latency specification for ultrasound OEM projects
The following is an engineering checklist, not a vendor benchmark or a disclosed ALEVA implementation.
Requirement | What the team should record |
|---|---|
Timing boundary | Named start and finish events, plus clock synchronization assumptions |
Imaging workload | Probe configuration, acquisition sequence, output dimensions and processing features |
Queue behavior | Buffer limits, backlog handling and the policy for incomplete or stale data |
Processing conditions | Concurrent tasks, transfer paths and sustained operating conditions |
Acceptance evidence | Throughput, frame age, latency distribution and dropped-data counts |
For example, a compounded B-mode frame and a Doppler ensemble depend on different acquisition histories. A faster processing stage does not remove the time required to collect those inputs. Tests should therefore use the intended imaging mode rather than a convenient video playback demonstration.
Averages alone are insufficient for the checklist. Include the largest observed delay over a defined test period and inspect outliers. Record the software version and processing settings so that a later optimization can be compared with the same workload.
Bringing the requirement into custom ultrasound development
For a custom ultrasound platform, define the latency budget alongside image-processing requirements, acquisition interfaces and thermal constraints. Then evaluate FPGA, GPU and embedded-software choices against that budget. Changing the processor without measuring the complete path can leave the actual bottleneck untouched.
ALEVA supports ultrasound OEM engineering across probe integration, acquisition electronics, beamforming and imaging software. These timing requirements can form part of the architecture discussion for a new development program. No use of Holoscan or IGX Thor in an ALEVA commercial product is asserted here.
Explore ALEVA ultrasound OEM development and beamformer engineering.
Sources
NVIDIA Holoscan FAQ — scheduling, throughput and latency, Q12/A12; reviewed 30 September 2026.
NVIDIA Holoscan Data Flow Tracking, measurement endpoints and supported configurations; reviewed 30 September 2026.
NVIDIA Holoscan GPU Resident Execution, execution model and restrictions; reviewed 30 September 2026.
NVIDIA IGX Thor platform announcement, 23 March 2026.