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

dLive dLive General Discussions
1

Hi all,

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.

Thanks!

2

GigAce tunnelled network is 100Meg.

Where is the Klang connected to? I’m assuming the Dante card in the mixrack.

Isaac P

3

Yes, exactly. The KLANG is connected to the Dante card in the MixRack, and the Fourier Primary port is on the same Dante network. The Surface and MixRack are connected via gigaACE, so the control traffic to/from FOH is currently relying on the 100 Mbps tunnelled network path.

4

Because the GigaAce network tunnel is limited to 10/100 speeds, logic tells me this 10/100 speed limitation is the problem.

To verify this, you could plug your computer into a different network plug (not part of the DLive system) that receives 10/100/1000 speeds. See if it works reliably at those speeds and then manually set the speed of the network port to just 10/100 and see if the result matches what happens when you plug into the DLive Surface. If it does, you can conclude that the problem is with any 10/100 network connection and not something that is DLive specific.

1 Like
5

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.

1 Like
6

Well good or bad I think it’s clear you found the problem - there is something going on with the GigaAce tunnel and this type of traffic. I doubt this is something that can be “fixed” in a timely manner, so I would plan on running a seperate network cable to FOH and not use the GigaAce tunnel for this purpose. I think that is the easiest (and probably only) solution.

I would urge you to submit an official “support ticket” with A&H via the support page on the main website. Hopefully this is something they can look into and possible fix in a future firmware update, but I suspect it happens infrequently enough that it probably isn’t going to be a top priority for them.

7

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