After further investigation...

It seems that the I2S protocol is only standardized up to 12.288MHz, so I would absolutely need two I2S inputs on the computer to bring in all sixteen channels.

Furthermore, it appears that the Raspberry Pi only has one I2S input, but the BeagleBone Black/Green has a more flexible "McASP" interface on its Texas Instruments SOC, which has four parallel ports each of which can be configured to be an I2S input or output, among many other formats.

On top of that, I have spotted your Teleporter product, which might even solve the differential receiver problem for me, as long as it is electrically compatible. Unfortunately, I cannot find a schematic for it anywhere on your site, but the blurb about the Transporter in the Buffalo III Integration Guide implies that it's a completely general TTL-to/from-Cat5 interface.

In this case, I am hoping that I could configure two of its four channels as inputs, to receive the two AES3 24/192 streams from the Ultranet Cat5 cable and pass them as TTL to the inputs of two of your WM8804 boards, which would each the decode their eight channels to 8x32x48K I2S which I could then take into the BeagleBone. All I need then is a suitable driver to present the audio as a 16-channel (or two 8-channel) ALSA device.

Does this sound plausible, from a block-diagram and electrical compatibility point of view?

My concerns:

(1) The reverse engineering project I gave a link for in my first post uses a transformer-isolated "MagJack" RJ45 plug. I would hope that your Transporter in "receive" mode would be electically equivalent, given that the port would be exposed "to the public" and connected to a separately powered commercial unit some feet away.

(2) It appears that the multiple I2S inputs on the BeagleBone share a receive clock, so synchronization between the two input streams would depend on the two WM8804 boards producing synchronized I2S output streams from their otherwise entirely independent inputs. The device at the other end of the Cat5 is presumably *sending* the two streams synchronized (both at the bit clock level and at the 8-channel-frame level) but is there any other variable in the WM8804 which might cause the absolute latency of its conversion from AES3 to I2S not to be predictable and exact so that the two I2S streams remain in sync to a sub-bit-clock level, so that I could use the bit and frame clocks of one to clock *both* inputs? One assumes that Cat5 cable has a tolerance on the difference between the lengths of each twisted pair over a given distance (which in this case won't be more than a few feet).

Thank you.

After even more thought, I am wondering if I should be using an FPGA for the actual audio processing.

The FPGA would accept and unpack the two 24/192 (actually 4x24/48) I2S streams, do the audio mixing, and generate eight new stereo 24/48 I2S streams which back out to eight stereo DACs and headphone amps.

The audio mixing itself can be reduced to a 16x16 matrix multiply (each output is some combination of all the inputs). The contents of the matrix could be passed to the FPGA asynchronously via say I2C, probably double-buffered to avoid clicks when the values change.

There are a bunch of FPGA "hats" available for Raspberry Pi (e.g. http://www.bugblat.com/products/pif) so this shouldn't be too hard, and it would allow me to stick with the Pi (as the most mature of those platforms) and avoid all the I2S driver problems, although probably only swapping them for all *new* problems with FPGA creation. Also, I have no concept of what "size" of FPGA would be required to implement that functionality.

So, parts-wise, it looks like I need one Transporter card as a dual-channel differential-to-TTL receiver, two WM8804 cards, the FPGA "hat", and eight I2S DACs and headphone amps of acceptable quality (yours are way too nice, and too expensive given that I need eight of them... no offense!)

Your site lists the Transporter as out-of-stock, and the line transceiver chip it uses seems to be out of production. Please advise as to whether you are still able to sell me one. Thanks!

OK, thanks. That said, I no longer think a Transporter receiver will work in this case. I re-read the original thread on DiyAudio that did the reverse-engineering of the Ultranet connection, and I now see that, while two of the pairs carry data, a third is tied to ground (tolerable) and the fourth provides 15V power on both wires (probably NOT tolerable). Also, the transmitting device may not even enable the outputs unless there is a measurable draw on the 15V lines. So, I might have to still build that part myself. Oh well.

I did not. I decided it was way too ambitious. Instead I went with a six-channel headphone amp and some mono-balanced-to-stereo-unbalanced adapter cables so I could do six band mixes of shared stereo and individual "me".