1
\$\begingroup\$

first off I have already found a wealth of information here so thank you! I am hoping to get some general feedback on a project I'd like to work on. Here is an outline.

I'd like to be able to transmit 8 channels of 24 bit 48KHz audio over ethernet to a collection of 6 to 8 receivers all connected through a switch. Here is my thought process.

  1. Network Speed - 8 channels * 24 bits = 24 bytes. That is below the minimum of 46 bytes (non 802.1Q) so we'll just work with that minimum. Our minimum frame size then is 84 bytes. At 48KHz this would imply an average throughput of ~32.3 mbit/s on the network. Given this result a fast ethernet network with appropriate switches would seem to be OK. Does this analysis seem accurate?

    Note that I'm not too too concerned with perfect playback so an occasionally dropped packet isn't a big deal. Given this I don't think I want to get into sample rate conversion for the network transmission.

    Sidenote - originally I wanted to work on a 10Base-T network because a lot of MCUs had integrated 10Base-T MAC/PHY. Given the minimum 84 byte frame size though... this would restrict sample rates to a little less than 15KHz yuck!

    Just to be sure I'm thinking about this correctly, I cannot violate the 84 byte frame minimum if I want to be able to use commercial switches correct?

  2. Receiver Hardware

    a. Ethernet Controller - I'd like a 100Base-T ethernet controller with built in MAC/PHY. The problem though is, it needs to be able to communicate with the MCU fast enough to push all the audio data through. 8 channels * 24 bits * 48KHz = 9.22 mbit/s. I'm thinking this is going to be too fast for SPI. The ENC424J600, in addition to SPI, has a parallel interface which seems to be useful for faster speeds. Page 53, gives some theoretical performance figures.

    http://ww1.microchip.com/downloads/en/DeviceDoc/39935c.pdf

    b. MCU - Which ever one I choose will need to be beefy enough to read in all 8 channels of audio data from the Ethernet controller, do some very basic DSP on then (channel mixing), and send out the data to a stereo 24 bit DAC at 48KHz. In addition to this it also needs to do some basic interfacing with panel I/O. Any suggestions on a suitable MCU?

    Note that I'm looking at using this DAC.

    http://www.cirrus.com/en/products/cs4341.html

Any comments or thoughts you guys have that might be useful to this project would be very much appreciated!

Thanks, Jordan

\$\endgroup\$
  • \$\begingroup\$ Since you already have an MCU, what about data compression? A lossy codec will reduce your bandwidth greatly. even a lossless codec will give you some net reduction in bandwidth. \$\endgroup\$ – Lior Bilia Nov 14 '13 at 6:43
  • 1
    \$\begingroup\$ Do you have a latency requirement? If not, I don't see why the minimum packet size is relevant, you can and should have more than one set of samples per frame. 33Mbit data over 100Mbit is just about achievable, as long as it's strictly in one direction. You'll probably want an ARM or similar as the processor. \$\endgroup\$ – pjc50 Nov 14 '13 at 9:47
  • \$\begingroup\$ you mentioned that 33MBit over 100Mbit is "just about achievable". Are this referring to an achievable sustained throughput? If so, could you provide more information on this calculation? \$\endgroup\$ – Jordan Street Nov 15 '13 at 19:56
1
\$\begingroup\$
  1. You don't want to send a single packet for every sample. That's because the packet has headers as well, and that means inefficiency in the transfer. Putting several samples into a single packet will both increate the efficiency and get you over your minimum packet size. The upper limit on the number of samples is the maximum latency that you can tolerate. At 48kHz, adding one more sample into your packets would increase the latency by ~21\$\mu\$s. You should also calculate the latency introduced by the whole system end-to-end. Having 8-16 samples per packet would increase your efficiency above 70-80%.

  2. I'd go for a microcontroller with a built-in Ethernet MAC. Having a built-in PHY as well would be a nice plus, however, that extra constraint would decrease your choice by large. There many-many microcontrollers with a built-in 100Mbps MAC, but only a few with a built-in PHY as well.

\$\endgroup\$
  • \$\begingroup\$ I never thought about putting multiple samples into a single frame, that makes a lot of sense. I'll do some research and better define my latency constraints. Thanks for the response! \$\endgroup\$ – Jordan Street Nov 15 '13 at 16:56
0
\$\begingroup\$

The elephant in the room with audio over IP in a professional context is clock distribution and clock recovery...

You can easily fit 64 channels of 24 bit 48K audio over a 100Mb/s link, with your multiple receivers I might be thinking multicast or the like.

AES67 may be interesting, and have a look at Ravenna and Dante as well to get ideas (Also AVB, but it is overkill for just audio).

There are plenty of little micros with built in MAC that just need a PHY adding to do this kind of thing, but you will probably want to lock the audio clock to the incoming frame rate which will usually need a hardware PLL of some kind (The alternative is a SRC and delay locked loop).

8 Channels = ~1.2MB/s = so it will not quite fit over a 10Mb link, but is trivial over a 100Mb/s link.

Use an 8 Channel DAC that supports DSP mode and you can often finesse the output using one of the SPI ports.

Regards, Dan.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.