Suggestions please for 16-channel 24-bit digital audio recorder

Hi guys, sorry just seen your messages now - I have some progress to report. Firstly - the Behringer Ultranet signals are definitely just AES3-like (or SPDIF-like) PCM audio. There are two channels per RJ45 connection, running on the D+ and D- signals.

On my unit, the P16I, there's also DC power available on those connections. The data rate on each pair is approx 12.2MHz, comprising 32 bits data x 8 channels x 48kHz sampling rate - in other words 1.5 MBytes per second. Two pairs means you have 3.0 MBytes per second of raw data.

The 32 bit 'samples' comprise 24 bits of audio + 8 bits of framing. The framing byte is usually 0x01, but occasionally is 0x09, indicating a 'multiframe'. That's essential for locking on to the correct beginning channel. Effectively the true data rate seen by the WM8804 is like "stereo 192kHz".

The 24 bits of audio are in fact 20-bit, the LS 4 bits on my unit are always zero. Other devices such as X32 might have different ADCs and therefore behave differently. There is some information on my blog about this: .. sounds off again in need of an update. For my purposes I wanted to stream in the audio in real-time, and write it to some permanent storage. I settled on an XMOS StartKit as being the ideal thing to play with. You can see more about them here: Development Kits | XMOS These are very low cost, available from Farnell, RS etc.

I've written some code for decoding and storing the signals onto SD card. For the sake of simplicity I'm writing just the MS 16 bits of the signals. Currently I'm streaming in WAV format and it works. I can load the recorded signals into Sonar X1 or Audacity and the audio shows up nicely.

My code's freely available on GitHub here: GitHub - tuck1s/UltranetReceiver: Simple I2S receiver writing contents to SD card It's not perfect yet - there are many TODOs marked in the code. I'm also drafting a PCB to go with it here: GitHub - tuck1s/UltranetReceiverPCB: PCB layout of an Ultranet to XMOS Startkit daughter card

Note a few things: - We don't have 'permission' from Behringer, they will probably tell us it is a proprietary interface. However it's pretty simple to decode with a DSO, and everything done can be done external to the box. - The SDCard code I have used drives the SD card in 4-bit mode. For commercial use you need to sign up to the SD Card Association which costs at least $1000 - The FATFS code I've used is based on published open source, originally on ELM - Softwares and in the derived work here: https://github.com/xcore/sc_sdcard

If there is enough interest I would consider making PCB kits available, but this will take time..!
 
Last edited:
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).
Yes, you will need 2x WM8804's if you want to read all 16 channels. The PCB I'm working on will have two, plus an SDcard slot and some other spare I/O pins for connecting up e.g. DACs, realtime clock etc.
 
I have read countless times throughout many recording forums about the desire and need for a portable simple PCM audio recorder with AES or SPDIF interface (either multichannel or just stereo). There is one made by Sonosax that is so expensive it is inaccessible for most but even that is still bogged down with some analog i/o. There is also a plug on module by Zaxcom but this again is multiple thousands of dollars.

Field recordists all over the world regularly carry a complete recorder with lots of extra ADDA circuitry and weight just to use it's spdif input as a "Bit Bucket".

IMHO the first person to make a simple cost effective product that simply records high resolution AES digital audio streams and nothing else (could even simply plug in to AES xlr port) would help so many others and sell many of such a product.
 
Last edited:
Haven't check this thread since. Guess XMOS startkit could be used without any SPDIF encoder alone, there's the XMOS audio library with examples for that:

https://www.xmos.com/support/libraries?subcategory=Audio

Also regarding the WM8804, it will truncate the output to 20 bits by default in certain conditions, and user should set the WL_MASK bit in S/PDIF register to avoid that. All 24 bits output are needed to gain the 102 dB dynamic range.
 
Last edited:
Last edited:
I have read countless times throughout many recording forums about the desire and need for a portable simple PCM audio recorder with AES or SPDIF interface (either multichannel or just stereo). There is one made by Sonosax that is so expensive it is inaccessible for most but even that is still bogged down with some analog i/o. There is also a plug on module by Zaxcom but this again is multiple thousands of dollars.

Field recordists all over the world regularly carry a complete recorder with lots of extra ADDA circuitry and weight just to use it's spdif input as a "Bit Bucket".

IMHO the first person to make a simple cost effective product that simply records high resolution AES digital audio streams and nothing else (could even simply plug in to AES xlr port) would help so many others and sell many of such a product.

