Using Alexa for content? Solved...

Out of the mouths of robots

I hadn't thought of that, but can see how it could be done cleanly if someone was proactive and recorded it, since if it's loose with timing, then it would be hard to schedule properly, unless you had a routine that could pick it up, record the report, and then insert it as a file in your playback system, delayed.

You'd have to watch that the Alexa device didn't pick up any voice activation and wake up, which might get recorded as a report, or that an ad or something else wasn't included with the report itself.

That opens up possibilities, like getting news reports the same way, shows and other feeds, or the voice could read text feeds, so you wouldn't have the scratchy, phone quality audio from weather services, and it would fit in better with music stations especially, where the voice should be smooth to fit in. The voices could read other things, and after all, if iHeart wants to go to AI, and computer announcing, those of us in low power radio ought to have the same options.

Someone had some scheduling software that was promoted here or on some other site, and I believe it was for Zara Radio. Maybe that author can ring in on this.

Boomer

Dr. Bob, I like how you have your own domain at mram.us now, that seems new, I remember it being something else, like 10000webs or something like that. You must have one of the longer running sites in Part-15 by now.

Did some further testing, using the Alexa device for on-air playback.  My initial tests showed the while the Alexa device could, potentially, work, there were timing issues.  Specifically, the time from the device encountering a Routine command and the device responding to it varied.  Sometimes, it varied wildly.

As an automation system I use StationPlaylist, so, using Creator, I inserted the Break Notes into the rotation, that, at the top of the hour, initiated a, hard, step to the next event, which was a station I.D..  To make this work well, I highly recommend placing instrumental material near the top of the hour.  After the station I.D., a Break Note is placed that initiated the Line-in event, to open the port and allow audio from the Alexa to be heard on the air.  This is where the timing issues came to be problematic.  

Initially, I provided a 30 second space of time for the Alexa event to be completed (play weather and then play the time).  After this event the automation resumes with the rotation.  Most of time time, the delay between the end of the station I.D. to the start of the Alexa audio starting was between 5 and 10 seconds.  This wasn't horrible, not was it wholly acceptable. The delay between the end of the Alexa audio and the continuation of the rotation routinely ran about 10 seconds, as well.  The Break Note timing was edited to reduce the overall time.  

For the most part, this idea worked well.  However, there were occasions where the delay of the start of the Alexa audio ran over 30 seconds, resulting in no Alexa audio being play to air at all.

I'm going to think this through some more to see if there might be a way to tighten things up, but I feel I may be disappointed.

(The testing covered an "on-air" timeline of 8 hours, to attempt the determination of the delay timings.) 

I wanted to document this process and resultant information not only for myself, but, also for others who might be considering using the Alexa device for some type of automated on-air audio programming.

Rich

While it is not my intent to overpopulate, or take over any post, or subject, I'm onto another track with utilizing Alexa content on-air.

If you've read the previous posts, you know that using routines is faulty, because of the time it take the Alexa device to actuate any response to a scheduled item.

I've decided, in my next attempt, to try a voice activated recorder, which can be scheduled.  Basically, turning the tables.  By setting the same type of routines on the Alexa device, and using a voice activated recorder, starting the recording process based on a schedule, the start delay should, in theory, not be an issue.  The "stop" time of the recording process should be the only issue, depending on the content.

We'll see how it goes.
Rich

Incidentally, if you'd like to hear what it sounds like, please listen at this link.

Rich

After extensive testing, with more testing to go, I believe that the schedule issue has been solved.  Admittedly, a little assistance from the horribly slow support team from NCH Software was required.

Over the last 24 hours, the weather forecast was able to be delivered and, successfully, recorded for on-air playback, from an Alexa device.  The process of getting things set up and operational was, for me at least, an involved on, that took much longer than I thought it would.  A little background is required to explain all the steps...

My wish was to be able to have an up-to-date weather forecast played to air, every 3 hours.  The playback times I had in mind were (military time): 0000, 0300, 0600, 0900, 1200, 1500, 1800, and 2100.  To begin with, I set up Routines on the Alexa device, which would allow the device to complete a task without having to have any outside instigator (voice command).  This task, for testing purposed, has been a pretty simple on - simply say the weather forecast.  

If you've followed this thread, you know what a pain in the ass the Alexa device is when following Routines.  There can be as much as a 30 second lag time between the scheduled time of the routine to when the device actually takes action.  This issue complicated what I, initially, had hoped would be a fairly simple job of just creating a schedule of Routined for the Alexa device to follow and then playing the device live-to-air, via Break Notes within the StationPlaylist automation software that I use.

After finding out the Routines alone were unreliable in their execution, I had hoped to record them and then air them.  Simply recording the audio, because of the undefinable delays of the Routine processing, I needed to determine either what, in reality, the delays were to a time limit that would work for broadcasting, or figure out another method of recording the audio.  Because of some of the discussions on this site, and others, I thought that using a voice initiated recording application might do the trick.  However, that led to some additional complications and requirements.  One would need to find an application that would not only record on the detection of audio, but that could be scheduled to record only at certain times (so as not to be affected by recording other audio outside the Routines set) and, hopefully, keep the use of storage resources to a minimum, having the ability to record to the same filename over and over, overwriting a previous recording when needed.

Numerous applications were tested. Most didn't fit the bill of requirements.  One, however was found that looked promising.  RecordPad, from NCH Software.  The application looked like it could do what needed to be done.  The application was put through the test process and failed miserably a number of time, in different ways.  On the initial set up, the application was to record and store files in an MP3 format, which failed due to an operator installation error.  Subsequent tests failed because of the applications inability to follow the simple schedule that had been created.

After correcting the initial issue (MP3 format), I began my deep dive into the schedule issue.  The problem was that of the 8 recording times I had schedule, the application was only working properly for half to 3/4 of the time.  The scheduled recording would either not take place at all, or at the wrong time.  An example might be that the 0300 hour scheduled recording would happen at 0900, or 0000 hour.  The schedule, within the application, was removed and re-created numerous times, to no avail.  The problem kept returning.  However, there was some commonality, in that the issue always seemed to return to the same items within the schedule.  After a lot of looking around, and beginning to look for other applications to replace RecordPad, and back and forth with the, extremely slow to respond tech support, I found out that the schedule created in RecordPad was dependent upon a subsequent schedule it created in the Window Task Scheduler.

Looking at this, and comparing the two schedules, it was noted that they were different.  The differences were on the same problematic recording mentioned.  The RecordPad schedule was correct, but the Window schedule was incorrect.  Initially, the Windows schedule was manually corrected.  After the manual corrections, the problem still existed.

So, taking the advice, of the ever so slow, NCH technical support, I removed the application and all of its supporting files (including the hidden, or not easily found items) from the system, rebooted and reinstalled again.  After re-installing and, carefully, recreating the schedule, I hoped to test again.  I did, however, prior to starting the tests, check the Windows Task Scheduler against the RecordPad schedule.  I corrected any discrepancies, again and began testing.

Having done all this, and after over numerous hours of testing, the first 24 hour test period has worked successfully.

I will try to gather some screen shots of the application and how it is configured, for others to refer to, if they are interested.  

I will keep an eye on everything for, at least, another 24 hours, before on-air-use, in hopes that the success was not a fluke.

Rich

If you are interested and would like to hear the results...
wimpradio.us.to:8000/;

I'd recommend listening between the top of the hour and 15 minutes past.

Rich