Unable to solve...please help! (barix / stl question)

[duckfan98]

Start with the buffers as big as possible. Barix receivers have a 64k buffer which is only a fraction of a second at PCM data rates. Not sure about the encoder, but generally bigger buffers = more resilience.

So are you saying that a 999 buffer size wont be much of a delay? Wont it be around a second or so?...

 

[chriscollins]

Yes, but it will make you resiliant to drop outs.

 

[dfwhisp]

I need an expert here!

I cannot get PCM audio to transport over my STL via Barix link. I get horrible drops, jittering, etc....however, my IP link is solid at 50-70 MBPS. Not the public internet, a direct noise free 5ghz link. Very fast. MPEG compression works good, but I do not want to run MP3 for obvious (quality issues). Here is my complete chain...please take a look over and let me know if I am missing something obvious:

Source material WAV files, 32khz MPEG Level 2 5:1 compression ---> Automation System --> AES out to console via Digigram VX222v2 Card ---> EAS --> Henry Balanced to Unbalance box ---> Barix Instreamer 100 ---> IP LINK --> Barix Exstreamer --> Shielded RCA cable w/ ferrite rings --> Henry Unbalance to balanced Box ---> M-Audio 192 card (48khz setting) --> Breakaway Broadcast ---> M-Audio 192 Card out ---> Fxi60 Exciter (L/R) ---> FM1C1 transmitter

MPEG on the barix boxes work fine. Whenever I switch to PCM (any format) I get the horrible audio.

Am I missing something obvious!??!?

You need to try older version of the rtp stl app for that pair of Barix.

I do not know why, but newer versions of the STL app do that on a similar setup using Mikrotik RB-433 and XR5 cards.

 

[stephend2]

I would question too how noise free is your link, really?

What does the air rate do under load?

What channel width? I'd run 10 mhz which is still overkill for your application, will give a solid 40mbps + on a clean channel, also friendly to other wireless operators in your area.

what is the tx ccq on both ends?

How did you come to that 50-70mbps number over the link? If you used the built in speedtest in the radios, thats a udp test that does not report packet loss, may very well be that there is packet loss that doesn't show up at the lower data rate of an mp3 stream but shows its ugly head at 1+ mbps. I had a link do that, was on a dirty channel thats all.

I have one station that I feed thats on a 15 mile shot on 5 ghz working great, in a 20mhz channel mainly so I have enough bandwidth to go around as I also serve internet customers off their site.

Btw, what is the rsl on each end? it it pretty consistent in both chains?

 

[stephend2]

also, if you are available this evening, shoot a message over to stephen (at) newbreakcommunications.com I may be able to help remotely through a tool such as showmypc to look over all your settings.

 

[Bojcha]

Channel width in non-N mode should be 20MHz (no need for 40). If you use N mode then it's more.
CCQ is most important! Basicly it means Link Quality. It should be always at 100%! And also rates should be also at maximum. For both sides.
Since you ask for CCQ on both sides i guess you're using "bridge" mode (?)
Try to simply set "AP WDS" for one side and "Station WDS" for other side.

Station side Bullet5 (not N version) - http://i.imgur.com/mbVe3.png

 

[stephend2]

when I said to use 10mhz width, I was assuming ubnt M series gear which is 802.11n based.

I would also be sure to run airmax if possible, there is some QoS built into airmax that works quite well. I used to not run airmax on p2p links between towers due to the extra latency but as of firmware 5.5 the latency is just as low as plain 802.11n. I'm seeing ~1ms on p2p links now. Airmax is also much more resistant to interference than 802.11 as 802.11 by design is CSMA, it backs off tx when it detects anything else on channel. Airmax is TDMA, simply put it will talk over everything else.

 

[chriscollins]

I would question too how noise free is your link, really?

What does the air rate do under load?

What channel width? I'd run 10 mhz which is still overkill for your application, will give a solid 40mbps + on a clean channel, also friendly to other wireless operators in your area.

what is the tx ccq on both ends?

How did you come to that 50-70mbps number over the link? If you used the built in speedtest in the radios, thats a udp test that does not report packet loss, may very well be that there is packet loss that doesn't show up at the lower data rate of an mp3 stream but shows its ugly head at 1+ mbps. I had a link do that, was on a dirty channel thats all.

I have one station that I feed thats on a 15 mile shot on 5 ghz working great, in a 20mhz channel mainly so I have enough bandwidth to go around as I also serve internet customers off their site.

Btw, what is the rsl on each end? it it pretty consistent in both chains?

We are Stephen's station on this link (I think this is the one he is referring to). We feed it through another ISP in another city and do FLAC 15K in our Comrex. It practically never bumps... Ever.