That's interesting. The XMOS CPUs have enough grunt to buffer and write 16 streams to a good quality SD card (e.g. SanDisk Ultra), which suggests a compact and portable solution, perhaps battery-powered, with relatively inexpensive BOM (even if external AES decoding hardware is used).

Mhelin do you know a good source of prototyping boards with CS8416 on them? I see there are eBay versions of 'LJM audio' boards but - if these are pirated - I would rather buy an original.
 
Last edited:
Mhelin do you know a good source of prototyping boards with CS8416 on them? I see there are eBay versions of 'LJM audio' boards but - if these are pirated - I would rather buy an original.

Don't know any with full access to all pins, there are DAC kits but it might be difficult to tap to I2S or I2C lines if you want use SW control.

How about the AKM receivers, I just ordered this kit:

AK4113 Digital Receiver Board SPDIF to I2S Converter Softwear Control + LCD | eBay

Wonder which receiver is used on P16-M if any (FPGA maybe)? Why can't XMOS processor decode reliably @192kHz. Maybe XMOS should be replaced by some other processor or FPGA? I'm sure that the cheap Altera kit could do everything needed:
ALTERA FPGA Cyslonell EP2C5T144 Minimum System Learning Development Board AS

Is the clock frequency (50 MHz) too slow, the Opencores SPDIF component suggests 100 MHZ clock for 192 kHz sample rate, but can the 50MHz clock PLL'ed (configured) to generate the 100 MHz clock (I guess).
It's though difficult to code (though XMOS isn't easy either). Too bad there is no S/PDIF receiver for Cypress PSoC's (5 LP for an example) though there is the transmitter so I guess it could be done.
 
