| Electronics > Projects, Designs, and Technical Stuff |
| Digital audio protocol for 100M copper |
| << < (8/14) > >> |
| Bassman59:
--- Quote from: mc73 on December 10, 2018, 06:14:15 pm --- I've been tasked with updating an audio communication system used in the fast food industry for drive ins (e.g. 3 order takers to 30-60 order stalls). We're converting an old simplex analog audio system to duplex. There are long runs of conduit with multiple wires. We're moving to digital to avoid crosstalk and interference that was previously avoided by the simplex communication. On the PCB we'll be working with I2S, AKM DSPs and TI PurePath ICs. Ideally it needs to run over copper, typically cat 5e or 6 in runs of up to 100m. Wireless is not an option to the stalls. In general signal robustness is more important than quality. We frequently deal with poor wire termination, etc. I don't have any experience with long distance digital audio protocols and am hoping someone might a have a recommendation. --- End quote --- Look into Dante (http://www.audinate.com/) or AVB, both do multichannel digital audio over standard Ethernet. |
| ogden:
--- Quote from: nctnico on December 11, 2018, 06:20:24 pm ---RS485 is fine. The resilience depends on the chip, speed and external overvoltage protection you add. An RS485 driver can be used with a transformer too and if the bitrates aren't too high then any cheap ethernet transformer or telecom transformer will do. Unfortunately ISDN and many other analog telephone chips which where real gems for these kind of systems are obsolete so I think you have to roll your own. But it doesn't have to be complicated. A small CPLD capable of detecting a pre-amble, shift in 16 bits (8 bit ulaw/alaw audio, 8 bit digital I/O) and do a CRC check and a codec chip is all you need. --- End quote --- No need to invent anything new here. Perfect match is AES/EBU balanced digital audio interface. Low cost version would be S/PDIF over twisted pair. I would use S/PDIF peripheral SPDIFRX of STM32F4/F7/H7 Series microcontroller with RS422 transceivers. Further info: ST application note AN5073 |
| ejeffrey:
--- Quote from: mc73 on December 11, 2018, 05:37:07 pm ---Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario? --- End quote --- If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple. Luckily you don't need much. You are on a dedicate LAN so it will be almost impossible to screw up. Since you are using voice, uncompressed mono 16 kHz audio is more than enough. You can even use an 8-bit ulaw encoding to cut the data rate further. A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends. I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested. This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN. |
| mikeselectricstuff:
--- Quote from: ejeffrey on December 11, 2018, 07:56:19 pm --- --- Quote from: mc73 on December 11, 2018, 05:37:07 pm ---Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario? --- End quote --- If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple. Luckily you don't need much. You are on a dedicate LAN so it will be almost impossible to screw up. Since you are using voice, uncompressed mono 16 kHz audio is more than enough. You can even use an 8-bit ulaw encoding to cut the data rate further. A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends. I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested. This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN. --- End quote --- Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses. |
| ejeffrey:
--- Quote from: mikeselectricstuff on December 11, 2018, 08:13:03 pm --- --- Quote from: ejeffrey on December 11, 2018, 07:56:19 pm --- --- Quote from: mc73 on December 11, 2018, 05:37:07 pm ---Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario? --- End quote --- If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple. Luckily you don't need much. You are on a dedicate LAN so it will be almost impossible to screw up. Since you are using voice, uncompressed mono 16 kHz audio is more than enough. You can even use an 8-bit ulaw encoding to cut the data rate further. A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends. I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested. This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN. --- End quote --- Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses. --- End quote --- I would go with UDP. The extra overhead is basically nothing -- 8 bytes per packet on top of the 20 byte IP header and 18-24 byte ethernet frame fields, and it gets you a fair bit of extra flexibility. You can separate IP from MAC address -- IP addresses can be assigned by stall irrespective of the hardware. You can use the port number to distinguish between e.g., audio stream vs. control commands. If you have to end up going through a router you can although that opens up the possibility of more latency and dropped packets. Possibly most importantly, the operator side is presumably going to be a general purpose PC running a full OS. By using UDP you can use simple socket commands rather than raw sockets and libpcap. Presumably you are going to use an off the shelf network stack, so you get all that stuff "for free", rather than having to implement your own addressing protocol. Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment. The only reason I don't recommend that is that the kind of dumb microcontroller you probably want to use for this application doesn't really have enough RAM to implement a good TCP stack. I would rather use UDP than a crappy TCP stack. |
| Navigation |
| Message Index |
| Next page |
| Previous page |