Archive
Why Dante by Audinate?
I have mentioned Audio over IP (AoIP) in posts and on my site. I have been using AoIP for years to do remote broadcasts, normally using Tieline codecs, but have used others. I was one of the early adopters. I also decided years ago to run our studio to transmitter audio over IP. Due to space constraints and other factors I decided on the Worldcast/APT codecs. All have worked very well. When the stations had to move I wanted my AoIP platform to be Dante. I am glad I did.
There are three notable choices for AoIP on the broadcast industry: Dante, LiveWire, and WheatNet. Two of these are proprietary and do not have to pointed out. Only one, Dante, is an industry standard most notably in the audio/video industry and live sound. It is used worldwide in major venues. The list goes on and on. Just visit the Audinate Project Gallery. If you need devices and interfaces, why there are a whole slew of choices. Any time you need to interface, just check out their Product Catalog where you can research what you want, but do not pass over Audinate’s own devices, the AVIO adapters. Though I have not needed one, I think next year I will pick up a couple to have for the rainy day emergency! How could I pass on choosing Dante for my platform of choice?
Overall, the installation was a breeze. In my next post I will detail our basic installation, but for now just an overview. Though Audinate is designed to run on your existing Ethernet network, I am a strong believer in keeping mission critical separate, so I installed a completely separate network just for Dante. This makes life super easy as all you need to install is a good core switch and home run all your connections. At this point, as Dante will automatically configure its own IP addresses you can just let it happen. I actually manually assigned all IP addresses. Once you have a couple devices installed, you will see them populate in the Device Manager software. Using the Device Manager, make your audio connections and you are off to the races.
I am a Sierra Automated Systems (SAS) plant. With the new KDL modules and Rio Bravos, interfacing Dante to the routing system is quite easy. Again, you need to make your routes in the Dante Controller first, but once you have them available, that audio is not available in the SAS routers just like any other audio. SAS is working with Audinate such that they can control Dante routing through their system from my understanding. Seems like a complex challenge, but if anyone can do it, SAS can.
Stay tuned from my next post about the details of installing Dante, the devices, and configuration. Being an industry standard makes for easy integration with many devices. Mackie comes to mind. As for up-time, I have not had any issues with our AoIP setup. It works, and that is what counts.
Headaches of the Week!
So, what were you headaches this week? We all get them! I had one when the weather went from dry, to almost normal, back to dry again. That was a one day actual headache. The daily grind headaches were power supplies and WideOrbit configurations.
The easy fix was the power supplies for my Nautel NV20s. Yes, these are those two which were installed Dec. 2008. Still running strong, but as it ages, those power supplies tire out. What is awesome is they are easy to swap out. Pull one out, put one in. Done. Like taking Advil, pain gone.
WideOrbit on the other hand is a different story. This is combined with the fact that Jelli/Katz shipped new hardware to replace the aging appliances. I changed from 5 separate servers to 2 servers. I got them babies installed and audio plugged in. I changed the ports configured for the WO Device Server. I give Traffic the go ahead to schedule them tests. ALL OF THEM FAILED.
Well, they worked before, so I checked the configurations again. Dug into the actual WO Device Server configuration file on each workstation and what do I find? Instead of changing the “entry” for the configured port, it appended a new one! WTF I say. Check with a colleague and sure enough that is what he has been fighting for months while the pair were nailing down the metadata feeds. Every time you make a change, it doesn’t change anything, it appends the damn thing. Argh.
Last night I thought I had it, and I only received dead air on one station. Sure enough, appended change. Then Jelli and I agreed to move/swap two stations so everyone’s docs matched up. I did a test. Nothing. Wait, I checked and cleaned up the file. Oh, no, there is another line in there which referred to the OLD entry! Things like this makes you want to bash your head against a wall to fix the headache. I corrected those, so we will see how these two stations run tomorrow morning.
I’m saving the last as it has the most complex configuration file as the station uses GPIO along with metadata and Jelli. Best to pick on it separately.
I hope your headaches are easy to resolve and treat. Speaking of treats, Halloween was pretty quiet last night. Remember that next year it will be the weekend, so all Hell will break loose!
Cheers!
Only Tuesday….
Update on my Omnia 11. It has been received and the estimated time to repair is 2 weeks. This is fine as the unit on air has been accepted and reports are they like it. It is a demo Orban 8700, btw. I still need to dig in and see what else the thing does.
Running an HD3 channel which has been directly fed from the source. Now they need to run local commercials. I told them when they had logs ready I would activate the final parts to make it smooth. Guess what? They didn’t. Logs are a bit of a mess, so now I need to figure out what they did.
Meanwhile today I am swapping out Jelli appliances. I guess they decided to put newer hardware in and most likely software. So, with those messing with one thing, I bet doing this next bit will be annoying filled with interruptions.
I feel my head will explode with the lack of communications, which is the norm for a communications company.
Processor Revisited
Now doesn’t that take the cake. Just before taking some time off that Omnia 11 started to do its degraded audio again. Stereo squished in, dull, sounded almost mono. I was thinking maybe multipath as it is that time of year and the weather does mess with the signal here. Yet, if sitting in one place you can hear the audio change makes you scratch your head. The decision to swap out with another processor was made.
Ran an old 8500 for a few days. Other than the fact it is an older device, at least the audio remained consistent. Right before I left the boss man decided to get an Orban 8700 demo. I slapped it in and said let me know. After over a week no complaints from the programming. I decided to ship the Omnia in for “repair”.
I hope they find something, but I feel it will be the old we cannot find a problem. I guess I’ll let the world know what happens. BTW, the program director seems to be quite content with the 8700.
Processor Trouble?
Received complaints from PD about some odd changes on air in the sound of the station. Last time this happened I basically pulled the AES digital input briefly. Once it was back in all was stable again. Thought nothing of it as little blips and burps occur in the electronics world.
Today there was another complaint. OK, a couple months have passed, we had some fun, let’s check things out. My first indication of a possible issue on the Omnia 11 is the fact that when I look at the detail page of the input settings I saw AES Sync: Unlocked. Now that is very interesting. I run a SAS shop, so my reference for anything digital is this system, and if one box is having issues, then all units would have issues. I spot checked anyways. All 48kHz sample rate, all good. Let’s do the old unplug the AES input from the processor, wait a moment, and plug it back in. No, still unlocked. time to dig.
I look at the output of the processor to see what it should be synchronized with and find that it was set to External. No, that should be set to Input as I am using the SAS as my house clock. Changed it. Still AES unlocked. Let’s plug a source into the External Reference on the processor. Still unlocked. Now this has become interesting, so back to the output and change it to sync with the internal at 48k. AES unlocked. I believe we are due for a reboot, so I check online for any updates. I see there is a 3.6 for the Omnia 11, so I get it. In addition, I send a note to the Alliance. They confirmed the unit either needs a reboot, or there is an I/O issue with it. Tomorrow I get to test this theory.
A new day and morning drive is over. Let’s play processor roulette! I double check and make sure I still the AES sync still unlocked. I have a spare Orban 8500 setup and ready to go, so let’s do this. Uploading the file is a breeze. As the first thing to do after the update is applies is a power cycle, everything gets a fresh start. Mental note I saw that the I/O board received and update during this cycle.
After a few minutes, like almost 10, the processor is up and running. Only details is to apply the saved I/O configuration and preset. First thing I check is AES sync. It reports locked. I change the setting to sync to input. It stays locked. I’m good to go. I figure I have another 11 I proceeded to update that one, too. Only time will tell if this is permanent. Being a computer, it does not surprise me that a reboot would take care of the issue. I will continue to monitor this and keep an ear out for screaming PDs with audio degradation!
Cheers!
When Old and New Don’t Mix
A few months back the decision was made to “rush” a MaxxCasting system. The company teamed up with GEO Broadcasting and GatesAir to have this system installed. Currently in analog mode it works fairly well. When the baseball season finally ends, we become the test for doing HD as well. Check it out, it is interesting. The part I have issues is making the old, a 2006 Harris (GatesAir) HTHD+, and the new, a Flexiva FAX50 exciter, play nice.
I knew I would have issues from day one with this installation. Having no involvement other than being told what needs to be done, providing input was limited. At the onset I informed everyone on this project by interjecting a simple question: Will there be any issues utilizing our old HTHD+ transmitter for this? An early 2006 edition of the HTHD+ transmitter as we were “forced” into the early adoption of HD radio, this transmitter installation was a rush job from the get go. As an amplifier I have never had any issues with the transmitter, but I have had issues with exciters. We had 3 different Flexstar exciters in this thing, yet I have only replaced the tube 4 times. Anyways, the answer to the question was basically, yes, don’t worry about it.
Without being involved other than do as you are told routine, the day came to install the FAX50 as an exciter. Without a full rundown of the Geo-synchronization of the whole system, let it be known the Flexstar was not capable, thus the swap. I has the exciter out. I had the filler plate. I had cable adapter kit. Whoa, hold on. The kit labeled for a Z series transmitter? I told everyone this was an HTHD+. Hmmmm? Let’s proceed with getting the new exciter installed in the transmitter. After the first indicator of an issue (the cable), the second indicator of more fun to come was the fact that the exciter did NOT go into the transmitter! I was told otherwise, and I was provided with no instructions. Phone call time. Sure enough, the interface kit was wrong, and no, the FAX does not fit inside the transmitter, but must be externally mounted. New interface cable kit and instructions were on their way.
The new cable kit arrived with the new instructions. Now things began to make sense. I cleared out rack space and place the exciter in a location that was just accessible to comfortably been seen, i.e. not at the top of the rack, but at least a quarter way down. That was the maximum length of the new cables. Installation complete. Testing into the station load I got to learn how to setup the exciter as it did not come setup for our station. It was setup on the wrong frequency and as a transmitter, full 50 watts, not as an exciter of which we run about 4 watts. Details of this for another time. Rest assured it was not too bad and I had the transmitter back on the air soon enough.
Mixing the old and new. As we all know, the HD E2X, or Exporter to Exgine, stream will have packet drops on occasion or some other ISP induced oddity. In the case of anything somewhat prolonged or unusual, the exciters are designed to shut the HD off, suppress the carriers, and the station goes analog only for that brief time. When the E2X stream returns, the exciter detects it and HD carriers return. All good. Well, the FAX series exciters are some fancy boxes and are designed as stand alone transmitter. These range in power from the 50 watts to high power. As such when the E2X is gone, FAX is designed to drop power level and normalize to analog operation. When the E2X stream returns, the FAX adjusts, the power level changes to accommodate the HD carriers. All good when in an all inclusive box, when driving an external transmitter it causes some serous output power swings, and at times even a brief no power out. Our transmitter is licensed for 18kW TPO. I have witnessed this drop to zero and shoot to about 20kW all within a few seconds. I had four occurrences just this morning of lower power alarms followed by high power alarms. The APC and drive level required drops suddenly during this incidences that the transmitter PA cannot handle it. I wonder what stress this will place on my recently replaced tube?
GatesAir is aware of this and is considering options. I have suggested to the company they may wish to just upgrade the transmitter. We will see. I think the lesson that reinforces my philosophy is not to attempt a new project which mixes technology without considering all the pieces, and be prepared to invest in replacing the old even if it is going to cost you. Consistency is key to a smoothly running plant.
Cheers!
WideOrbit Automation & EAS
When we made our move into new facilities, we had to change our automation/playback system from NexGen to WideOrbit. At first we thought that it may be a good change. Maybe even take care of or streamlining some of the processes. The plan was to continue with an IP based facility, so we needed to make sure there was not falling back to a ton of cabling and physical GPIO for this. Well, a year+ later and we continue to fight how to reliably and consistently run EAS tests from WideOrbit.
As we saw this was turning into and issue, we setup our Sage Endec to send a RWT on Sunday mornings while we worked out the details of how WideOrbit deals with them. This has turned out to be a good thing as various attempts and inconsistencies caused scheduled tests to be missed. We would make them up, or attempt to, as soon as we found out of such events, but some got through. This begged the question why? We stuck one of our guys on it. Week after week, months gone by, there was no rhyme or reason to why some worked and some didn’t. Unfortunately we had cutbacks and the person working on this was released. The void had to be filled and I took up the challenge.
I had, with a little work with NexGen support, the Endec and NexGen working well via Ethernet. Weekly tests were scheduled and they would run. Monthly tests or alerts came in, and NexGen would drop them into the log, fire them, and resume operation. This was 7+ years ago! I believe I even wrote about it in a previous blog. I began to dig in and find out what is so different here that we cannot do the same.
The WideOrbit documents show a log of information if I wired up GPIO, and they do have the EAS widget. I began questioning operators on how they used the system. What did they do? Who did what when it worked? Who did what when it didn’t? Yes, using the widget produced different results. I decided to dig deeper and pulled out the trusty Ethernet tap and placed that in front of the Endec. Data gathering time has begun. I learned a lot of what the Endec sends and what it wants to see. I sent notes to Sage support for clarification. I now know what the heartbeat is. I know what a query from the workstation is and the Endec response. Time to see what happens when they run their tests.
My packet captures were full of fun stuff. One forgets that the Endec, and all EAS units, communicate with the CAPS servers, so all that traffic I knew had to be ignored. Pretty cool though to see the chatter, but time to filter that out. I only cared about the talk between the workstation and the Endec. There could be much, but then I noticed the Endec sending a series of strings consistently timed. The heartbeat. The Endec sends a heartbeat to tell systems the unit is there waiting to play. Included in the heartbeat is the expected delay if a RWT is run. In our case it is 14.45s. I never knew that, so something new is learned. Then I see a packet sent from the workstation and the Endec immediately replied. I learned that this means the EAS widget on the workstation was definitely connected as this was a query to the Endec, “are you there?” The Endec sends a reply code, so all good there. Why are tests not being run?
After much digging, and observations, I still did not know why the inconsistency, so I reached out to our engineering community. With a couple of responses of positive results, I needed to chat. The main thing that came up and was consistent between the two engineers was the fact that a test run via the widget was dropped into the stack. From the information I received from our operators some would drop the test into the playlist/log in advance of the test, while a few would drop it into the stack. I took this information and decided to put it to the test. I went to each of 4 stations control rooms and asked, stack or playlist? The answers were mostly playlist insertion with a couple of stack if it was convenient. Each station we dropped the test into the stack. Each time it triggered. Part one of the mystery may be solved. Instructions went out to the air staffs’ to use the stack insertion.
All this fine if you have someone in the studio to run the tests. These days stations are unattended a good portion of a day to all day. How does a system like this deal with these situations. Turns out WideOrbit really does not have a system when using Ethernet or IP control. If you are wired for GPIO they have some provisions. So, I decided to experiment and see if I can at least fire a RWT using a workflow. I configured a workflow with the instructions to connect to the Endec’s IP address and port, and send the string to run a test. To make it testable, I put it on a hotkey so I can fire it at any time. The moment of truth, I click on the hotkey. I check out the Endec. Nothing. I do it a couple more times. Nothing. I create a telnet session from the workstation to the Endec and send the command. Works like a champ. I check the WideOrbit logs and they claim the workflow ran and sent the string, but the Endec did not respond nor did the packet get captured, but he telnet did.
At this time I am at a loss on how to make a completely working IP control of the Endec using WideOrbit. In today’s time and the proliferation of unattended stations one would think this would be of high importance. When asked, WideOrbit support responds with run the Endec in automatic and let it run. I hate to say it, but when you are in a top 20 market the last thing the PD, GM, and sales manager wants to hear is an EAS test stepping all over a commercial break or song. Sure it can be done with GPIO, but to me that is an 80’s, last resort solution. Leave a comment if you have any thoughts.
Cheers!
Should I or Should I Not
So, I’ve been a been absent on posting. I began to start wondering how helpful my blog posts are. Leave a comment if you think these are worth it.
Question: Do you want to see more posts?
Question: What subject matter, or should I post on what I am doing?
I also dropped social media due to the inundation of junk that was not worth weeding through. A shame that people cannot use tools properly and effectively. In any case, would a twitter feed by useful again?
Cheers!
Bill
Happy Holidays!
A long year is coming to a close. Here we were involved in the most complex and annoying facilities move ever. As I gather notes, I think I will post some highlights of the move. I am also going to take the age old advise and say, if you have nothing good to say about someone, do not say anything at all.
Have a Happy Holiday season and best wishes for the New Year!
NAB Show 2017 Recap
I had to cancel my NAB trip this year!!!!
So there you have it. The recap of the century. What was the excuse to cancel? It was cancel, too. All plans were made: flight, hotel, appointments, dinner. All cancelled. Oh, the excuse: One of our stations decided to change formats!
First we are on the back half of our facilities move. More on that someday. Needless to say, there are many things that are not in place or implemented at this time, so a format change does not make life too easy, especially when one of the staff was on vacation. Well, we did it. Format done, but many important meets were missed.
The life of radio sure makes things interesting and last second changes are among them.
Cheers!
PS: I was involved with putting the first AM all sports station on the air in San Diego. I now can say I as involved with putting the first FM all sports station on the air in San Diego.
Tech Notes from the Field 