Barix used for Remotes

[ChiefOperator]

The recent talk about the barix boxes (500 & 1000) being broadcast specific has raised some questions for me. Is anyone successfully using Barix boxes on extended remote broadcasts, such as football games? By successful, I mean stability comparable to the Comrex or Tieline units.
Additionally, if so, has anyone further tried these units with 3G connections (Barix to router).
Finally, will these units sustain bidirectional feeds, such as remote program feed one direction and studio feed (talkback, cue) the other.

I asked this question about a year ago and the results were mixed, as I recall. However, the barix units have improved since then.

Thanks!

 

[pellmell]

While I've never even seen a Barix unit in person, I have been following the recent discussion here. It seems that the answer to your question is that so long as you really understand computer networking, any of the Barix units will do exactly what you want. They seem to be about as difficult as setting up a home router when making your home computer available as a server over the Internet. What I do NOT know is whether the transmitter unit of the pair has to have a port forwarded behind the router. If so, you'd have to have access to the router at the ball field. If not, you should be good to go. I don't have a clue on 3G.

 

[pbf1]

We air two college football teams' networks on Barix boxes. Flawless.

(No clue about talkback or 3G.)

 

[ChiefOperator]

pbf1-

Could you please elaborate a little? Which bitrate are you using? How do you handle talkback to the studio?

Thanks!

 

[joshzz]

We too have found Barix to work very well. We have used it for internet streaming and have found it to be very reliable. I believe we use 128 kbps or higher.

FOr some live remotes we use ustream.tv and have found it to be reliable - great for talk - high school games etc.

 

[ChiefEngineer]

Barix has a relfector service in beta that works well. It allows the encode and decode to link automatically without setup at either end. A wonderful system that works. Reflector works on existing 100 Instream and Exstream units.

 

[LA_Guy]

You can use Barix units for remotes by either using the Reflector system mentioned above or by having a public static IP address at your studio and pushing the stream from the Instreamer to it. This also requires opening a port on any firewalls (routers) located at your studio. We have hundreds of customers doing this every day.

 

[ChiefOperator]

Thanks all for your replies!

Dana, for these remotes, how do bidirectional remotes perform? That is, a feed from the remote and talkbalk/cue from the studio. Also, how do these perform with 3G routers in the field.

Thanks....

 

[stephend2]

we have used the barix 100 units for remotes, I've not been impressed with the stability. They do not hand varying internet conditions, especially not over a cellular connection.

We were using around 70k, 44.1khz sampling rate, mono. We have moved to skype for now, comparable quality as long as we are on a good connection and much more stable. I have heard recently there is some newer firmware out for the barix units, I might give that a try in the near future.

On a land based net connection (same isp on both ends) we have a remote morning show that comes back on a pair of barix 100 units that is flawless every day.

If there is a way to make the barix units more stable on the public internet, I would love to hear some suggestions. I have a pair of the units sitting on the shelf right now to try some things out on.

 

[Charlie]

When you say "stable" and "varying conditions" - are you actually blaming the units (ie: locking up and requiring a reset) or the actual quality of the link ? The weakest link is usually the gap between sites A and B, so if the connection suffers from bottlenecking, then you would need to add a buffer so that short "blips" don't affect the transmission. I can appreciate the need for as short a delay as possible (clock starts etc), but the shorter the delay/buffer - the far more likely you are to have issues with blips and hiccups over the link.

 

[RolfTaylor]

When the network is bad, is when the sophistication of the codec becomes crucial for long term links.

There are many ways to compensate for lost or delayed packets. A simple buffer is the simplest, but adds delay.

Intelligent buffers, such as those used by Comrex and Telos only add the delay when necessary. The downside, of course, is the delay varies.

The ability to conceal the glitches from lost packets is another feature that helps when conditions are bad. Comrex and Telos use concealment based on psychoacoustics and work rather well. APT allows concealment by using very small packets. Because the apt-X does not use audio frames, the size of the dropout is directly related to the packet size. This is not true for the MPEG algorithms since they use audio frames - if any packet that is part of the frame is lost, the entire frame must be discarded.

Dynamic automatic bit rate adjustment is the final technique that can help under non-ideal conditions.

When you say "stable" and "varying conditions" - are you actually blaming the units (ie: locking up and requiring a reset) or the actual quality of the link ? The weakest link is usually the gap between sites A and B, so if the connection suffers from bottlenecking, then you would need to add a buffer so that short "blips" don't affect the transmission. I can appreciate the need for as short a delay as possible (clock starts etc), but the shorter the delay/buffer - the far more likely you are to have issues with blips and hiccups over the link.

 

[OKCRadioGuy]

http://www.telos-systems.com/ZephyrIP/index.htm The new Z/IP One looks pretty promising. I like the adaptive idea when it comes to cell networks. I can imagine sending someone out with a cellular USB stick in one of these puppies and the unit adjusting itself to keep working, even when there's congestion issues. I'm going to be using some of them for a project soon that will use cellular as a backup to a higher broadband link. The fact it will adapt to the available bandwidth was a big selling point to me.

 

