I think Erland's and Stefan's comments are both probably important (Peter's as well, in pointing out to distinct issues in terms of the fallback alarm versus some earlier stream playing for a bit).
I'd suggest doing a small bit of testing with the following in mind: You're playing stream 1 at some point in time and then think you've stopped it. It could be that when you think you've 'stopped' it that you really haven't, since hitting the pause button actually 'pauses' the stream. If the stream is then sitting there paused for hours prior to the alarm going off then there will be no surprise if you hear it again briefly when the 'server' alarm goes off (and maybe even if a fallback alarm fires, since it could be that encoded audio from the earlier stream has already made it to the Radio cache before you paused it OR that decoded audio - PCM samples - are themselves still waiting in the Radio cache from earlier). The reason you may hear the earlier stream briefly is due to how the notification system works. If a playerModeChange notification is delivered to some listening applet (or perhaps even just SqueezeOS directly determines the transition has occurred) which then decides that means to turn the local audio playout back on then voila... you are left with the previously played stream audio which was previously in paused state. playerModeChange notifications (along with several other similar type notifications) DO occur during the alarm process... So, see if a previously stopped (not paused) stream, as Stefan mentioned, manifests the issue when a later alarm is fired then retest with the played stream being paused (not stopped) prior to the later alarm firing... I would not be at all surprised if you hear just the alarm audio after the prior stream was stopped, but the brief earlier stream first if it was paused... Of course, if the earlier stream continues to be briefly heard prior to the requested alarm audio even after the earlier stream was explicitly stopped (not paused) then the problem is likely that either the cache/prefetch audio buffer at the server or the Radio is not being properly flushed after a stop operation. Either way, any existing audio (whether earlier paused or stopped) should, in my view, be flushed out of the playout pipeline when an alarm fires... Not so easy to do in the current context of how alarms work though... Marc -- Marc ------------------------------------------------------------------------ Marc's Profile: http://forums.slimdevices.com/member.php?userid=34776 View this thread: http://forums.slimdevices.com/showthread.php?t=73708 _______________________________________________ Radio mailing list Radio@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/radio