Last edited:
Related to Ultranet protocol a patent application which is really odd, basically they apply patent for using S/PDIF or AES to transfer multichannel audio by marking the LSB of 24-bit word (actually it's the LSB of auxliarry information channel on AES3) by bit 1, for other channels it zero (so the data is actually 23-bit):

https://www.google.com/patents/US20130177158

Btw. MADI standard is actually quite similar to Ultranet in that the preambles are coded little bit differently to mark the frames, and data is otherwise transmitter as multiplexed stream. So Ultranet is like a poor man's MADI or MADI-X.
 
Interesting .. I wonder if Behringer have licensed that themselves (or own the company quoted on the patent).

Also, bit-stealing the LSB to provide a side-channel (for frame sync etc) is common practice in standard telephony PCM (such as T1, used to carry 24 channels). One would assume they would have checked the prior art there.
 
As far as I know the "patent" is just the application for a patent. Besides AES3 specifications tell that the aux bits in time slots 4 - 7 can be used for anything if not used to provide the the bits 20 - 23 in PCM audio. So the patent application is practically worthless.

Anyway, after being studied the AES3 specifications I think that Behringer just uses the aux audio bits for framing the eight channel. The preambles are used for the interface itself and are fixed (and besides follow the parity bit coding though are not using biphase coding themselves), otherwise the AES/SPDIF receiver couldn't detect the frames and subframes at all, or the start of the 192 frame, so you cannot use other patterns with them.

So in the stream there are only left the aux audio bits, the 20 audio bits and the status bits (validity, user, channel status, and parity bits), so that explains the fact that there are available only 20 bits for the audio data. The status bits are available from other output pins of the receiver chips, or can be accessed using SPI or I2C depending on the receiver implementation.

Nevertheless, it would be interesting to be able to see the data received before SPDIF receiver. It's NRZI decoded so it might be difficult to read, but I guess you could sample the stream as much as fits into memory of your scope or USB dongle (using the storage functions) and try locating the preambles and data received afterwards on computer screen. The NRZI preambles are listed on Wiki:
AES3 - Wikipedia
 
Gentlemen,

I'm very pleased to see that you guys are still pursuing this.

I'm the guy that wants to retrofit the Mackie SA1232's to behave somewhat like a pair of Turbosound IQ-series speakers, i.e. with an Ultranet input and passthrough. The passthrough output would be nice, but not strictly necessary.

For my application decoding only the top stereo pair, channels 15 & 16 would do, and I'd build two of these, one for each speaker.

It just occurred to me that if I can persuade a decoder/DAC board to sync properly to the single stream of data from one differential pair coming from a Magjack, then I may not even need any sort of CPU at all.

Can a CS8416 be persuaded to handle the format that Ultranet is sending on one pair?
 
Good question, I think if you can design a circuit with a serial comparator triggered by the raising edge of the LRCLK from SPDIF you might be able to generate a TDM sync pulse which you might need to delay, or delay the data line to be able to extract a stereo pair for a TDM supported stereo DAC. Use some circuit simulator for developing the circuit, shouldn't be that hard.
 
I too, am also interested in a hardware only version. The application is a "receiver" stage box that I can use with an X18 to run the monitors/mains. I'm happy to chip in to help someone build such a device, or just a single channel receiver with a 1-8 or 9-16 selector switch and an 8 position rotary to select th channel. That could be mounted inside a powered cabinet. I have some electronics experience, but digital electronics are a little beyond my capability
 
Hi all,

I have had some success capturing Ultranet on a Pi 3B following the excellent work of tuck1s. I'm using the AM26LV32 + WM8806, and a modified simple_card.c kernel module. I'm getting all 8 channels nicely by recording stereo 192kHz. Source is an X32 rack @ 48kHz.

I'm not sure how to sync to the first channel, or if I'm doing something wrong with the WM8806. It's in hardware control mode, and the control pins are set the same as in tuck1s' schematic.

The low 2 bits of the 24-bit audio word are usually 00, but a couple of times a second they burst into life for about 100ms and identify the channel pair (00=1/2, 01=3/4, 10=5/6, 11=7/8).

I thought it might be something I'm doing wrong with ALSA, but I can also see those bits coming and going on a scope. If I send audio down one channel and just strip out every 32-bit word which is > 0x300, I get crystal clear audio so I can be reasonably confident (?) that the WM8806 is set up properly.

It seems to me that those channel ID bits should be set all the time. I'm sure I could code around it as-is, but it seems wrong - Anyone know what's going on?
 
Hi guys,

This is very interesting topic. Did anyone marked success so far with extracting Ultranet channels directly to DAC without using any MCU/FPGA related stuff? Been investigating a bit, and:

- CS8416 seems suitable for extracting AES3 signal directly
- PCM1861 can decode 8 channel TDM stream directly to 8 DAC

What's seems now as a problem, is that LRCLK signal is not directly aplicable as TDM marker (for PCM1861). But I think this would be doable with some serial latch and logic gate to extract frame start bit from LRCLK transition from R to L channel.
PCM1861 expect 24 bits LSB, seems ignoring next 8 bits. This seems to be directly compatible with CS8416 output in AES3 direct mode.

What do you think? Is this a viable? Or a no-go?

Would be nice to have some sort of Ultranet smaller monitoring mixer, possibly with 16 outs (on 3.5mm jacks) to feed any mixer, with returns for two balanced / four unbalanced channels available via some RJ45 breakout boxes. Powered via USB (chargers everywhere).

T.
 
You much mean PCM1681 DAC (PCM1861 is a 2-channel ADC).

CS8416 has dedicated output pin for Z flag (RCBL pin in hardware mode) which could maybe used to locate the beginning frame using HW logics if it happens to sync with the protocol.

Receiver Channel Status Block (Output) -Indicates the beginning of a received channel status block.
RCBL goes high two frames after the reception of a Z preamble, remains high for 16 frames and then returns low for the remainder of the block. RCBL changes on rising edges of RMCK. Also used to set the serial audio port to master or slave at reset.


The C and U bits have dedicated output pins but those flags are not used in Ultranet as the LSB 4 bit values used were 0x01 and 0x09 meaning bits 0001 and 1001 for WM8804 decoded flags in "24 bit Left Justified With Flags" mode in which the flags are embedded into AIF output's 32-bit data. In CS8416 this mode is called "AES3 Direct" but it may differ from WM8804 a little bit:

A special AES3 direct output format is included, which allows the serial output port access to the V, U, and C bits embedded in the serial audio data stream. When using the part in AES3 direct-output format, the de-emphasis filter must be off (see Section 14.4 on page 38). The P bit, which would normally be a parity bit, is replaced by a Z bit, which is used to indicate the start
of each block. The received channel status block start signal is also available as the RCBL pin in Hardware Mode and through a GPO pin in Software Mode.


I guess no one has tested CS8416 yet, WM8804 works for software decoding.
WM8804 "flags" are (from bit 3 to zero) 192BLK,C,U and V. So it appears Behringer uses V bit to indicate frame and 192BLK to indicate subframe.

So I assume in AES3 direct mode with CS8416 the XMOS software has to use 0x09 for multiframe and 0x08 value for frame sync as the flags bit are V, U, C and Z (frmo MSB to LSB).