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

--- Quote from: ogden on December 11, 2018, 07:44:07 pm ---
--- 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

--- End quote ---
But is there room for digital I/O in such a stream? If yes, then it would be a good solution for the OP's system indeed.
nfmax:
This application sounds almost like a network of Door Entry phones. Loud speaking, weather-resistant VoIP entry phones are commercially available - would it be possible to base a solution on their use? Then your CAT5 would be running plain old TCP/IP over Ethernet. Plenty of bandwidth for audio with enough left over for control. You could even put a tablet display at each outstation if you really want, running a browser in kiosk mode. Upsell!
T3sl4co1l:
The other robust option would be any industrial network: CAN, LIN, Modbus, Profibus, etc. (several of which are a protocol layer that runs on any physical layer, or can tunnel through another..).

CAN is a multidrop network, which would be nice, but it would have to run damn fast (way faster than practical) to serve even a few boxes at once.  And they're not described as chained (though that might make installation easier, if changing the topology is an option?), so that's no help.

RS-485 is quite robust, but you may need to provide isolation, and that drives up the cost.

Ethernet would then be the cheapest isolated option, and again, you can use it on a pretty low level, no PC needed -- it may not be as well supported at this level in terms of available tools to work with it (e.g., if you aren't using IP, then you aren't going to get anything into a PC expecting an IP address..), but that's really not much different from RS-485 where you're building your own protocol and stack completely from scratch!

And as Mike's shown, low level Ethernet is quite accessible. :)

Tim
tooki:

--- 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 ---
Over the internet perhaps. On a wired LAN that isn’t suffering from horrific packet loss, this retransmission happens in milliseconds, more than good enough for audio. (Uncompressed stereo CD-quality audio is about 1.5Mbps, a tiny, tiny fraction of a modern gigabit LAN or even of now-basic 100Mbps Ethernet.)

Granted, there’s no significant downside to using UDP for this application on a LAN, either. But just saying that calling TCP “unsuitable for streaming” in a wholesale fashion just isn’t true.

Heck, I occasionally do wildly inefficient TCP-based video streaming on my LAN (even WiFi!) when playing video files over file sharing (SMB). A mounted file system has tons of overhead and zero tolerance for lost packets. It works totally fine. (Over the Internet would be a different matter.)
nctnico:

--- Quote from: tooki on December 12, 2018, 12:20:31 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 ---
Over the internet perhaps. On a wired LAN that isn’t suffering from horrific packet loss, this retransmission happens in milliseconds, more than good enough for audio. (Uncompressed stereo CD-quality audio is about 1.5Mbps, a tiny, tiny fraction of a modern gigabit LAN or even of now-basic 100Mbps Ethernet.)

Granted, there’s no significant downside to using UDP for this application on a LAN, either. But just saying that calling TCP “unsuitable for streaming” in a wholesale fashion just isn’t true.

Heck, I occasionally do wildly inefficient TCP-based video streaming on my LAN (even WiFi!) when playing video files over file sharing (SMB). A mounted file system has tons of overhead and zero tolerance for lost packets. It works totally fine. (Over the Internet would be a different matter.)

--- End quote ---
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.
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