I would like to interface one of the Behringer: POWERPLAY 16 P16-I
with an ARM based single board computer with an SPI input (pretty much all of them do - from the Raspberry Pi to newer, more powerful ones).
The "Ultranet" output is apparently just 2x AES3 data streams over Cat5 cable (running 8 chans x 48kHz sampling rate on each stream): X32 User Net • View topic - The pm16-m protocol
So they are using 2x AK4114 digital interfaces, which seem to be obsolete (there is an AK4118 which maybe is a successor part, but seems hard to find).
Transformer isolation is used in this system, so thought I should do the same. Given the Cat5 interconnects used, the architecture I have in mind goes like this:
RJ45 "PoE" compatible MagJack --> 2x clock recovery --> 2x SPI inputs on ARM board
the MagJack could be something like:
SI-52008-F - STEWART CONNECTOR - SOCKET, 1 PORT POE GIGABIT MAGJACK | CPC
I would appreciate any comments, suggestions. Particularly if there are projects already going on that I could re-use, e.g. for the clock recovery.
with an ARM based single board computer with an SPI input (pretty much all of them do - from the Raspberry Pi to newer, more powerful ones).
The "Ultranet" output is apparently just 2x AES3 data streams over Cat5 cable (running 8 chans x 48kHz sampling rate on each stream): X32 User Net • View topic - The pm16-m protocol
So they are using 2x AK4114 digital interfaces, which seem to be obsolete (there is an AK4118 which maybe is a successor part, but seems hard to find).
Transformer isolation is used in this system, so thought I should do the same. Given the Cat5 interconnects used, the architecture I have in mind goes like this:
RJ45 "PoE" compatible MagJack --> 2x clock recovery --> 2x SPI inputs on ARM board
the MagJack could be something like:
SI-52008-F - STEWART CONNECTOR - SOCKET, 1 PORT POE GIGABIT MAGJACK | CPC
I would appreciate any comments, suggestions. Particularly if there are projects already going on that I could re-use, e.g. for the clock recovery.
.. just to add, I plan to try with the following interface module. The WM8804 seems to be a well regarded device for clock recovery.
WM8804 S/PDIF TOSLINK to IIS Converter I2S Codec Project integration DIY | eBay
WM8804 S/PDIF TOSLINK to IIS Converter I2S Codec Project integration DIY | eBay
There are various "digital snake" protocol existing in pro audio industry. One onf them was AutioTrail (AudioRail Technologies.). Anyway, it's not clear how the Behringer protocol works, I mean how they mark the frames in AES3 stream. AKM datasheets though suggest using the hardcoded preamble for non-PCM encoded audio bitstreams.
Anyway, SuperMAC data is "scrambled", DSP of FPGA is needed to convert data to TDM (SuperMAC internal format) or multiple I2S streams. Protocol also includes some error correction, and the cable also delivers the clock signals (so I assume these are used for framing).
SuperMAC | HyperMAC
Anyway, SuperMAC data is "scrambled", DSP of FPGA is needed to convert data to TDM (SuperMAC internal format) or multiple I2S streams. Protocol also includes some error correction, and the cable also delivers the clock signals (so I assume these are used for framing).
SuperMAC | HyperMAC
Last edited:
Thanks for your comments .. I've measured the signals coming out of the cat5 ports and confirmed some of the details already known here:
X32 User Net • View topic - The pm16-m protocol
Reproduced here for ease:
Pin configuration
Looking at the back panel of the x32 and counting 1-8 (left to right) we have
1: Ch 1-8
2: Ch 1-8
3: Ch 9-16
4: Vcc
5: Vcc
6: Ch 9-16
7: GND
8: GND
Vcc is 15 volts DC (pins chosen are similar to Power over Ethernet standard). This comes from an internal switch-mode PSU and is intended to power the P16-m external monitoring boxes. It's not stated how much current each connector is specified to source (there are six output connectors on the P16-i). The P16-m's can also be powered by an external PSU, and the back panel reads "12v 300mA". So it's probably safe to say that each P16-i output socket could provide around 4 watts. To be on the safe side, I'll not use the PoE power as it's probably not enough for a recording device with a hard drive.
One other thing to note, is that the P16m requires some power draw on the Vcc pins, to switch on the data outputs. Some experimentation found that 5k6 resistor from Vcc to GND does NOT switch it on; whereas a 2k2 resistor DOES switch it on. So the P16m is looking for approx 7mA current draw to switch on the outputs.
Each output (1, 2, 3, 6) is fed via half of a 74LVC245 octal buffer transceiver device, used in output-only mode.
twisted-pair cable is meant to have a characteristic impedance of around 110 ohms. I've terminating output 1-2 via a Magjack (i.e. transformer isolation) into 110 ohms. There I see approx 500mV pk-pk digital waveform. It looks fairly clean and nice.
Ok, fine. WM8804 may not be right part for the AES3 though. You would be better using CS8416.
Using a level converter you might want to first record (directly from the MagJact output using a simple resistor level converter with a series capacitor) the data to PC soundcard with bit perfect S/PDIF input supporting 24bit/192kz data to see if it's just pure PCM data (vs. non-PCM). It is possible that the framing information is embedded into audio data LSB and could be easily reverse engineered.
Using a level converter you might want to first record (directly from the MagJact output using a simple resistor level converter with a series capacitor) the data to PC soundcard with bit perfect S/PDIF input supporting 24bit/192kz data to see if it's just pure PCM data (vs. non-PCM). It is possible that the framing information is embedded into audio data LSB and could be easily reverse engineered.
Last edited:
24 bits*48000 smp/s*16 channels = 2.304 MB/s which means you should be able to store the data to Class 4 SD cards (4 MB/s). You could use some of the newest Cortex-M4 CPU's so the 4 watts would be more than enough to power a simple recorder.
One thing to note: the Behringer specifications for the P16 system tell:
Dynamic range : typical 92 dB
So it might be possible that the data is packed to for an example 24bit/96kHz frames, and possibly using DTS or DD decoding with real 16 bit DR (72 dB SNR + 20 dB headroom).
That is perfectly fine for monitoring application though. Might be one reason why they used the AK4114 part as it recognizes DTS automatically.
To see if that is a case please try connecting P16-I to you AVR (using level conversion to S/DPIF of course).
Dynamic range : typical 92 dB
So it might be possible that the data is packed to for an example 24bit/96kHz frames, and possibly using DTS or DD decoding with real 16 bit DR (72 dB SNR + 20 dB headroom).
That is perfectly fine for monitoring application though. Might be one reason why they used the AK4114 part as it recognizes DTS automatically.
To see if that is a case please try connecting P16-I to you AVR (using level conversion to S/DPIF of course).
Last edited:
Hi, thanks for your comments. According to the work done by roblof on the x32 user forum, the data format is simply 8 channels x 24 bits x 48k on each TD+- pair, encoded as a single 24/192 stereo interleaved stream. I have not got that far in verifying this myself yet.
Re. CS4816 vs WM8804 - (briefly) what aspects of the Cirrus part are more suitable for AES3? Is it a data format issue?
Do you know of a good source of prototype / dev board with the CS4816 (to reduce the need for tiny surface-mount-package soldering ..)
Re. CS4816 vs WM8804 - (briefly) what aspects of the Cirrus part are more suitable for AES3? Is it a data format issue?
Do you know of a good source of prototype / dev board with the CS4816 (to reduce the need for tiny surface-mount-package soldering ..)
I don't think roblof has verified anything. He is just guessing (" Could it be adat compatible?" - actually AES3/SPDIF and ADAT use incompatible coding systems, and AK4114 can handle the ADATA one). Problem is that of framing. You can obviously send 4x 48kHz data in 192kHz stream, but how do you know which channel is which one? AES3 is just a stereo channel. Dolby Digital (AC-3) instead packs 6 channel inside single stereo channel meaning it uses SPDIF framing. Ultranet might use something similar compression and packing into stereo frame system. That's why the lowish 92 dB dynamic range instead of that of converters (114 dB for the Crystal converters).
Btw. what are the main components on P16-I?
Btw. what are the main components on P16-I?
Last edited:
Here are some photos of the inside: https://www.dropbox.com/sh/n0wj548x6grdp9q/AADKnjD05nsViPGzStpUngTGa?dl=0
There are 8x stereo ADCs, these were AKxxx parts, my photo doesn't show the part numbers very clearly.
You can switch the inputs (in two banks of 8) to come from the analog inputs, or from ADAT optical inputs. There are 2x WaveFront AL1402G chips handling the ADAT inputs.
The main logic is an FPGA - Lattice LFXP2-5E.
The digital bus driver outputs are coming from 3 x NXP 74LVC245.
There are 8x stereo ADCs, these were AKxxx parts, my photo doesn't show the part numbers very clearly.
You can switch the inputs (in two banks of 8) to come from the analog inputs, or from ADAT optical inputs. There are 2x WaveFront AL1402G chips handling the ADAT inputs.
The main logic is an FPGA - Lattice LFXP2-5E.
The digital bus driver outputs are coming from 3 x NXP 74LVC245.
Inexpensive kit for the LFXP2-5E:
LFXP2-5E-B2-EVN - LATTICE SEMICONDUCTOR - KIT, DEV, XP2 BREVIA2 | Farnell UK
LFXP2-5E-B2-EVN - LATTICE SEMICONDUCTOR - KIT, DEV, XP2 BREVIA2 | Farnell UK
Ok. Noticed that Lattice XP2 devices have some kind of dual boot option, don't know how it works in practise but I guess you could configure the device without reprogramming the flash memory.
Regarding the data formatI'm pretty sure the compression Behringer is using is based to sub-band ADPCM (data is first filtered using 8-32 or so filter banks which are then ADPCM compressed to 1-3 bits each). It is almost the only algorithm available having low latency and decent (4:1) compression ratio. Might be Behringer has developed own prediction algorithm for it though, and propably use minimum phase filters for the filterbank implementation. AptX used with Bluetooth audio has almost the same specs (except for the latency which Behringer claim is less than 1 ms) anyway as you can see:
aptX Live® Audio Codec for Digital Wireless Microphones
Wish you luck. Obviously I hoped they didn't use compression, but regarding the application it's really the only way to go to keep the signal clean even in the most difficult electric conditions as on stage.
Regarding the data formatI'm pretty sure the compression Behringer is using is based to sub-band ADPCM (data is first filtered using 8-32 or so filter banks which are then ADPCM compressed to 1-3 bits each). It is almost the only algorithm available having low latency and decent (4:1) compression ratio. Might be Behringer has developed own prediction algorithm for it though, and propably use minimum phase filters for the filterbank implementation. AptX used with Bluetooth audio has almost the same specs (except for the latency which Behringer claim is less than 1 ms) anyway as you can see:
aptX Live® Audio Codec for Digital Wireless Microphones
Wish you luck. Obviously I hoped they didn't use compression, but regarding the application it's really the only way to go to keep the signal clean even in the most difficult electric conditions as on stage.
Last edited:
Some progress - I got the WM8804 eval. board hooked up, firstly to my Squeezebox Touch (with the 3rd party app to enable 'enhanced digital out' up to 192 / 24), and then to the P16-I.
Good news: In HW mode (no programming) it syncs up nicely with a 192k / 24 bit source. Here's the LRCLK and DOUT lines:
https://www.dropbox.com/s/hdycnlul0pmxirp/P1030496.JPG?dl=0
From the way the data is "dancing" in the LSB's, it looks like good old PCM to me.
Good news: In HW mode (no programming) it syncs up nicely with a 192k / 24 bit source. Here's the LRCLK and DOUT lines:
https://www.dropbox.com/s/hdycnlul0pmxirp/P1030496.JPG?dl=0
From the way the data is "dancing" in the LSB's, it looks like good old PCM to me.
I'm interested in retrofitting my older Mackie SA1232 powered speakers to have Ultranet inputs, like the new Turbosound IQ series. My first search turned up your thread here, and it looks like you got to a point in your project that is almost all of what I would need to accomplish.
Did you ever complete your project? Can you share the details?
Thanks!
Did you ever complete your project? Can you share the details?
Thanks!
I'm also quite interested in reading the Ultranet stream. The application I have in mind is to extract the current tempo from one of the audio channels which contains a click track, and slave my gear to that via MIDI.
Question for tuck1s: the WM8804 eval. board is only going to read one SPDIF stream, so you can only access 8 of the 16 Ultranet channels at once? (That would be enough for my purpose, but I'm interested in what solutions there are for reading all 16 channels).
Question for tuck1s: the WM8804 eval. board is only going to read one SPDIF stream, so you can only access 8 of the 16 Ultranet channels at once? (That would be enough for my purpose, but I'm interested in what solutions there are for reading all 16 channels).