Digital audio protocol for 100M copper

[ejeffrey]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

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.

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.

[tooki]

But that is not realtime streaming which is what this topic is about! Look at home much buffering goes on under the hood. Your video player is likely buffering several seconds of data to make sure it doesn't run out. Streaming video and audio realtime is a completely different ballgame. Add a couple of seconds of delay to a conversation and see how that pans out. Also if there is acoustic echo cancellation involved it helps to have as little delay as possible because then the echo canceller can also kill (or mask) the far-end echoes.

As ejeffrey agreed, it just doesn’t matter in this application. Whether 100 or 1000 Mbps, on a dedicated LAN like proposed here, packet loss just isn’t an issue.

To repeat: I’m not saying that TCP is necessarily superior here, just that it’s not categorically unusable as you seem to think. The bandwidth of a modern Ethernet LAN is so enormous compared to the data stream in question, and latency and packet loss so low, that it’d work fine.

[Jeroen3]

When you're using TCP, you still need the buffer to keep un-acked packets. If bitrate is high, this buffer is large. For UDP you do not need this buffer.
Another advantage of ethernet is that it is indeed rather simple to run a browser over it, as mentioned earlier.
And, if the customer asks "can you also install a camera?", then you can. Since there is plenty of bandwidth.

[Marco]

For a point to point connection it just doesn't make sense, there is no congestion, there are unlikely to be really spikey packetloss.

Just do some ad-hoc half duplex protocol with forward error correction over the existing wires with RS485.

[nick_d]

I was surprised to have to read to reply #47 before T3sl4co1l suggested CAN bus. I have been working on a CAN bus system for a client throughout this year, and it has been quite robust and reliable.

For this application I think 250 kbps (first version CAN) would be fine. It is necessary to check what the official maximum wire length is at 250 kbps, one source that I have says 87m and another says 250m.

I understand that the requirement is for isolation, there are isolated CAN transceivers available. It would be necessary to check the wire length separately for the isolated transceiver. I could look into these issues further if asked.

Anyway, the most compelling reason to use CAN instead of Ethernet is because CAN is real-time and Ethernet is not. Of course the non real-time medium can still be used, by arbitrarily picking a latency and providing that much delay and buffering to avoid artifacts from packets arriving earlier than the worst case scenario. But why do so? You're adding enormous complexity in order to get a substandard result.

With CAN you know that audio packets will take priority over other (control) traffic so you know exactly how long they will take to arrive. It would be prudent to provide one or two frames' worth of buffering just in case, however the frame size of CAN is deliberately set to just 8 bytes (with about 2 bytes overhead for address, check bit, stuff bits, etc). So at say 16 kHz x 12 bit samples the latency is about 16 samples or 1ms. There is no way that Ethernet could match that.

RS485 might, but I don't see a compelling reason to use RS485 over CAN bus given that CAN basically starts with capabilities similar to RS485 and adds additional robustness (such as higher tolerance to clock rate error, etc) and a higher layer protocol (address field, check bit, flags/stuffing etc) that you'd have to do yourself in software with RS485.

One good thing that can be said about RS485 is that it drives the bus high for 1 and low for 0, allowing faster speeds in general than CAN bus which uses a (slower) pull-up resistor for 1 and only drives low for 0. On the other hand, the CAN bus way greatly simplifies media access and collision management, which adds significant software complexity in RS485 and requires bus grant schemes etc that hurt real-time performance. Hence, I would go with CAN bus here.

One thing that can be quite tricky with digital audio distribution is sample rate error that builds up over time. Say you have an ADC and DAC at each end each running off a locally generated 16 kHz sample clock, then if the DAC at one end is slightly faster than the ADC at the other end, the data transfer will underrun and filler samples might have to be generated, if the DAC is slower then the data transfer will overrun and samples might have to be dropped.

There are many ways to deal with this, some of those ways require a timebase to be sent over the medium, and this is something that CAN bus does brilliantly. Our application has a number of radio transmitters on the CAN bus whose transmissions must be tightly timed l, and we are using a higher level protocol called UAVCAN on top of the basic CAN addressing and medium access protocol. UAVCAN has a time server built in that works really well, using the hardware to timestamp the sending and receiving of CAN frames.

If only audio is to be sent over a dedicated connection of at least 3 wires (or 4 including power), then a small and cheap microcontroller will do it. The STM32F4's have pretty good number crunching ability if you want to do compression, but the CAN controller has some frustrating errata that wasted a lot of my time. 8051 derivatives with CAN can be had for next to nothing but may require external ADC/DAC if quality is a concern. There may be a middle course... NXP? Or you mentioned specific chips, so if using those you could add an external CAN chip. I have a USBtin that uses an MCP2515 plus MCP2551 transceiver, these are cheap and common.

cheers, Nick

[TomS_]

I would go with UDP.  The extra overhead is basically nothing

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]

I would go with UDP.  The extra overhead is basically nothing

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.

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]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

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.

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.

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.

[ogden]

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.

