Well, although I am not confident about this - I can make a few assumptions.
Although there is no source for an RTC within the beast (no hardware), there must be some kernel clock support to help the kernel operate it's tasking and time slicing. The main timer would just run from 0 upwards at startup, instead of a real time value maintained by RTC hardware. So, in all likelihood, there will be timer routines available in the kernel libs linked to the kernel. You could then write a stand-alone application that functioned as a sleep timer. This could be started at boot time in the startup script (or is it done with init? I forget). Making it available at the user interface would be a little difficult as we as yet don't have access to the menus. You would have to control it with a command line interface at the console, which would require the use of the developer image.
The main problem would be what the resulting action of a timeout would be. You somehow have to either poke the empeg player to stop, or have access to a kernel routine that would shut down the while box.
The empeg player itself can be paused or stopped from the terminal command line. If you can some how feed the standard input of the player with ASCII command strings, this would be one method. Perhaps the startup of the player could be modified, and then you could use the "tee" utility to pipe input from your timer app and the console at the same time to the STDIN.
Alternatively, if the empeg app supported signals, you could hit the player with a SIGXXX signal (where XXX = HUP, INT, SEG, or whatever) and it would run it's signal handler appropriate for the signal you sent. Although Mike or Hugo have not described if the player app does have signal handlers built in, I am certain they are in there as they have both mentioned, for example, the Power down hardware interrupt, which requires the player to save it's current status and bail out. Now, which signal is it?
Finally, if a UNIX app does not provide a handler for a signal, usually a default action is carried out. In some flavours of UNIX, this is to ignore the signal and take no action, however this is a little rare since it would mean that the application could miss critical interrupt conditions. More frequently, the default action is simply to kill the application when an unhandled signal arrives. You could take advantage of this default behaviour to kill the player.
The problem with this would be that I believe the player is started with a "respawn" option - ie. if it dies for any reason, the kernel spots it has gone and creates the process again. You would need to turn off the re-spawn behaviour in the inittab.
It's not impossible, just a little unwieldy. It would probably be better to have a proper signal interface definition to the player and use legitimate signal handler functionality - for which you would need to petition Mike & Hugo. I can't see why they couldn't use the user-definable signals SIGUSR1 - SIGUSR3 to carry out functions such as PAUSE, STOP, PLAY, since all it would require would be to write a SIG handler routine that catches all incoming signals, then calls the same functions internally as those invoked at the command line.
Mike, is there a set of defined signal handlers built into the player?
What is the default signal behaviour for this kernel (KILL, or drop)?
Do you have a signal handler in the player to handle HUPs and so forth?
If so, would you be willing to build despatch routines for the three USR signals to handle PLAY, PAUSE, STOP?
Previous Topic
Index