I think the SD already provides a solution for this situation. The alarm task queue may cycle in a loop from a selected line until the sound is finally detected. This loop may contain pauses, application restarts etc. The loop is created by the Repeat command.
Let me try to understand.
I put a line in to "initialize" my application. This is a kill command for the current play window. This allows me to accommodate any normal silence errors.
The next line starts the app up from a command line and automatically loads the parameter it needs to find the website.
If the sound starts, SD finishes its detection loop and goes back to listening for silence per the settings.
If sound does not start, the player app has stalled for some reason and just stops. It doesn't kill itself or allow a command line parameter to kill it if it errors. It just stops.
SD sees the app function but there is no sound so it does not finish the loop it started. Or maybe it does finish the alarm loop and just doesn't start looking for sound until it senses sound for the first time. I do not know.
There is a check box that forces it restart the detection cycle, but only if it detects sound.
This is where I am stalled right now.
I see I can add delays to the alarm queue, but they do not interfere with the executing code. Adding more instances of the radio software without killing the present instance produces a double feed. Bad bad bad for listening!
In short, I do not understand how I could use your idea to make this work.
If I could simply kill SD after an alarm action and then restart it (maybe with a batch file that kills SD and restarts it a few seconds later) I am certain that would work.
This would allow the radio software to be monitored and left alone unless an alarm condition, no sound indicating an error, occurs.
And maybe I am misunderstanding the whole thing...I'll keep experimenting.
