• 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

Best compression for an STL

X

xmtrland

This question has two parts because I’m taking into consideration of an AM STL and FM. The STL is IP delivered via your favorite ISP and the set up can even have a main and backup ISP. I’m going to focus on two popular audio codecs. A Comrex Brick or Access and the Harris IP Link, IP100 or 200 codec. Tieline should not have a problem with the three codec algorithm. The Tielines in house don’t get used for an STL function.

Choices are:
Uncompressed PCM 32khz Dual Mono

128kb AAC Dual mono

192kbs Opus Dual mono

The FM Station of course Uncompressed PCM, but how about a backup, would you use AAC or Opus?

The AM station Uncompressed PCM, but does it really need it? Which compressed format would you use.

Both codecs offer error correction feel free to comment on how much.

Comrex has a feature called Hot swap that works with CrossLock where it will switch to a backup network connection hooked to your backup ISP, with minimal audio cut out. It does not keep the backup stream active (using Data) until it’s needed. It’s the reason you can hear a blip in the audio but at least it’s quick.

The Harris IP Link has Stream Splicing where two active streams (one delayed) preferably via separate IP paths are then spliced together to offer a robust audio out. But can be hard on overhead in PCM mode

The IP connection can be just an ISP or wireless IP link.

I have Harris IP links used for the FM uncompressed main (RF IP link/Harris RF HD link) and backup (Private IP link Layer 2).

The AM has Comrex and Harris IP links. The IP Link is uncompressed, Comrex 128kb AAC. I’m thinking of using Opus instead of AAC for the compressed format. I’m still testing fail over modes.

What would you use?
 
Unless you have bandwidth issues or are paying for volume of data, uncompressed will be the best choice for both services. For the FM backup, is off air monitoring important? Opus has fairly low latency compared with AAC but still significant enough to be a problem for monitoring.
 
For off air monitoring depends on what you mean. For my PPM encoder confidence monitoring, the MCEM and off air logger don't care about the latency or delay. Due to more things being digital these days most stations abandoned off air monitoring for talent years ago. So the answer is no to latency or delay is not an issue. But if your using Starlink as a backup you may want to run compressed for that if it were your backup.

I do backhaul audio for monitoring purposes but Opus compressed is fine for that.

Would like to say bandwidth is not an issue but sometimes it is. I have seen fiber circuits with lots of bandwidth have issues with momentary packet loss. That's where you do Stream Splicing or Hot swap. I have seen the cloud backup decide it wants the whole fiber pipe at the studio for the weekend cloud backup. You know the game as soon as you think your immune to one type of failure the plant proves you wrong.

I do like to run uncompressed. But if I'm using the IP Link and Stream Splicing, I'm using Bandwidth on both main and backup ISP. At one site the main ISP is Comcast fiber so lots of bandwidth and through put included. But the backup is Starlink and the Bandwidth cost more for that especially if your running uncompressed. Rather than Stream Splicing I'm looking at a fail over built into the codec to switch to the backup ISP. If I'm running Opus then the bandwidth is less with out much perceived audio quality loss.
 
I have stations with both Comrex and GatesAir Intraplex IP Link. Here's my obsevations for what they're worth.

I started with the IP Link 200 on an FM station. Initially chose uncompressed PCM at 48KHz. Almost immeidately I ran into issues with packet drops. After much experimenting I ended up with Opus at 48KHz. My theory is that with an RDP stream packet loss is unrecoverable. With uncompressed PCM you take a bigger hit with a dropped packet than you do with a compressed stream. While this doesn't seem to make sense, it is my observation, and why I ended up using the Opus codec. For a monitor return stream I settled on AAC-LC.

My next deployment was a pair of IP Link 100s for an AM station. Based on my experience with the FM station I started with Opus, but had issues (the site has only wireless internet), so went down to AAC-HE at 32KHz, and that's what worked best.

I've put up 6 Intraplex links for various stations. Been around the block with these.

Enter Comrex Briclinc II and III. I first came to them because a client had a TieLine BridgeIT pair as a link between studios, and it was always problematic. I got a free demo of a pair of BricLinc II units, and was sold in the first week.

First observation is that setup was a breeze. Nothing like the IP-Link, which required a LOT of fussing, including setting up static routes, etc. The Comrex was much more like plug&play. Second observation, and I'm not sure why, they deal with packet loss much better. As in no issues at all. They are now in alternate link positions for the first FM (usually is the link on the air), and main positions for other sites. I also have a bunch used for remote studios and remote broadcast (replacing TieLine BridgeIT units), and they were such a huge improvement there's no way to describe it. We still drop one link that's on a residential Comcast circuit (because infrastructure there is old coax and is pretty terrible), but otherwise they just work, wired, fiber, wireless, you name it. If I had my choice I'd only be using Comrex now. But I don't so there you go. It's rare that the simple/cheaper fix wins, but it does this time.

As a second-hand story, a friend at another station in my area has similar experiences. He originally had installed the IP Links, then went to Comrex, and is now removing the IP Links. I won't relate any more detail because it's not my first-hand story to relate, but he basically confirmed my observations.

As to settings, for FM Opus is fine, though AAC in various flavors can work in a pinch. Uncompressed is great if you have a very solid low packet loss link, but actually those are kind of rare. Redundant streams help, but burn bandwidth massivly, and the fail-over is not inaudible. I suggest 48KHz because that puts the link filters significantly above the 15KHz FM pilot protection filters, and we don't need to stack up in-band phase shift. For AM it doesn't matter, and 32KHz is fine. AAC is fine, Opus is better, but there are lots of flavors of AAC to try if you're bandwidth challenged.

The Comrex GUI has a great moving graph of data integrity. Intraplex doesn't, but keeps a log that's not too bad to slog through. Comrex support is great, Intraplex support is only great if you get the "one guy" who knows everything, otherwise the other guys are at the "have you tried a reboot" level and that's about it, by their own admission BTW. The problem is, I needed Intraplex support significanlty more than Comrex support.
 
We recently purchased a couple of Bric Link IIs and I can't say enough good things about them.
We are using them for remote broadcasts.
After an easy initial setup with their switchboard service they just keep working. The folks at Comrex are very helpful if you have any issues.
When you pair two units, they have an algorithm called cross-lock that monitors the state of the link and adjusts the link accordingly.
I think we are using AAC.
Great thing is that the switchboard service has worked with every ISP connection that I have tried (even ISPs with "secure" features).
Was worth every penny given the setup/maintance issues we had with our previous RPU link (implemented on the cheap).
 


Back
Top Bottom