Author Topic: Digital audio protocol for 100M copper  (Read 6497 times)

0 Members and 1 Guest are viewing this topic.

Offline LapTop006

  • Supporter
  • ****
  • Posts: 467
  • Country: au
Re: Digital audio protocol for 100M copper
« Reply #25 on: December 11, 2018, 12:09:31 pm »
Balanced line (transformer coupled) AES3 will work

Yep, if you weren't going with Ethernet I'd go with that. Also works fine over coax. Except for a few bit flips that almost nothing cares about it's the same thing as S/PDIF, but worth knowing that the pro audio world often just call them "AES" inputs or "AES/EBU"
 

Offline dmills

  • Super Contributor
  • ***
  • Posts: 2093
  • Country: gb
Re: Digital audio protocol for 100M copper
« Reply #26 on: December 11, 2018, 01:18:21 pm »
If I were doing this I would want CAT5 cables (it is all kinds of cheap to get installed and terminated) and POE so the end devices do not need separate power. I would also be looking HARD for cots gear, there is little here that needs reinventing. Do not underestimate the wiring costs, I would expect the cabling to come in at the same order of cost as the end box.

Audinate for example have the Dante Ultimo chipset that IME just works and gives you access to a huge range of Dante audio boxes that do all kinds of interesting things, I would bet there is an Dante intercom controller you can just buy.

Dante feels heavyweight, but I think the flexibility it gets you is probably worth it. For example, hook a PC up to the network and run a $30 virtual sound card and the supervisor can now record the interactions with customers, useful for dealing with complaints...

You could go AES3 over two pairs and it would probably be fine, but then you are having to build a custom central control box which is a bit of a pain, and is a nasty single point of failure, with AES67 or Dante you just use an off the shelf POE switch as the central controller and that is available from any computer bits place.

There are two key things about this sort of project, reliability and usability, think hard about the environment the control positions are used in, heavy duty membrane keyboards and sealed boxes might turn out to be a very good thing for surviving the deep cleaning crew.

Regards, Dan.
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 8973
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: Digital audio protocol for 100M copper
« Reply #27 on: December 11, 2018, 02:21:26 pm »
If there's going to be a dedicated line to each stall, keep it simple and have the stall unit be just a passive speaker and a microphone with bias powered preamp. The central unit will have all the signal processing circuits. Keep the signal voltages high and there will be little interference.
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline LapTop006

  • Supporter
  • ****
  • Posts: 467
  • Country: au
Re: Digital audio protocol for 100M copper
« Reply #28 on: December 11, 2018, 02:24:03 pm »
Audinate for example have the Dante Ultimo chipset

Random fact, that chipset is named for the suburb of Sydney their office is in, just a few blocks from my apartment, has a cafe downstairs that does a lovely Korean-style steak sandwich.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Digital audio protocol for 100M copper
« Reply #29 on: December 11, 2018, 02:30:29 pm »
I don't see how computers are expensive... there's boards with soldered cpu like this one for example at 60$: https://www.newegg.com/Product/Product.aspx?Item=N82E16813157730&ignorebbr=1
Add 40$ for 4gb ddr3 and a ssd and you'll only need a psu to power it.  but there's such boards with 12v or 18.5v dc in jacks
See Asus H110T for example: https://www.amazon.com/H110T-CSM-LGA1151-Mini-ITX-Motherboard/dp/B01EZGYSGG
The problem is not in the hardware but in the software to run it. For that you'll suddenly need IT maintenance people in an organisation which likely doesn't have any.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: Digital audio protocol for 100M copper
« Reply #30 on: December 11, 2018, 02:59:32 pm »
There are long runs of conduit with multiple wires.

What kind of wires? Just a single wire per booth with shared ground, or some phone wire to each booth? Because if it's phone wire, just reuse it with differential signalling. If it's point to point, your hardware will always be connected to the wire, so it will always be correctly terminated.

Not having to rewire saves a ton of money and as ADSL has proven, you can stretch the performance of existing copper a lot.

We'd prefer not to use the full ethernet stack.

It's a connectionless protocol. Your software might fail, but if it's going to fail it's not going to be because you used ethernet. Some unmanaged switch is highly unlikely to be a common point of failure either, but you can actually buy them cheaply unlike for any alternative wire protocol
« Last Edit: December 11, 2018, 03:15:13 pm by Marco »
 

