Fourier transform.engine plugin GUI not updating over Allen & Heath dLive gigaACE network

Bug Reports 🐛
1

I’m running into a strange networking issue with a Fourier transform.engine in an Allen & Heath dLive setup and I’m curious whether anyone has seen something similar.

My setup is:

  • dLive Surface + MixRack connected via gigaACE
  • Dante card in Surface
  • Dante card in MixRack
  • Fourier transform.engine
  • KLANG
  • MacBook running transform.client and Dante Virtual Soundcard

Originally, Dante/control were on the same 192.168.1.0/24 network.

The problem is very specific:

When I connect the MacBook directly to the MixRack NETWORK port, transform.client works perfectly:

  • plugin control works
  • meters update
  • plugin GUIs move correctly
  • visual feedback is normal

When I connect the MacBook to the Surface NETWORK port, control still works, but the plugin GUIs / meters stop updating properly.

I can move parameters and hear the changes, but the visual state in the plugin window becomes stale or frozen.

The same happened when I connected through the Surface Dante card with the Dante Internal Network Bridge enabled.

Dante audio and clocking are completely stable, including audio through the Fourier engine.

I also tested with:

  • DVS stopped
  • Dante Controller closed
  • Mac connected directly to the normal Surface NETWORK port

The issue remains.

Ping from the Surface side to the engine is also clean:

  • 0% packet loss
  • roughly 1–2 ms RTT

I then made packet captures.

Direct connection at the MixRack shows a large, bursty UDP stream from the transform.engine to the Mac, with lots of packets around 1088 bytes.

Example:

192.168.1.209:50382 → 192.168.1.234:64887

UDP length 1088

The source/destination ports are dynamic between sessions.

Over the Surface → gigaACE → MixRack path, normal TCP control and lower-rate UDP traffic still pass, but the large UDP bursts appear incomplete / disrupted.

This matches the real-world behavior very closely:

Control OK

Audio OK

Engine reachable OK

GUI / meters NOT OK

So at the moment my suspicion is that the transform.client GUI / visual feedback uses a fairly bursty UDP stream and that the dLive/gigaACE network tunnel does not handle this traffic transparently enough.

I’m now testing a cleaner setup with Dante and control completely separated:

Dante network:

Fourier PRIMARY

KLANG Dante

dLive Dante cards

DVS

Control network:

Surface NETWORK

gigaACE

MixRack NETWORK

Fourier CONTROL

KLANG CONTROL

with the Internal Network Bridge on both dLive Dante cards disabled.

Has anyone successfully run Fourier transform.client through the dLive Surface/MixRack gigaACE control network?

And more specifically:

  • Is there a known bandwidth/burst limitation for generic Ethernet traffic over gigaACE?
  • Has anyone seen UDP-heavy applications behave like this?
  • Is the dedicated Fourier Control port the recommended way to run transform.client in a dLive environment?
  • Any QoS, MTU or network settings that helped?

I have PCAPs from both the working direct-MixRack connection and the failing Surface/gigaACE connection if anyone wants to dig into them.

2

I repeated the packet capture while actively using the plugin GUI. Directly connected to the MixRack, all segmented Fourier UDP GUI frames arrive complete (533/533 and 89/89 in the two main streams). Over the Surface → gigaACE path, approximately 19–20% of these frames are incomplete, with large contiguous ranges of UDP segments missing.

Since the same setup works perfectly when the Mac link is manually forced to 100 Mbps and even 10 Mbps, and also works over Wi-Fi, this does not appear to be a raw bandwidth limitation. It looks much more like burst packet loss / queueing within the gigaACE tunneled network path.

3

Update: I’ve now done quite a bit of troubleshooting together with Allen & Heath support, and Fourier are also involved.

The issue is very specific: when my Mac is connected directly to the MixRack NETWORK port, Fourier transform.client works perfectly, including real-time plugin GUIs and meters. The same is true even when I manually force the Mac Ethernet adapter down to 100 Mbps and even 10 Mbps, and it also works over Wi-Fi.

When the Mac is connected to the Surface NETWORK port, so that the control traffic has to cross the gigaACE tunneled network to the MixRack, parameter control still works and the engine state is correct, but plugin GUIs/meters no longer update properly in real time. Closing and reopening the plugin immediately shows the correct current state again.

Packet captures with active plugin GUIs also show a clear difference: directly at the MixRack, Fourier’s segmented UDP GUI traffic arrives complete, while over the Surface → gigaACE path around 19–20% of those GUI frames are incomplete, often with larger contiguous groups of segments missing.

So far this seems to rule out raw bandwidth, DVS, general Dante load, the MixRack Dante Internal Network Bridge itself, basic IP connectivity, and Wi-Fi/latency as the cause.

Allen & Heath explained that tunneled Ethernet traffic is fitted into the gaps between prioritised gigaACE audio frames rather than being handled like normal switched Ethernet, so bursty traffic may potentially queue differently. They have forwarded the case to Fourier, and both Allen & Heath and Fourier support are currently looking into it.

This is also quite relevant with the upcoming native A&H integration for gigaACE, DX and TCP/MIDI. For many dLive setups it would make much more sense to keep the Fourier engine at the MixRack/stage side, together with the audio I/O, rather than having to place it at the Surface/FOH side just to get reliable transform.client control. So ideally the upcoming integration should allow a Fourier engine located at the MixRack to be fully and reliably controlled from FOH across the dLive system.

At this point the working theory is that the issue is related to how the gigaACE tunneled network handles Fourier’s bursty real-time GUI UDP traffic, rather than a simple bandwidth limitation.

2 Likes
4

The 100 Mbit detail is the most interesting part of your report, and I think it points away from bandwidth and toward burst shape, which matches what A&H told you. Forcing the Mac NIC to 100 Mbit doesn’t reduce how much data the client sends, it just spreads the same frames out in time, so the tunnelled path never sees a full-rate gigabit micro-burst it has to squeeze into the gaps between audio frames. Segments that get dropped in contiguous groups usually mean a queue filling and tail-dropping, not random loss.

A couple of things you could test that would separate “burst pacing” from “something specific to the tunnel”:

  1. Put a small managed switch between the Mac and the Surface NETWORK port and leave the Mac at gigabit, but apply an egress rate limit (say 100–200 Mbit) or simple shaping on the port facing the Surface. If that fixes the GUI while the Mac link stays gigabit, it is pacing, not the NIC negotiation.
  2. Try to reproduce without Fourier in the picture at all: iperf3 in UDP mode across the same Surface to MixRack path, with a bitrate high enough to be bursty, and watch the lost/out-of-order counters. Then repeat directly at the MixRack. If iperf shows the same pattern, you have a clean, vendor-neutral repro to hand both support teams, which usually speeds things up a lot.
  3. Check whether lowering MTU on the Mac interface (1400ish) changes anything. Your capture shows 1088-byte UDP payloads, so you are probably not fragmenting, but if the tunnel adds encapsulation overhead somewhere it is a cheap thing to rule out.

On your actual question about placement: keeping the engine and the control connection on the MixRack side and treating the tunnelled gigaACE path as control-only has been the more predictable arrangement in the setups I’ve read about, precisely because it keeps the high-rate GUI traffic off the tunnel. Your split Dante/control plan looks right to me, but I would keep expectations low that it fixes this specific symptom on its own, since the failing path is still the tunnel.

Also worth saving your two PCAPs with clear names before you change anything else, since a before/after pair on the same firmware is far more useful to support than a new capture later.

5

Thanks Helen, that explanation makes a lot of sense and the burst pacing theory seems to fit the captures very well.

I’ll try the managed-switch shaping test when I get a chance, as that should indeed be a good way of separating link speed from actual packet pacing.

The main reason I’m particularly interested in getting the tunneled path working reliably is the practical dLive use case. In many clubs and smaller touring environments I can realistically rely on one CAT line between FOH and stage for gigaACE, but not on having a second dedicated Ethernet/Dante line available.

Ideally I would therefore keep the transform.engine in the stage rack next to the MixRack and audio I/O, while controlling it from FOH through the existing dLive network. Moving the engine to FOH would solve the GUI issue, but it means moving the Fourier audio path to the Surface side as well, which is less attractive from a system-design perspective.

So for me the interesting question is whether this is something that could potentially be addressed either on the Fourier networking side (e.g. less bursty/paced GUI traffic) or as part of the upcoming A&H integration. If transform.client could work reliably across the existing gigaACE control tunnel, the whole dLive/Fourier integration would become much more practical for touring setups where a second FOH–stage network line simply isn’t guaranteed.

I’ll keep the PCAPs from both the working direct-MixRack connection and the failing gigaACE path and can provide them if useful.

1 Like