| Electronics > Projects, Designs, and Technical Stuff |
| Digital audio protocol for 100M copper |
| << < (13/14) > >> |
| ogden:
--- Quote from: nctnico on December 12, 2018, 10:10:10 pm ---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. --- End quote --- 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:
--- Quote from: nick_d on December 12, 2018, 12:49:23 pm ---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. --- End quote --- 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:
--- Quote from: ogden on December 12, 2018, 11:56:10 pm --- --- Quote from: nctnico on December 12, 2018, 10:10:10 pm --- --- End quote --- 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. --- End quote --- 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:
--- Quote ---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. --- End quote --- 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. --- Quote ---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. --- End quote --- 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 |
| Navigation |
| Message Index |
| Next page |
| Previous page |