ACE Protocol Reverse Engineering

Allen & Heath
1

Hello together,

I have also recently acquired one of the iLive consoles and am a CS Student. I have also done some reverse engineering on the Ace protocol and the console in general. I have also written a small Linux app that can record the entire 64channels of ace audio, based on the aforementioned project. Last I was working on sending audio and figuring out the synchronisation issue, but I have hit a roadblock for now, since the Linux timer stuff is too slow for the required timing. You can look at some of my progress at This link, although I have not been able to upload all my discoveries yet.

Some other side notes, dSnake, DX And ace are very similar. ACE just has a flag bit in the sync word set. Other than that they are the same. And DX does the same just with two samples per frame of only 32 channels for a 69kHz sampling rate. Also the control data is different and probably the Mac addresses.

As for sync, it seems to be in the dropped trailer of the packets. In a correctly running connection of ACE, every 80th ±1 trailer is dropped. That is the mechanism I have been able to find, but I can not replicate it in Linux since timer_fd cannot handle 48kHz on my system. But for inspection you can use wireshark on a gigabit switch with the connection to the ace hardware limited to 100mbs duplex.

I also have some preliminary work on the control protocol, but I will not write about it for now.

And as far as hardware goes they used redboot on the main processors and a standard Linux pc for the touchscreen. And interestingly the MPC main processors are still supported by Linux. Other than that everything is just shift registers and spit, plus multiple FPGAs and 11 DSPs.

I’m really interested in this work and would be happy to help out where I can.

Cheers

1 Like
Recording 64 Channnel Audio from Allen&Heath ACE with only Linux
2

Hey! we used your reverse engineering to implement an ACE sender for the FPGA of the Behringer X32 in OpenX32. Really cool to have you here :+1:

We also struggle with the timing, but @chris optimized the VHDL and we have an internal prototype to test. Source is public available: OpenX32/fpga at main · OpenMixerProject/OpenX32 · GitHub

1 Like
3

Good to know! :smiley:

4

Well personally I don’t have any experience with vhdl, only with conventional programming. But on a quick look over your linked code I found no mention of the trailer. It’s supposed to be the first two bytes of the iso crc32 hash of the entire message. If you never send it, the second device will always accept your packets, but never sync up. Once you start sending the trailer you get the error light on your receiver console to blink or go solid depending on your timing. In the ideal synced state both devices will leave out the trailer after sending pretty much exactly 40 packets each. Also they will switch whoever is next to send the short frame. When they are not synced properly yet they might send them earlier or later. My best theory is that they use this mechanic to phase lock both device clocks. But I can’t explore that timing much more for now, since I don’t have an FPGA nor other fast enough means to interact with the protocol.

Also something of note, an sLink card will send a short frame every 40 frames when not connected, while the IDR will send one every 69 frames I believe. Also you can force an sLink card to ace mode by just changing the link to manual negotiation 100mbs duplex instead of 1gbs, even with gigabit enabled hardware.

1 Like