Electronics > Projects, Designs, and Technical Stuff
Digital audio protocol for 100M copper
<< < (9/14) > >>
mikeselectricstuff:

--- Quote from: ejeffrey on December 11, 2018, 08:29:24 pm ---
--- 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.


--- End quote ---
But if you don't need PC interoperability, by using raw frames you don't need a network stack at all, so no learning curve and unnecessary features (and bugs) you won't use.  Could be an issue if implementing on a resource-limited MCU.
ARP-like functionality to map logical addresses to MACs, ports etc. would be very easy to implement.

jbb:
I too would start by considering an Ethernet solution using, e.g. uncompressed audio over UDP. Latency should be some milliseconds.

Given that it may well be possible to manage all the audio uncompressed with reasonable bandwidth, I suggest avoiding the complexity of audio compression for now.

Using an ARM Cortex something with a small RTOS will improve consistency versus a ‘desktop’ OS like a standard Linux distribution and should also be a lot tougher with respect to temperature and power supply glitches (which tend to mess up file systems and brick computers).

Ethernet delivers a second benefit in that it happily lets you send packets to specific addresses, which will help with routing booths to staff.

To maintain predictable performance, use a dedicated high quality Ethernet switch for the backbone. Keep it separate from the general IT infrastructure in the building to
- maintain consistent performance (ie audio doesn’t get laggy because the manager is streaming a training video from Corporate)
- segregate networks for security (the attackers carried out the big Target hack a few years ago via the air conditioning equipment)

At this point I would like to flag a privacy concern. Is it an issue if the booths have live mics at all times? For a drive-through that would be expected. For a sit-down restaurant it would be a problem. Is it appropriate to include some kind of live mic warning indicator?
Twoflower:
Because you can use lots of the shelf HW I would also consider Audio over Ethernet. And I would see that most of the protocol is along some standards as well. Even if you waste some bandwidth or CPU power. The debugging will be much easier if you can hook up a PC with standard tools. One additional point is the insulation of Ethernet. With 100m cable there's a good chance that you can create a nice ground-loop that could ruin your day. I would think to use a industrial kind of connectors and not the normal Ethernet one, just to reduce the risk that some genius connect that system to the intra-/Internet.

If the $40 is per Stall I would say that will be very challenging. Consider that you need a PSU, speaker, microphone, amplifier, some kind of processing, housing (potential custom made; at least holes for the connectors/cables), connectors, full PCB production plus putting the things together. Any that probably weather-prove, vandalism-prove and reliable. Not impossible but you should check if you can met that price-point.
mikeselectricstuff:
Another approach to addressing is have the MAC addresses set by DIP switches on the units to code the location. A big advantage of DIP switches is that replacement for maintainance is easy - just set switches same on the replacement unit, no configuration, programming etc. 
nctnico:

--- Quote from: ejeffrey on December 11, 2018, 08:29:24 pm ---Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

--- End quote ---
No. TCP is unsuitable for streaming because it does resend and so on. Every streaming solution uses UDP. When a packet is lost, the content of the previous packet is replayed. By the time TCP does a resend the contents of the packet is meaningless.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod