| Electronics > Projects, Designs, and Technical Stuff |
| Digital audio protocol for 100M copper |
| << < (4/14) > >> |
| ejeffrey:
--- Quote from: mikeselectricstuff on December 10, 2018, 11:28:56 pm ---Unless you're taking literally single-point to single-point, ethernet looks like a no-brainer, the only question being what protocol you run over it. Personally I'd avoid any unnecessary protocol layers and software stacks - keep it simple, but think about and allow for future expansion. --- End quote --- That's also a really compelling advantage of ethernet. You have multiple existing nice streaming protocols to choose from with both TCP and UDP options, and you can change with a relatively simple software update. You can also roll your own which should be unnecessary but is also relatively easy for such a simple application. |
| jbb:
Whichever scheme you go with, there is a fundamental question: will you do a star, a daisy chain or a full loop? If reliability (eg uptime) is cucial and space allows for all the canes, I recommend star. That way one broken wire (or dead node) doesn’t bring it all down. Isolation is a good idea - helps with (some kinds of) noise and should present nasty surprises. How are you powering the nodes? I ask because Power over Ethernet (PoE) can practically deliver 20W per node (remember the power converters have lossses...) and that could help your overall solution. Also, PoE could be applied to pretty much any scheme which uses coupling transformers and two twisted pairs (eg RS485 with some coding for DC balance). Regarding RS485: - assume 16b mono audio @ 48 kSamples - assume 80% coding efficiency - get basically 1 Mbit/s per audio stream - if duplex is desired, need 2 Mbit/s - could be trouble for 100m cable runs - trying to get 30 booths’ worth would be 60 Mbit/s, which is a lot for RS485 and definitely won’t go 100m |
| mikeselectricstuff:
--- Quote from: jbb on December 11, 2018, 03:30:39 am --- Regarding RS485: - assume 16b mono audio @ 48 kSamples - assume 80% coding efficiency - get basically 1 Mbit/s per audio stream - if duplex is desired, need 2 Mbit/s - could be trouble for 100m cable runs - trying to get 30 booths’ worth would be 60 Mbit/s, which is a lot for RS485 and definitely won’t go 100m --- End quote --- 4MBaud over 100m of Cat6 is no problem. If you are running multiple pairs in one cable you do need cat6, as crosstalk is the first problem you hit with cat5 For this system, 485 is probably too close to the limit for what you need - Ethernet will have so much headroom you can get something up & running without worrying about compression, and once working can look at optimisation if necessary. And you have the option to go to gigabit in future if you need it. |
| mariush:
I'd say just get a microcontroller/processor powerful enough to encode and decode FLAC or OPUS (open source both) FLAC decoding is as far as I know integer only so it will work even on lower frequency microcontrollers.... if you "optimize" the opus library to encode just mono for example it may also be not that much cpu intensive. from stall to server, you could send mono 22khz which would take something like 200-400kbps in FLAC and around 48-64 kbps for perfectly good OPUS (in music mode, it can do something like 10-15kbps for voice only) from server to stall, if you want stereo 16bit 48khz ... could be as much as 500kbps -1mbps (this could be a single stream broadcast to all 30+ stalls using udp, and the stall thing just mutes it when connection is not created (by pushing a button, answering on other end etc) or the shoutcast server could be configured to continuously stream blank flac/opus audio to the stall and keep connections opened non-stop. Latency can be tweaked to be under half a second, by having very small buffers. You could use some custom shoutcast server (each stall thing connects to a stream on shoutcast to read the operator's voice and uploads its own recording to the shoutcast server as another stream ) |
| mikeselectricstuff:
--- Quote from: mariush on December 11, 2018, 08:16:02 am ---I'd say just get a microcontroller/processor powerful enough to encode and decode FLAC or OPUS (open source both) FLAC decoding is as far as I know integer only so it will work even on lower frequency microcontrollers.... if you "optimize" the opus library to encode just mono for example it may also be not that much cpu intensive. from stall to server, you could send mono 22khz which would take something like 200-400kbps in FLAC and around 48-64 kbps for perfectly good OPUS (in music mode, it can do something like 10-15kbps for voice only) from server to stall, if you want stereo 16bit 48khz ... could be as much as 500kbps -1mbps (this could be a single stream broadcast to all 30+ stalls using udp, and the stall thing just mutes it when connection is not created (by pushing a button, answering on other end etc) or the shoutcast server could be configured to continuously stream blank flac/opus audio to the stall and keep connections opened non-stop. Latency can be tweaked to be under half a second, by having very small buffers. You could use some custom shoutcast server (each stall thing connects to a stream on shoutcast to read the operator's voice and uploads its own recording to the shoutcast server as another stream ) --- End quote --- Using any compression that takes appreciable comprless/decompress time adds latency and complexity, and just isn't necessary if you have 100Mbit ethernet. It's probably going to be much cheaper and easier to just throw bandwidth at it and use little or no data compression. |
| Navigation |
| Message Index |
| Next page |
| Previous page |