| Electronics > Projects, Designs, and Technical Stuff |
| Digital audio protocol for 100M copper |
| << < (12/14) > >> |
| TomS_:
--- Quote from: ejeffrey on December 11, 2018, 08:29:24 pm ---I would go with UDP. The extra overhead is basically nothing --- End quote --- But its still additional overhead to process and doesnt actually add anything except more complexity by having to then implement an IP stack. Ethernet still allows you to address end points directly, you then just need (as suggested by someone else) a very basic control protocol that provides advertisement/discovery and other functionality as needed. |
| mikeselectricstuff:
--- Quote from: TomS_ on December 12, 2018, 02:33:11 pm --- --- Quote from: ejeffrey on December 11, 2018, 08:29:24 pm ---I would go with UDP. The extra overhead is basically nothing --- End quote --- But its still additional overhead to process and doesnt actually add anything except more complexity by having to then implement an IP stack. Ethernet still allows you to address end points directly, you then just need (as suggested by someone else) a very basic control protocol that provides advertisement/discovery and other functionality as needed. --- End quote --- And don't forget that you do not need to use globally unique MACs if it's point to point you could just use 1 and 2 (and not need a switch) If devices have IDs of some sort then the MAC addresses can just be set to these IDs rather than having an additional layer of logical-to - physical address translation (ARP). |
| mariush:
Do you really need super low latencies for this particular application? I mean, you're talking about stalls in restaurants, where most likely people push to talk or unmute, listed to a person, think for a bit, answer , maybe they ask to repeat if it's too noisy inside... i would think even 50-100ms of latency between person talking and being heard at the other end wouldn't be an issue. Don't get it why you'd restrict yourself to CAN or RS485 when you could just use ethernet and leave yourself room for future stuff... maybe suggest upgrading the boxes in the future to have a small display that displays some ads/banners/products on sale or maybe some eInk screen to show the menu along with a couple of buttons or touch sensitive screen.. You could implement something like push update to everything by using udp, or just have a basic http server or tftp ...with udp you could just repeat broadcasting a package of data for 20-30 minutes and for sure even if a frame is lost, every stall machine eventually picks up the frames a second time or third time and builds up the update package eventually. With ethernet you'd just put a 48 port switch on a half-rack and you're done. You can get 48 port 100mbps switches for around 100$ new ... I'd think you'd have to custom make some box in which to terminate the cables and maybe have custom connectors when you could get patch cables or plain cat5e ethernet cable in 305 meter or higher spools. And... you could get a switch with power over ethernet on all ports to power the device at the stalls or just abuse everything and send 24v DC through unused wires in the cable ... or you could split ethernet cable on 2 x 4 pairs and handle 2 stalls at a time with one cable. And you have cheap ARM micros with built in ethernet... |
| T3sl4co1l:
To the OP: You get what you pay for. As free advice goes, this thread is one hell of a deal, I must say! There do seem to be a lot of IT/network fetishists on here, but that's not really surprising. It takes a lot of them to keep those networks running. :) Tim |
| nctnico:
--- Quote from: ejeffrey on December 12, 2018, 12:55:21 am --- --- Quote from: nctnico on December 11, 2018, 09:54:55 pm --- --- 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. --- End quote --- Basically on a dedicated LAN, packet loss will be zero or next to it and in the rare case the retransmit latency is so low that it won't be an issue (this is a drivethrough order system, not a real time game). A 50 millisecond audio buffer is irrelevant and is dozens of round-trip-times. In this application UDP vs. TCP won't matter. On a bigger network you are right, but then a simple raw UDP solution isn't great either, and you want to look at one of the well designed streaming protocols. --- End quote --- As you wrote the packet loss will never be zero and then you end up waiting for (exponentially increasing) TCP re-transmit timers which will make the audio pause / stutter every now and then. Using TCP for any realtime streaming application is asking for 'bugs' in installations which are impossible to reproduce and solve but it will have a negative impact on the overall quality of the system as seen by the customer. And trust me: the customer really doesn't care that in a small network there shouldn't be any packet loss. They just want the streaming to work flawless. All in all I really don't understand why people keep insisting TCP is useable for realtime streaming. It clearly isn't even though you can make it work in theory. But then again: for the application of the OP using ethernet may be overkill although components (like a phy or a transformer) typically used for an ethernet network may be useful to keep the solution cheap. There are a lot of ways to make clever combinations but ultimately the best solution also depends on the skill & knowledge available at the company the OP is working at. The solution has to fit their processes and budget. |
| Navigation |
| Message Index |
| Next page |
| Previous page |