logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·30.10.26
← Back to news

ETH-68: Ethernet Audio Interface for Linux

Original article
naturalsystems.io|205 points|131 comments|by chabad360|Oct 7, 2026

ETH-68: A High-Performance Ethernet Audio Interface for Linux

The ETH-68 is a professional-grade audio interface designed specifically for the Linux ecosystem, prioritizing extreme low latency and modular scalability.

🛠 Technical Specifications

The hardware is housed in a standard 1U 19-inch rack chassis and features the following:

  • I/O Capabilities:
    • 6 balanced line-level inputs (1/4" TRS).
    • 8 balanced line-level outputs (1/4" TRS).
  • Audio Quality:
    • Powered by the Burr-Brown PCM3168A codec.
    • Supports sample rates of 48 kHz and 96 kHz.
  • Connectivity:
    • DIN MIDI ports.
    • Ethernet for audio transport.
  • Internal Logic: Runs custom bare-metal firmware on an STM32H7 microcontroller, emulating a netJACK1 master endpoint.

💻 Software Integration

The ETH-68 is designed to integrate seamlessly with modern Linux audio servers. Traditional USB drivers are replaced by network-based transport.

Using with JACK

To establish an audio stream, initialize the JACK server utilizing the netone backend:

jackd -d netone

Workflow:

  1. Launch the server as shown above.
  2. Once the first capture packet arrives from the ETH-68, JACK automatically generates IO ports corresponding to the physical hardware.
  3. Open any JACK-compatible application and route the signals.

Using with PipeWire

For those using PipeWire, the pw-eth68 client provides a direct connection. This client mirrors the behavior of the JACK netone backend.

Workflow:

  1. Run the pw-eth68 client.
  2. Connect your PipeWire-aware applications to the newly available ETH-68 IO ports.

⏱ Audio Latency Analysis

Definition: Audio Latency refers to the total time an audio signal takes to travel through the combined hardware and software layers.

This delay is caused by digital filter group delays within the codec and buffering at both the software and hardware levels. If latency is too high, musicians will notice a lag between a MIDI trigger and the resulting sound. Generally, the human perception threshold for this delay is between 5 ms5\text{ ms}5 ms and 20 ms20\text{ ms}20 ms.

Performance Metrics

Using a loopback cable and jack_delay, the ETH-68 achieves a round-trip latency of 3.620 ms (at 48 kHz / 64 samples).

Round Trip Latency Comparison Table

Buffer Size48 kHz (ETH-68)96 kHz (ETH-68)48 kHz (RME HDSPe AIO Pro)96 kHz (RME HDSPe AIO Pro)
322.288 ms1.148 ms——
643.620 ms1.814 ms3.62 ms2.14 ms
964.954 ms2.480 ms——
1286.287 ms3.147 ms6.28 ms3.48 ms
25611.621 ms5.814 ms11.62 ms6.14 ms

Notes:

  • JACK measurements were performed in synchronous mode: jackd -S -d netone.
  • pw-jack jack_delay yielded identical results for the PipeWire client.
  • Verdict: The ETH-68 matches the RME card at 48 kHz and actually outperforms it by 0.33 ms0.33\text{ ms}0.33 ms at 96 kHz.

⛓ Multi-unit Synchronization

The ETH-68 is highly scalable. You can link multiple units to expand your channel count without increasing the round-trip latency.

How Synchronization Works

The system employs a two-step synchronization process:

  1. Clocking: A high-frequency (HF) clock is generated by a "Master" unit and distributed to "Slave" units via BNC daisy-chaining.
  2. Alignment: The eth68ctl.py tool sends a UDP broadcast sync command to null the sample offset.

The synchronization precision is roughly ±1\pm 1±1 sample, which at 48 kHz is: Offset≈20.8 μs\text{Offset} \approx 20.8\ \mu\text{s}Offset≈20.8 μs

Data Handling

Because the netjack protocol isn't natively designed to merge multiple masters, a proxy is required for JACK users:

  • eth68proxy: This application merges multiple capture packets into one large netjack packet and splits playback packets for distribution to each unit.
  • PipeWire: The pw-eth68 client handles this internally; therefore, no proxy is needed.

Verification: Oscilloscope tests using a sawtooth wave from Reaper showed waveforms aligned to less than 1 μs1\ \mu\text{s}1 μs (or 1/20th1/20\text{th}1/20th of a sample).

Oscilloscope showing two synchronized sawtooth waves


⚙️ Processing Latency

Definition: Processing Latency is the duration required to complete the processing of a single audio buffer.

If this time exceeds the deadline, an xrun (underrun/overrun) occurs, causing audible pops or clicks.

Ways to minimize processing latency:

  • Optimize the host OS for real-time responsiveness.
  • Upgrade to a higher-performance CPU.
  • Tune network priority.

Debugging with LATMON

The ETH-68 includes a hardware debugging feature called LATMON, which outputs a 3.3V3.3\text{V}3.3V digital signal via a rear BNC connector.

LATMON Signal Logic:

  • HIGH: Triggered the moment capture data enters the DMA buffer.
  • LOW: Triggered once the playback data has been copied into the playback DMA buffer.

The width of this pulse provides a precise measurement of the total processing cycle, accounting for the microcontroller's delay and network transport.

LATMON signal on oscilloscope