We are (on Tuesday) going to change it to a Barix (because we have another purpose for the Comrex), and put it all on Stephen's network. I would expect once we are all on his backbone, that it will be more solid than it already is.

 

[duckfan98]

Ok. So today I went to the studio and did some testing.

I am still unable to run any PCM... I tried 44 and 48 khz, with a buffer delay as high as 4000. At 4000, it was considerably better sounding - however - I still get a 'garbled' tweaking / robot sound about every 10-15 seconds.

Any further suggestions?? I am running the latest STL firmware on both the studio and transmitter end.

 

[oldiesstation]

It was suggested you consider an earlier firmware version,perhaps the one before this one.But before that i would ask Stephen to look at your access points and Barix setup. You never mentioned distance between points and whether you has clos....It sounds like:
A buffer on barix
B packet issues in radios
C possible line of sight issue
D The latest and greatest firmware may have issues.

I think you would find the Barix 500 much easier to work with..

email [email protected] he is stateside and prompt at answering emails..

 

[duckfan98]

Sorry, but yes I have clear line of sight. Its a 3.1 mile straight line of site....

I'll try and downgrade to earlier versions of the firmware.

Also, one other thing I noticed - they headphone jack on the Instreamer does not work with the STL firmware I have installed. It does work however on just the normal, default client firmware...does this make any sense at all?

 

[stephend2]

I observed this as well running the STL firmware. Instreamer headphone jack does not work, exstreamer does.

 

[stephend2]

also, yes chris I was referring to your station, actually both of them. WBBV is running 44.1 PCM through our network and I have not heard any glitches in quite some time since a routing issue downtown was resolved.

 

[fugazi]

A better way to test link capacity is to use bigger ICMP frames.
Standard ICMP ( ping ) is just 64 KByte and will in most cases work out perfectly. So to just ping a device will only tell if there is IP connectivity and nothing more.

Under linux -> use bing
under windows: ping ip_addres -l 8192 -t ( -l = -L ( small letter ) no i ).

Sometimes bigger frames get truncated. When this is the case half the ICMP size until you get a response and then increase it again until you see packet drops ( ping timeout ).
A ping with 8192 bytes will put a symmetrical load of about 8 x 8192 on your link ( in kbit/s ) . If you get a response with 8192 bytes, increase the size until you experience drops.
Ping from ubi to ubi, try to avoid pinging to other machines then the ubiquiti devices ( some devices like routers or other embedded devices tend to drop big ICMP packets or they just truncate them to smaller sizes ).

With my ubi's i can ping with 65000 bytes without any dropout ( 3 mile link ). 65000 bytes x 8 = 500 kilobit/sec.
On a weaker ubiquiti link i achieve around 16000 bytes with rather high round trip times ( which is also a measure for link quality ) and occasional drop-outs.

BR

Evert

 

[chriscollins]

also, yes chris I was referring to your station, actually both of them. WBBV is running 44.1 PCM through our network and I have not heard any glitches in quite some time since a routing issue downtown was resolved.

KLSM does well on the Flac 15K. I don't think it hiccups anymore. We have a watchband hooked up there now, so I can listen remotely off air to any of the FM's.

 

[LA_Guy]

Use the Barix IP intercom firmware on both ends and then select "Raw UDP" for the transport protocol. This will likely fix your problem.

 

[duckfan98]

Use the Barix IP intercom firmware on both ends and then select "Raw UDP" for the transport protocol. This will likely fix your problem.

Thanks LA_Guy, will this provide high quality PCM?? I assume so, just thought I'd ask... I've tried the STL and Streaming Firmware with no luck - but havent tried the Intercom

 

[LA_Guy]

It will do PCM at up to 24 kHz sampling, which gives flat frequency response to 12 khz. I have used these on FM and literally NO ONE could tell the difference with full 15 khz response. It actually sounded subjectively better because there was less HF limiting on the tightly processed audio we were doing.

 

[RolfTaylor]

Reread my earlier post and TEST the link as I suggested.

That will independently test the link and will point you to the link or the codecs. Number one rule in troubleshooting - divide and conquer.

Ideally do the pings at the same packet size as the codec is using. Do you know what size that is? If not, find out. If greater than 512B the MTU issue is worth checking into as well.

Best of luck.

Rolf Taylor

 

[duckfan98]

Rolf; with all do respect - I know how to test connection speeds. As I mentioned in my previous postings...the speed is rock solid. In fact, today I ran a vigorous speed test just to confirm, and I was able to consistently push 40+Mbps UPLOAD on the link.