Offline mc73Topic starter

  • Newbie
  • Posts: 4
  • Country: us
Re: Digital audio protocol for 100M copper
« Reply #31 on: December 11, 2018, 05:37:07 pm »


Thanks everyone for the input. Here some answers to many of the questions that have been asked.


My budget per stall is probably $40 max,  (30 stalls per store) and $300 per inside unit (2-3 inside units). These are per 500-1000 piece orders.

No PCs or IT infrastructure that requires maintenance. The most we'll get is a power reset. No 6 min reboots either....max 10s.

We have independent wiring per stall to a central punchblock. The stall is selected by the user on the inside unit, typically on a membrane keypad.

We usually work with ATSAMD21s, ATSAMD51s and Wiznet 5500 for our monitoring and control systems.

We've been trying to find an on chip hardware controlled protocol so we're just dealing with signals and not software encoding. Seems like RS-485 might be a bit too delicate for our purpose though.

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

-Thanks again.







 

Offline ajb

  • Super Contributor
  • ***
  • Posts: 2582
  • Country: us
Re: Digital audio protocol for 100M copper
« Reply #32 on: December 11, 2018, 06:02:10 pm »
My budget per stall is probably $40 max,  (30 stalls per store) and $300 per inside unit (2-3 inside units). These are per 500-1000 piece orders.
  Is that your target BOM cost, or CM price?  As a BOM it's not bad, as a CM price. . . :scared:

Quote
We've been trying to find an on chip hardware controlled protocol so we're just dealing with signals and not software encoding.
Seems like RS-485 might be a bit too delicate for our purpose though.
Hardly!  It's used in industrial environments all the time, and while it takes some care to design (including protection) and install, it's not particularly fragile.  As with any physical link, it's prudent to include some sort of error detection at the protocol level.

Quote
Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?
  If you're using a dedicated network, the protocol hardly matters, and for voice your probably don't even need to worry about compression.  Ethernet gives you a frame check sequence that you can rely on for error detection, so at that point you can simply stuff audio samples into a datagram with a rudimentary header (something to identify it as an audio packet, and a sequence number) and kick it onto the network.  The stalls just have to listen for datagrams addressed to them and maybe make sure the sequence number is larger than the last one they received and shove the data out to their audio DACs.

You can use other simple datagram structures for whatever control get/set commands you need for lights and buttons and whatever.

One thing to keep in mind is you need a way to identify the stall on the network.  Since you have a limited number of nodes on the network, the simplest solution might be to have some DIP switches to set the last octet of the IP address to the stall number.  Unicasting the outgoing packets to the particular node that needs them will reduce the network processing overhead for the stall nodes. 
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Digital audio protocol for 100M copper
« Reply #33 on: December 11, 2018, 06:13:06 pm »
[..]
I don't see how computers are expensive... there's boards with soldered cpu like this one for example at 60$: https://www.newegg.com/Product/Product.aspx?Item=N82E16813157730&ignorebbr=1
Add 40$ for 4gb ddr3 and a ssd and you'll only need a psu to power it.  but there's such boards with 12v or 18.5v dc in jacks
See Asus H110T for example: https://www.amazon.com/H110T-CSM-LGA1151-Mini-ITX-Motherboard/dp/B01EZGYSGG
It would be foolish to use consumer motherboards to build something like this. That's how you get unreliable.
I meant something like this, a low power small pc that mounts on your DIN rail. https://www.logicsupply.com/cl210g-10/ (still requires heated cabinet though)

But one very important number has not been given. How long do they have to last. If you deploy pc's windows Windows 10 LTSB now, it ends support in 2026, that is only 8 years from now. I can imagine this is not long enough.
« Last Edit: December 11, 2018, 06:16:42 pm by Jeroen3 »
 
The following users thanked this post: tooki

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Digital audio protocol for 100M copper
« Reply #34 on: December 11, 2018, 06:20:24 pm »
Thanks everyone for the input. Here some answers to many of the questions that have been asked.


My budget per stall is probably $40 max,  (30 stalls per store) and $300 per inside unit (2-3 inside units). These are per 500-1000 piece orders.