[stephend2]

what we ran into on running a larger buffer on the barix is that when there is a dropout, it would go silent for several seconds while it brought the buffer back up to a certain level vs. a few 10ths of a second with a smaller buffer.

We have gone to skype for our sports broadcasts that are on unknown connections. Works great so far, even in the backwoods of MS.

 

[ChiefEngineer]

Reflector has been promising. I really want a one way barix protocol. This would be like a satellite delivered digital program. It would be a replacement for FM extra for example.

Encoder sends the programing digitally and it is decoded similarly. Depending on needed bandwidth look at the promising uses. 2 stereo one way stl systems on 67 and 92 khz sca channels. old marti gear could pass the bandwidth needed to use it as an stl system or high quality remotes.

Anyone have another product that does this?

 

[RealityCheckr]

Huh???

Many of the Barix boxes ONLY support one-way audio. Nearly all IP codecs support (and most recommend) UDP/RTP which is a one-way protocol even when it is used in both directions.

It makes no sense to run the sample rates needed to pass SCA carriers, it just means a lot more data. These can and should be delivered base-band and modulated at the TX site.

How does any of this relate to FM extra?

Reflector has been promising. I really want a one way barix protocol. This would be like a satellite delivered digital program. It would be a replacement for FM extra for example.

Encoder sends the programing digitally and it is decoded similarly. Depending on needed bandwidth look at the promising uses. 2 stereo one way stl systems on 67 and 92 khz sca channels. old marti gear could pass the bandwidth needed to use it as an stl system or high quality remotes.

Anyone have another product that does this?

 

[joshzz]

I would recommend that you consider using ustream.tv for remotes.

 

[ChiefEngineer]

Huh???

Many of the Barix boxes ONLY support one-way audio. Nearly all IP codecs support (and most recommend) UDP/RTP which is a one-way protocol even when it is used in both directions.

It makes no sense to run the sample rates needed to pass SCA carriers, it just means a lot more data. These can and should be delivered base-band and modulated at the TX site.

How does any of this relate to FM extra?

[/quote]

Extra is proprietary. If one could use Barix to act as Extra sending a one way no handshake required signal over an sca it would have a wonder of uses. (No one wants to send an sca over barix). Barix to sca, barix from sca decoder to remote point. An excellent way to send a stereo feed ( or 2 w 2 sca signals) over FM.

No handshaking could be used as it would stop the application. Now there is handshaking even if it is a one way application. This does not mean it is truly just one way.

 

[RolfTaylor]

I am not exactly clear what the point is, but are confusing layer 2, the data link layer and Layers 3 and 4.

FMextra covers both, but the data link layer is the really tricky (and proprietary) part. I expect (I do not know) you can send "user data" which could be anything, including IP packet-based audio. Of course at low bit rates mean you really benefit from state of the art codecs such as AAC HEV2 and can do without wasting bits on packet headers.

If you want to send IP data point-to-multipoint using UDP/RTP unicast streams over a uni-directional IP path you will need to deal with spoofing the address resolution protocol process (ARP) or it won't work. We are getting off topic, but if you are interested in this last bit (the IP network implications) I can post a link to the paper I delivered at NAB last year that covers some ways I have done it.

Huh???

Many of the Barix boxes ONLY support one-way audio. Nearly all IP codecs support (and most recommend) UDP/RTP which is a one-way protocol even when it is used in both directions.

It makes no sense to run the sample rates needed to pass SCA carriers, it just means a lot more data. These can and should be delivered base-band and modulated at the TX site.

How does any of this relate to FM extra?

Extra is proprietary. If one could use Barix to act as Extra sending a one way no handshake required signal over an sca it would have a wonder of uses. (No one wants to send an sca over barix). Barix to sca, barix from sca decoder to remote point. An excellent way to send a stereo feed ( or 2 w 2 sca signals) over FM.

No handshaking could be used as it would stop the application. Now there is handshaking even if it is a one way application. This does not mean it is truly just one way.
[/quote]

 

[Chuck]

If someone were to develop a box, similar to a Barix, that could feed directly into your SCA generator, and also provided a decoder box to connect to the MPX output of an analog receiver, then I think they'd really have something, especially if it were priced in the range of a Barix box.

I'm not the guy who is going to figure this out, but I think the person who does would sell a lot of them. I can think of lots of uses for such a device.

 

[RealityCheckr]

So, you want FmExtra and don't want to pay for it???

There are a lot of things I would like....

If someone were to develop a box, similar to a Barix, that could feed directly into your SCA generator, and also provided a decoder box to connect to the MPX output of an analog receiver, then I think they'd really have something, especially if it were priced in the range of a Barix box.

I'm not the guy who is going to figure this out, but I think the person who does would sell a lot of them. I can think of lots of uses for such a device.