erland;541967 Wrote: > I was thinking about a simple one, not a flexible "CustomAlarm" applet. > It doesn't have to take care of all corner cases, it just have to > satisfy the users that isn't satisfied with the stability of the > standard one. Some users would have to choose, either use the standard > one to get features or use the third party one to get stability. > > Building one that is as flexible as the standard one definitely needs a > lot of work, I was just thinking that a simple one might satisfy a lot > of users who are happy just waking up the correct time. > > Everything could be stored locally on a simple one, no need to > synchronize settings with MySB or any SBS instance. It would just use > SBS or MySB to play the alarm sound and use a fallback file on the > local file system. We could even only support the fallback file and > offer the user an option in the alarm popup to easily turn off the > alarm and start playing one of his presets/favorites.
You're both right that it won't be as easy as it may first appear. Despite the fact that it *should not* be all that difficult in the context of the scope of the problem, there are several reasons why it would be hard (though certainly not impossible) in practice: If the same Radio front panel user interface is to be used (which is a good idea, in my view) then the existing alarm functionality would have to be entirely bypassed/disabled from the outset. One could use the same user interface that exists today and just reroute the I/O to/from a new applet, however, the way that the alarm handling works today means that removing the functionality cleanly won't be easy. Firstly, input from the Radio front panel doesn't always seem to go directly to an applet. In the alarm case, much of it is handled by SqueezeOS unbeknownst to the applet. The configuration and control of alarms is not modular and constrained to being handled at the alarm applet itself. SqueezeOS does specific things with alarm events (including those emanating from Radio front panel use) that are not obvious to the applet. The server should only become involved with the alarm case when the Radio requests a stream for playout. There is no other rationale whatsoever for its involvement. Later, the alarm setup paradigm could be extended so that an http interface was provided to optionally configure alarms - however, if that decision was ultimately made then alarm configuration information would need to be made available remotely (beyond the Radio UI) by the new implementation. In any case, such a UI extension would only be reasonable if it did nothing besides allow configuration and display of Radio alarms - essentially a replacement for the Radio front panel. A redesigned alarm applet would make the most sense if it were able to speak directly to the Radio front panel I/O. There is no reason at all to warrant the involvement of SqueezeOS in the alarm functionality. Having said all of this, be aware that even if the alarm subsystem were to be redesigned that wouldn't necessarily be the end of the grief. There are problems in SqueezeOS and in the Squeeze network client<-->server infrastructure that would still likely cause problems. The local Radio player subsystem is heavily used by the alarm logic (and would continue to be in any design), yet there are still synchronization problems when locally requested playout crashes into Server requested playout. The necessary synchronization constructs for distributed client/server communication to occur in a reliable and consistent manner shouldn't be presumed to exist under the covers of SqueezeOS. When you hear volume jumps (up or down) or alternating fallback alarm audio and server stream audio those are just two examples of the client/server synchronization constructs failing (or not existing). The server should not be allowed to push a stream while the Radio is already pulling one, yet it indeed does so today. It's not clear to me that the Radio ever actually pulls a stream from the server, actually. It may be that the server is *always* pushing the stream. Yet, in the alarm case it only makes sense for the alarm to be pulled. The first step would be to find another use case in the Radio code where a stream is pulled via the Radio... Then SqueezeOS would need to be locked out until the alarm was cleared locally to prevent the server from attempting to usurp the playout subsystem for some other reason. Thus, other Radio UI input needs to be discarded while an alarm is ongoing. Again, the strange modularity paradigm used by the Radio software may prove problematic. Access to favorites, and any other state needed to specify a particular stream requested as alarm audio may be another issue. I haven't looked at how this information is accessed by local Radio software, since the server is always responsible at present for pushing the requested stream... Due to these issues, I'm loathe to get involved again on my own time (despite the time it takes to post these dissertations)... -- Marc ------------------------------------------------------------------------ Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=77883 _______________________________________________ Radio mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/radio