No PCs or IT infrastructure that requires maintenance. The most we'll get is a power reset. No 6 min reboots either....max 10s.

We have independent wiring per stall to a central punchblock. The stall is selected by the user on the inside unit, typically on a membrane keypad.

We usually work with ATSAMD21s, ATSAMD51s and Wiznet 5500 for our monitoring and control systems.

We've been trying to find an on chip hardware controlled protocol so we're just dealing with signals and not software encoding. Seems like RS-485 might be a bit too delicate for our purpose though.
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 2501
  • Country: us
  • Yes, I do this for a living
Re: Digital audio protocol for 100M copper
« Reply #35 on: December 11, 2018, 07:30:53 pm »


 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. On the PCB we'll be working with I2S, AKM DSPs and TI PurePath ICs.  Ideally it needs to run over copper, typically cat 5e or 6 in runs of up to 100m. Wireless is not an option to the stalls. In general signal robustness is more important than quality. We frequently deal with poor wire termination, etc.

I don't have any experience with long distance digital audio protocols and am hoping someone might a have a recommendation.

Look into Dante (http://www.audinate.com/) or AVB, both do multichannel digital audio over standard Ethernet.
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Digital audio protocol for 100M copper
« Reply #36 on: December 11, 2018, 07:44:07 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.

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
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3685
  • Country: us
Re: Digital audio protocol for 100M copper
« Reply #37 on: December 11, 2018, 07:56:19 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?

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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: Digital audio protocol for 100M copper
« Reply #38 on: December 11, 2018, 08:13:03 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?

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.
Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 3685
  • Country: us
Re: Digital audio protocol for 100M copper
« Reply #39 on: December 11, 2018, 08:29:24 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?

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.
Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses.

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.

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.  The only reason I don't recommend that is that the kind of dumb microcontroller you probably want to use for this application doesn't really have enough RAM to implement a good TCP stack.  I would rather use UDP than a crappy TCP stack.

 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: Digital audio protocol for 100M copper
« Reply #40 on: December 11, 2018, 08:54:17 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?

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.
Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses.

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.

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.

Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline jbb

  • Super Contributor
  • ***
  • Posts: 1128
  • Country: nz
Re: Digital audio protocol for 100M copper
« Reply #41 on: December 11, 2018, 09:16:04 pm »
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?
 

Offline Twoflower

  • Frequent Contributor
  • **
  • Posts: 735
  • Country: de
Re: Digital audio protocol for 100M copper
« Reply #42 on: December 11, 2018, 09:18:50 pm »
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.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13695
  • Country: gb
    • Mike's Electric Stuff
Re: Digital audio protocol for 100M copper
« Reply #43 on: December 11, 2018, 09:19:26 pm »
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. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Digital audio protocol for 100M copper
« Reply #44 on: December 11, 2018, 09:54:55 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Digital audio protocol for 100M copper
« Reply #45 on: December 11, 2018, 09:56:28 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.

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
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline nfmax

  • Super Contributor
  • ***
  • Posts: 1556
  • Country: gb
Re: Digital audio protocol for 100M copper
« Reply #46 on: December 11, 2018, 10:01:43 pm »
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!
 

Offline T3sl4co1l

  • Super Contributor
  • ***
  • Posts: 21606
  • Country: us
  • Expert, Analog Electronics, PCB Layout, EMC
    • Seven Transistor Labs
Re: Digital audio protocol for 100M copper
« Reply #47 on: December 11, 2018, 10:22:06 pm »
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
Seven Transistor Labs, LLC
Electronic design, from concept to prototype.
Bringing a project to life?  Send me a message!
 

Offline tooki

  • Super Contributor
  • ***
  • Posts: 11341
  • Country: ch
Re: Digital audio protocol for 100M copper
« Reply #48 on: December 12, 2018, 12:20:31 am »
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.
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.)
 

Online nctnico

  • Super Contributor
  • ***
  • Posts: 26755
  • Country: nl
    • NCT Developments
Re: Digital audio protocol for 100M copper
« Reply #49 on: December 12, 2018, 12:33:51 am »
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.
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.)
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.
« Last Edit: December 12, 2018, 12:37:55 am by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf