As an Audinate Dante Preferred Integration Partner with a dedicated Dante offshore development center, Cardinal Peak continuously explores methods to optimize audio product design and network performance for our clients. Recently, our engineering team developed a custom proof-of-concept test utilizing the Dante Embedded Platform (DEP) to rigorously assess network and hardware conditions.
DEP is a software implementation of Dante packaged as an OCI-compliant container, allowing developers to deploy Dante audio networking directly onto custom Linux-based edge devices. To ensure the reliability of these deployments, we built a diagnostic tool based on the DepLoopback SDK example designed to identify missing or corrupted audio packets, often referred to as a “glitch test.”
Contents
The Challenge: Ensuring Packet Integrity in Audio Networks
When streaming audio over a network, minor packet loss might go unnoticed by the end user. However, losing a significant number of audio packets creates a noticeable problem that degrades the audio quality and system reliability. Real-time digital audio processing requires predictable execution with minimal latency. Interrupts, kernel housekeeping tasks, and unrelated user space processes can all preempt processing threads at inopportune times, causing scheduling jitter and audio dropouts.
For developers and integrators, having a reliable method to test network stability is only part of the equation. We also needed to determine the maximum hardware capacity. Specifically, we wanted to see how many channels of audio an edge device like a Raspberry Pi can send and receive without dropping packets. We needed a reliable way to place a device on a network, run a continuous 24-hour test, and quantify exactly how well the network and the hardware handle heavy Dante traffic.
The Solution: A Custom DEP Loopback Architecture
To solve this, Cardinal Peak’s engineer extended the DepLoopback application found in the Audinate DEP examples package to create a custom loopback testing tool.
The system architecture and testing process were structured as follows:
- Hardware Setup: The core of the test runs on a Raspberry Pi 4. For external loopback testing, the Pi sends audio across the network to an AVIO USB-C device, which runs custom code to transmit the received audio back to the DEP endpoint. We also successfully tested internal loopbacks directly on the Pi.
Raspberry Pi 4 Dante Loopback Hardware Setup
Physical hardware setup featuring the Raspberry Pi 4 running the DEP loopback test.
Dante Controller Internal Loopback Routing
Dante Controller software configured for an internal loopback on the Raspberry Pi 4 DEP device.
Dante Controller External Loopback Routing
Dante Controller routing configuration for an external loopback utilizing the AVIO USB-C device.
- Packet Verification: The application generates audio packets on the fly, storing them in a First In, First Out (FIFO) buffer. Because the application handles generation and comparison entirely in software and drops the packets after verification, it does not interact with the physical soundcard. Consequently, ALSA (Advanced Linux Sound Architecture) bridging was not required for this specific glitch test.
- Routing and Synchronization: The system relies on the Dante Controller application to manage device routing and channel assignments. Because the Raspberry Pi’s NIC does not natively support hardware PTP (Precision Time Protocol), the DEP device is configured to run in PTP follower-only mode.
- Debugging Note: During early development, the system occasionally failed to synchronize upon startup. We discovered this was related to our custom application’s initialization sequence, which inadvertently left old audio samples in Dante’s external circular audio buffers. By modifying our code to explicitly flush these buffers upon startup, we achieved perfect synchronization.
- Data Output: Rather than measuring exact latency and jitter, which can be monitored directly via the Dante Controller software, the application tallies mismatched packets to identify dropped audio caused by either network instability or hardware processing bottlenecks. The terminal output provides granular diagnostics, including total run time, DEP resyncs, throughput (samples/sec), and FIFO high-water marks.
Dante Loopback Test Terminal Diagnostics
Diagnostic terminal output showing continuous run time, throughput, and mismatch statistics from the custom DEP loopback application.
Performance Results: Hardware Limitations and Channel Capacity
During the initial testing phase, the project yielded valuable insights regarding hardware performance limitations on edge compute devices. While the Dante protocol technically supports up to 128×128 channels, running high channel counts in a software-based container requires highly tuned hardware resources.
Initial attempts to run the code with 64 audio channels on the Raspberry Pi resulted in a standard connection timeout, preventing the application from attaching to the Dante buffers. To systematically find the hardware’s breaking point, our team conducted methodical scaling tests at 48kHz and 32 bits per sample without CPU isolation. We found that the Raspberry Pi could safely handle up to 10×10 channels simultaneously. Pushing the configuration to 12×12 or 32×32 caused the FIFO buffer to fill up and drop samples within a few minutes.
To push past this barrier, we implemented strict CPU isolation as recommended in the Dante Embedded Platform Programmer’s Guide. We isolated Linux OS processes and Ethernet interrupts to cores 0 and 1, dedicated core 2 to the tester application, and locked DEP to core 3.
However, even with isolated cores, a 32×32 configuration still experienced dropped samples. Our engineers dug deeper and identified the true bottleneck: I/O write speeds. The test program was running in a debug mode that actively saved the transmitted and received audio as .wav files to the Raspberry Pi’s notoriously slow SD card. This slow disk access bogged down the program, causing the FIFO overruns.
By disabling the .wav file writes and maintaining the CPU core isolation, the Raspberry Pi successfully ran a 64×64 channel configuration indefinitely with zero dropped packets.
Dante Embedded Platform (DEP) Glitch Test: 64-Channel CPU Isolation Results
Terminal output showing a successful 10-minute run at a high channel count with zero mismatches, utilizing taskset for CPU core isolation.
Pushing the Limits of the Raspberry Pi
This isn’t the first time Cardinal Peak has pushed the Raspberry Pi to its edge computing limits. In another recent proof-of-concept, we used a Raspberry Pi to build a smart cat detector powered by Amazon Kinesis Video Streams (KVS).
Much like the Dante loopback project, the KVS cat detector required optimizing a resource-constrained Pi to handle heavy streaming workloads—in that case, processing live video frames through a machine learning object detection model. Whether managing 25-million parameter PyTorch models for video or ensuring microsecond-level PTP clock synchronization for Dante audio packets, our engineering team excels at navigating the bottlenecks of edge hardware to deliver reliable, real-time performance.
Deep Expertise in PTP and Audio Synchronization
Our success in debugging the Dante loopback synchronization is rooted in Cardinal Peak’s extensive experience with complex network clocking protocols.
In a recent automotive embedded audio engineering project, our team tackled severe audio instability caused by clock drift across a vehicle’s Time-Sensitive Networking (TSN) framework. Just as Dante relies on Precision Time Protocol (PTP) to align packets, the automotive system required microsecond-level precision across a dashboard, network switch, amplifier, and noise-canceling subsystem. By refining the PTP algorithms, reworking interrupt handling to prevent race conditions, and introducing real-time clock corrections, we extended the automotive system’s continuous uptime from a mere two hours to ten days without a single buffer overflow or dropout.
Whether we are isolating CPUs for Dante audio routing or rewriting PTP algorithms for an automotive network, Cardinal Peak brings the low-level embedded software expertise necessary to make networked audio systems perfectly reliable.
Optimizing Your Dante Audio Product Design
Thoroughly testing network stability and hardware limitations early in the development cycle is essential for delivering robust AV-over-IP products. Custom diagnostic tools, like this DEP loopback architecture, allow engineering teams to identify processing bottlenecks, validate CPU isolation strategies, and guarantee packet integrity before hardware goes into production.
Whether you are evaluating the Dante Embedded Platform for a new device or need to troubleshoot packet loss in an existing AV-over-IP network, Cardinal Peak can help. As an Audinate Dante Preferred Integration Partner, we leverage custom accelerators and deep embedded software expertise to reduce technical risk and speed up your time-to-market.
Contact us today for an expert consultation to discuss your audio product design and see how our embedded engineering services can ensure your next project is perfectly synchronized.
FAQs about DEP & Audio Network Testing
What is the Dante Embedded Platform (DEP)?
The Dante Embedded Platform (DEP) is a software-based implementation of Audinate’s widely used AV-over-IP solution. Packaged as an Open Containers Initiative (OCI) container, DEP allows manufacturers to deploy Dante audio routing natively on Linux-based edge devices—such as x86_64 or ARM architectures—without requiring dedicated Dante hardware chips.
How does loopback testing work in Dante audio networks?
Loopback testing in Dante audio networks works by transmitting an audio packet from a source device to a destination device, which immediately routes the exact packet back. The source device then compares the received packet against the originally transmitted data in a FIFO buffer to accurately identify dropped or corrupted audio frames.
How many Dante audio channels can a Raspberry Pi 4 support?
A Raspberry Pi 4 can reliably support up to a 64×64 Dante audio channel configuration when properly optimized. While a standard software configuration handles about 10×10 channels, implementing strict Linux CPU core isolation and eliminating slow SD card write bottlenecks allows the Raspberry Pi 4 to process 64×64 channels without dropping packets.
Why is CPU isolation necessary for Dante Embedded Platform (DEP) deployments?
CPU isolation is necessary for DEP deployments to ensure real-time digital audio processing with minimal latency. By using Linux kernel parameters to reserve specific CPU cores exclusively for audio workloads, developers prevent standard background tasks and hardware interrupts from preempting DEP threads, thereby eliminating scheduling jitter and audio dropouts.
What is an Audinate Dante Preferred Integration Partner?
An Audinate Dante Preferred Integration Partner is an officially vetted engineering services firm with proven expertise in designing, integrating, and testing Dante audio networking solutions. These partners help AV manufacturers accelerate time-to-market and reduce technical risk on both hardware chip implementations and software-based DEP deployments.