Bugzilla – Bug 9093
Powering off during alarm causes music to stop, start then stop again
Last modified: 2008-12-15 12:40:08 UTC
If I hit power-off during playback that has occurred because of an alarm, the music turns off, but during switch off, it then comes back on for half a second, before turning off again, which sounds nasty. This doesn't happen if I switch off during normal playback.
Max: Can you have a look at this one too?
Are you hitting power very soon after the alarm went off i.e. during the fade in period? Turning off during a fade can cause nasty volume spikes. Other than that I've never seen this problem and I always use power off to stop an alarm. More info needed.
I can't reproduce this.
I take it back, I've just come across this whilst testing another change. It happens for me if I turn the player off almost as soon as music starts playing as a result of an alarm. I'm fairly sure this is actually to do with turning off during a fade and not specifically to do with the alarm. It would be worth seeing if this can be reproduced with fading disabled. Could you try this, Phil? This could do with some more eyes, but I doubt it will be fixed for 7.2 unless it turns out to be something trivial.
I don't use fade-in for alarms. I have tried stopping at random times, and always get the stutter before it finally stops. My settings are: A single alarm Alarm Sound="In Rainbows" (A favorite - all songs are FLAC format). Repeat Alarm=No Alarm Volume=22 Snooze Length=9 Alarm Timeout=0 Fade In=No Let the alarm play for 50 seconds, then press power off.
Could I get some help from qa in reproducing this, please? According to Philip he's only seen it on his Boom, where it happens all the time. I've never seen this bug, but I have fade alarms turned on. I also do most of my real alarm testing on my PQP1 Boom as that's the one by my bed as opposed to near my laptop. I don't know what version Boom Philip is using. From an email from Philip (before this bug was Boom): > I wanted to add to this bug (but it's public) that I've only noticed the stuttering when I stop the alarm on a Boom box (pressing power off on the Boom front panel - I will try with the remote or WebUI). > > This happens all the time on Boom - haven't noticed it on my SB3 whn I power off using standard remot
Philip: 1) What firmware version do you have on your BOOM. 2) Is your boom attached to SN or SC when this error happens. 3) If SC, what version-subversion number.
Boom Firmware: 26 SqueezeCenter Version: 7.2 - TRUNK @ UNKNOWN - Windows XP - EN - cp1252 Trunk version: 22529 Perl Version: 5.8.8 MSWin32-x86-multi-thread MySQL Version: 5.0.37-community-nt
Using a non-trunk version, I am unable to reproduce this error. Philip: Can you turn debug on for the following, then attach the a log file player.alarmclock player.display player.firmware player.playlist player.streaming I used SC 7.2-22530 with boom PQP3 r26 Tested with (MP3) natural sounds as well as a (FLAC) local file as a favorite. Used the exact settings you listed in Comment #5
Created attachment 3796 [details] Debug log, as requested
Philip: thank you for the quick response. Max: does this help at all? BTW: QA is still unable to repo this.
There's nothing in the log that looks wrong from the Alarm point of view. I'm not familiar enough with the other components to be able to know if anything's up there. I don't think there's much else I can do on this at the moment.
Felix/Caleb/Andy: Care to comment on this issue?
Can't reproduce either, although I do see a rather ugly showBriefly when powering off an alarm: Clock -> "Alarm stopped" (text too long) -> Clock
James and I worked the problem out. I was able to reproduce because I have a really sucky windows install, and my SC is running in a vmware image. Everything's really slow, and its the network latency that causes the problem. The issue is that when the power button is hit, the firmware immediately shuts the volume off (so that it works in offline mode too). Subsequently, the server starts ramping the volume down -- which means that it will go back up to nearly the original volume, then ramp down. This can be solved in 2 ways: 1) have the firmware not touch the volume controls and let the server handle it. 2) put in a delay in the firmware of, say .3 to 1 second, so that the server gets a chance to ramp the volume, but if it doesn't happen in time, shut it off. 3) Force SC not to fade the alarm out on Boom, and just set to 0 volume immediately. This will sound just dandy on Boom, since it automatically fades the volume anyway. I think I prefer #3. I'm able to reproduce this very reliably with a network emulation tool that I just coincidentally started playing with yesterday to help QA with something else all together. The tool I'm using is WANem. If anybody knows a better one, let me know, but WANem isn't too bad once you understand how it works. It's a web interface on top of tc. So, this should go to Felix if implementing #1 or #2, or Max if #3, right?
Actually, the alarm doesn't fade the volume down - I think this is just a side effect of the power command, which is initiated by the user and responded to by the alarm. Nice work, Caleb!
Assigned to Felix to ensure someone carries the ball. Not sure if he's right person, though.
I believe we are talking about a online, i.e. connected to SC or SN, scenario here. In this case, I am pretty sure, firmware is not doing anything directly to the volume when pressing power (on the remote or front panel). Caleb: What is letting you think that that happens in firmware? Maybe I am overlooking something. I can get the short music burst upon stopping an alarm also when using the power button in the web-interface. The issue goes away if I am changing 'Power On Resume' to 'Stop at power off/...' instead of 'Pause at power off'. So, yes, I agree it probably has something to do with volume ramping down on pause, but so far I cannot see what or where it goes wrong.
I think I found what goes wrong: When an alarm is stopped and 'Power On Resume' is set to 'Pause at power off' this starts fading out the music. During fading the alarm code calls setAnalogOutMode() to restore the sub/headphone mode that was set before the alarm, which sends a slimproto 'audo' event. In firmware this calls boom_set_line_out_mode() which upon storing the new setting calls runtime_config_store() and that call simply takes too long causing the audible interruption. Max: Would it be possible to call setAnalogOutMode() which is currently in Utils::Alarm.pm - stop() before the player gets the pause command or after the fading is done?
Created attachment 3822 [details] Untested patch to only set analog out mode if line out is connected Unfortunately, Slim::Utils::Alarm::stop() is triggered from a subscription to commands such as pause/stop/power, so you can't call setAnalogOutMode before those commands. stop() never actually initiates a fade_volume or a pause/stop/power. The fade_volume call is merely a side-effect of the user stopping an alarm with pause/stop/power. The attached, untested patch only calls setAnalogOutMode if line out is currently connected. This should mitigate the situation. One problem with the patch's approach is that the temporary analog out mode would never be undone if the user unplugged line out between and alarm going off and the alarm being stopped. Probably not a big issue.
I've just done a quick test and this patch seems to do what it should. I have no more time this evening, but if someone wants to commit the patch, please go ahead.
Dean notes that it's okay for this bug to should ignore the preference to pause on power off, and just abruptly stop playback on power off. If that helps find a fix. Felix notes that the best solution would be to have a callback indicated when the fade out is complete.
The alarm does not initiate any power off command itself, nor does it initiate a fade_volume - it only responds to one that the user has already caused to be executed. You'd therefore have to make the standard off routines aware of an active alarm and modify their behaviour accordingly.
Max: As a workaround could we just delay setting back the headphone jack setting a bit when an alarm is stopped so it doesn't cause the sound to be interrupted?
Don't see why not. How long would the delay need to be?
Well, I don't know. Long enough so it's not interfering with the fading out that's happening. Maybe 1 second? I don't think it's that critical as long as the line out state gets set back. I guess you need to try it out.
Change 23437 (in 7.2 trunk) introduces a 1 second pause before restoring the analog out mode to its previous setting at the end of an alarm. I've tested that this works as intended but can not test whether it fixes the problem as I've never experienced the problem. Caleb/James could you give it a go?
James could you have a look at this?
I spoke with Caleb and Ross on how to best test this, we will setup a test case and validate the patch.
OK, I was able to setup a VERY slow connection to SC 7.2.1-23448. I was unable to replicate this error any more with that build. -------------------------------------------------------------- Philip, can you please retest to see if you still experience the issue? if so, please reopen the bug and add your comments.
Verified fixed in SqueezeCenter 7.2.1-23472 Boom r33
I have tested this fix - do not notice any sound glitches any more. Thanks!
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.