Problem in their heads is packet loss which is seemingly solved by TCP retransmits. People who suggest to use TCP for realtime VOICE(!!) application are clueless and need to improve their knowledge about video/audio transport ALOT. RTP protocol which mostly runs over UDP is widely used in streaming and voip systems. Packetloss solution in RTP audio systems is plain simple - if packed did not arrive in time just play contents of previous one, obviously using crossfade to avoid click. Rarely anybody will notice.

[dmills]

RTP over UDP is used for BROADCAST PRODUCTION VIDEO at 10, 25, 40 and 100Gb/s in ST2110 and friends, it is a complete non issue for telephony grade audio.

We are not doing old school thinnet these days, modern ethernet is NOT CSMA-CD any more.

Regards, Dan.

[Marco]

I was surprised to have to read to reply #47 before T3sl4co1l suggested CAN bus. I have been working on a CAN bus system for a client throughout this year, and it has been quite robust and reliable.

Galvanic isolation for a CAN bus will cost you more than for RS-485 though (always nice to have an extra safety layer between a wiring mishap and customers). Also they have existing point to point wiring, so they don't really need a bus protocol.

Given the requirements that they just want to replicate the analogue system as much as possible and don't really care to add bells and whistles like recording and multiple listeners, I'd just keep it mostly ad-hoc. RS-485 has nice signalling levels, half duplex drivers are relatively cheap and it's protocol agnostic ... good fit.

[Jeroen3]

Problem in their heads is packet loss which is seemingly solved by TCP retransmits. People who suggest to use TCP for realtime VOICE(!!) application are clueless and need to improve their knowledge about video/audio transport ALOT. RTP protocol which mostly runs over UDP is widely used in streaming and voip systems. Packetloss solution in RTP audio systems is plain simple - if packed did not arrive in time just play contents of previous one, obviously using crossfade to avoid click. Rarely anybody will notice.

TCP is a stream, all bytes arrive in FIFO order. Any packet loss halts the entire stream. With millisecond interruptions.
That is horrible. You'd have to configure TCP beyond spec with tiny timeouts. Possibly inhibiting the stacks capability to communicate on the actual internet.
It's like using a lithium battery rpm controlled cordless drill as a hammer. Why wouldn't you just use a hammer???

[nick_d]

 

Galvanic isolation for a CAN bus will cost you more than for RS-485 though (always nice to have an extra safety layer between a wiring mishap and customers). Also they have existing point to point wiring, so they don't really need a bus protocol.

Yes, after I wrote the previous manifesto this occurred to me too. Actually, it depends on how many wires they have. If there are only 2 then RS485 may well be the go. If they have 3 then RS232 might be an option, not quite sure how the isolation would be done but similarly to RS485. If they have 4 wires then something like a current-loop in each direction would work. I recall that this used to be popular for things like keyboard connections to industrial PCs back in the day, although I wasn't up on the details. I envisage something like MIDI's physical layer, where basically the LED of a fast opto-isolator is driven remotely through a dedicated wire pair.

Given the requirements that they just want to replicate the analogue system as much as possible and don't really care to add bells and whistles like recording and multiple listeners, I'd just keep it mostly ad-hoc. RS-485 has nice signalling levels, half duplex drivers are relatively cheap and it's protocol agnostic ... good fit.

Quite. I have realized that the 5V swing of CAN bus is not good for long distances even though it is differential. Also, in my previous proposal I forgot to mention that I envisaged a use for the multidrop bus to carry multiple connections to a small cluster of booths where necessary to deal with issues like broken or failed wiring, but I realize now that this would be (a) way more complex, (b) too ad-hoc and (c) limited by data rate. If you wanted a bus, then I think the Ethernet proposals are better. Recently my apartment was refitted with video entryphones running over PoE and they're good, as another poster suggested (I think slightly over budget for the OP, possibly cheaper after development costs though).

cheers, Nick

[amlu]

you can get a working solution off the shelf, budget one would  be something like that:
https://www.bhphotovideo.com/c/product/969887-REG/behringer_x_32_rack_x32_16_midas_preamps_ipad_control.html
plus a digital audio snake to go with it...
its the lowest end but anyway used in pro audio/events and apparently does the job.

[dnwheeler]

Many of the solutions being proposed assume that there is some need to aggregate multiple signals on a single wire. As I understand the OP, there will be separate point-to-point connections for each stall. There won't be collisions and there's no need for addressing or high bandwidth.

As others have mentioned, running two separate AES3 lines (one for each direction) to each stall should be fairly easy and cheap. Then on the "station" end, a simple selector to pick which lines to connect to (with enough software to synchronize to the start of a frame - there might be an AES3 decoder chip that do this). AES3 also has a low-speed user data channel for additional data if desired.

[soldar]

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.

Hmmmm... It seems to me this should be quite simple and digital encoding is probably not needed. Plain Old Telephone wires run much longer bundled together. I would not discard analog because I think it would work and is simpler and cheaper.

OTOH, if the microphone can receive the speaker then you will have feedback problems. If the speaker is a headphone which cannot be picked up by the microphone then this is not a problem.

Having to deal with feedback and echo cancellation complicates matters considerably.