I was wondering if there is a physical distance problem when using Barix boxes as STL's. For example could you have a studio in NYC feed an FM transmitter in Texas using a Barix box setup without any issues?
-
Get involved.
We want your input!
Apply for Membership and join the conversations about everything related to broadcasting.
After we receive your registration, a moderator will review it. After your registration is approved, you will be permitted to post.
If you use a disposable or false email address, your registration will be rejected.
After your membership is approved, please take a minute to tell us a little bit about yourself.
https://www.radiodiscussions.com/forums/introduce-yourself.1088/
Thanks in advance and have fun!
RadioDiscussions Administrators
Barix question
- Thread starter RadioGuy1864
- Start date
Short answer no. But there are always issues. longer the distance, the more chance of data loss or backhoe fade. Barix has the least control over error correction. Is this over the public internet? For any long distance data link your going to have to find that happy spot of audio quality and how much bandwidth is used to provide reliable audio at the far end with no drop outs or digital artifacts.
Try not to use DLS for public internet, Cable modem is OK, fiber is best.
Try not to use DLS for public internet, Cable modem is OK, fiber is best.
Adding to what Steve said; Barix boxes are inexpensive ways of sending decent quality audio via the public Internet, but sometimes you get what you pay for. Barix devices have been known to be easily hacked, which could result in someone hijacking whatever station you're feeding with a Barix STL. There are much more reliable and secure devices from manufacturers like Comrex and Tieline.
We use barix boxes here on satellite internet.,. and they work way better than youd expect but not quite as good as youd hope. Sometimes after a power or internet outage, the barix boxes connected to the hig hearth orbiting services viasat/exede or hughgesnet need a reboot because they dont reconnect properly...... but the barix boxes connected via low earth orbiting satellites on starlink dont need a reboot.
This is how KSKO feeds its satellitor stations and it, overall, works pretty good.
This is how KSKO feeds its satellitor stations and it, overall, works pretty good.
We have a Barix link on a nano-beam path of just 400 feet.
Had to put the Barix on a remote control channel to power cycle it. Needs that randomly.
The other end also has it on a remote reset.
Had to put the Barix on a remote control channel to power cycle it. Needs that randomly.
The other end also has it on a remote reset.
Don't forget to periodically clean all the discarded bits out of the digital filters.
Basically I run the buffer as high as possible around 900+ . Set to 48khz . VBR. I was lucky enough to be able to hear the station I was setting up from the sending end and tried stuff like running lower khz thinking less data would need to get through. It burped every 20 seconds or so. and of course the audio bandwidth was low. I then set it for high data and I came to the conclusion that if I ran high data i.e. 48khz if some of the data didn't get through it wouldn't matter there was still plenty there. The burps decreased to about one about every 10 minutes. Then I tried sending the stream point to point from the studio address directly to the transmitter address. After pinging the route I noted it ran from Florida to Kansas City then to New York and finally back to the transmitter site only 5 miles from the studio. I assumed the longer the route the more chance of failure but found that if I ran the stream to a server and then to the receive site through the server reliability was increased to 99%. The server I use is in NYC a long way from Florida. The first test described above was over a very weak system. While the sending end was through cable the only system available at the transmitter was DSL 7,000 feet from the B Box and the best rate we got was 7,000 . I have used these settings from several other sites and found this to work quite well. Hope that helps.
Last edited:
If you're trying to reduce bandwith on a slow/shaky connection, the audio sample rate/bit depth won't help much..48khz/44khz wont make much difference. you need to change the bitrate..... say 128 instead of 256kbps.
We were trying that when i worked at another alaska station but lowering the bitrate, even when adjusting treble and bass made the station sound kinda grungy
DSL should work ok for a brix box if youre download is 7mbs, as long as youre upload is 1meg. I had DSL at a station in California that used IP as an STL..
If youre on a shaky connection with slow speeds, a Comrex briclink is a better option.. i wish theyd thought of that here.
You make a good point I found that setting it to Variable Bit rate on the Barix was the only way it would remain stabile.
It's less about speed (much less) more about data integrity. Unlike internet audio streams, which are buffered and get packet resends (because latency doesn't matter, it could be 30 seconds), remember, an RTP stream is just a stream, the receiver can't request to resend a bad packet. It's just a bad packet. We trade data integrity for low latency. With more dropped packets, the natural reaction is to go for lower bit rates and higher compression, but higher compression is often worse because each packet contains a higher percentage of the audio data that must be reassembled. The buffer is great, larger is better, but you still don't get resends. Comrex and TieLine both have work-arounds with redundant streams that double the bandwidth but cover dropped packets better. The Comrex work-around actually works. Barix...not so much. I'll only use a Barix when the audio doesn't matter much.
DSLs can sometimes have better integrity (fewer dropped packets) than whippety fast cable connections. Cable infrastructer is more of a "shared water main" with more chances for congestion, where a DSL is at least a private pipe back to the VRAD, and a really big pipe from there on. Sometimes. It's not a hard/fast rule. Fiber is great, and the world will be a lot older when it's available everywhere. But most cable use cases are about rapid downloads of non-real-time data, or at least high latency data as compared to broadcast audio. A few seconds is no big deal, and lots of packet resends can happen in that time. People are impressed by speed, and never notice the resends.
I don't do satellite internet. Throwing bits at the earth from space will never catch on.
DSLs can sometimes have better integrity (fewer dropped packets) than whippety fast cable connections. Cable infrastructer is more of a "shared water main" with more chances for congestion, where a DSL is at least a private pipe back to the VRAD, and a really big pipe from there on. Sometimes. It's not a hard/fast rule. Fiber is great, and the world will be a lot older when it's available everywhere. But most cable use cases are about rapid downloads of non-real-time data, or at least high latency data as compared to broadcast audio. A few seconds is no big deal, and lots of packet resends can happen in that time. People are impressed by speed, and never notice the resends.
I don't do satellite internet. Throwing bits at the earth from space will never catch on.
Never had to use it but Elon Musk's satellite service seems to have good bandwidth. Just ask the Russian Navy
Well unfortunately, satellite internet is all we have here. Viasat/exede and now Starlink. That's it. Cell service is 2G here, no mobile broadband and picture texts dont even work
I was kidding....