Bugzilla – Bug 10060
The alarm doesn't fade in if the source is Internet radio
Last modified: 2009-06-17 09:35:43 UTC
Alarms that use Internet radio as a source start at full volume and don't fade in gradually. MP3 playlists from my music library do fade in OK. I've tried with a number of different radio streams, including BBC iPlayer, AlienBBC and WMA stations. All appear to exhibit the same problem. I'm running the current latest nightly 7.3 (23938), although I've noticed that this has been a problem has been around in 7.3 for a couple of weeks at least. This was definitely not a problem with 7.2. Mac Mini Core Duo Mac OS X 10.5.5 SlimDevices Squeezebox v3 running firmware 119 Wired ethernet
Confirmed, SC will start OPML streams at what ever the max alarm volume is. SN does not have this same issue. Attached alarm.log
Created attachment 4296 [details] Alarm Log Notice that the volume was set to 10, and the alarm set it to 75. I didn't see the 'fade' code anywhere in the alarm, even though it unchecked - checked it before setting the alarm.
I don't know OPML from Opie Taylor, but my Boom's alarm fade-in has been inoperable for Internet Radio since Firmware level 40 (I think). I don't use SC at all so can't include a log file. ("Sound Effects"|"Natural Sounds"|"Musical Sounds") do fade in but Pandora and Slacker don't.
Isn't alarm fading in broken for all kind of playback, even local music?
I have just confirmed that the volume does not fade in when using an internet radio stream as an alarm sound. It does fade in when using a local track from my music collection saved as a favourite, and also when using the current playlist. In short, it does look as if there is a specific problem with remote streams. The alarm code doesn't distinguish between remote streams and favourites, or indeed anything with an url. I therefore suspect that something somewhere else is manually tweaking the volume when a remote stream is played, and therefore cancelling the fade.
I do know that the Internet Radio alarm fade-in *did* work with Boom firmware 33. I think it broke at 40, but am not sure about that. JADP.
I've put some logging into the fade_volume routines in my local copy and can confirm that the fade is initiated with internet radio. However, it is then cancelled by an external volume change. In the scenario I tried, the fade_volume started at 07:30:00 (alarm time) and was cancelled eight seconds later. I don't know for certain, but I would suggest that the internet radio stream took eight seconds to connect and buffer and that the fade was cancelled as soon as it started to produce audio, causing the first sound produced to be at full volume, following eight seconds of 'fading silence'. What we really need is a callback from the play/pause request that is triggered at the moment that audio is produced. We could then trigger the fade from this point. However, we'd still need to track down the other external volume change that seems to take place for internet radio.
Alan, can you shed any light on this?
I think that it is probably because Song::getNextTrack will be asynchronous for remote tracks and so StreamingController::_Stream, which sets the volume, will only be called after the alarm fade has started, thereby cancelling it. Maybe we need a fade-in argument to [ 'playlist', 'play' ... ].
Alan, I think adding a fade in arg would be a really good idea. This would hopefully solve the current problem and also would allow fades to start at the same time as playback rather than potentially operating on silence. Is this something you'd be able to work on? It may make sense to reconsider Slim::Player::fade_volume at the same time - it's a bit of an odd beast at present!
Ping Alan for response to comment 10 Moving bug to future for now, please target when a solution is created.
All down to priorities. Since I want this feature back too I guess I'll find time ...
Same for me on my SqueezeBox Boom using SqueezeCenter v.7.3.2 on an Desktop PC. If Alarmsound is set to Internetradion the SqueezeBox Boom starts up at alarm time with max sound instead of fading in gradually. This isn't a issue if using music from server. This bug is in from release 7.3 upwards at least and wasn't an issue before.
Currently we try to do a 20s fade-in. Would a 10s fade-in be sufficient? In which case we could use the player capability, rather than driving this from SC.
For me a 10-sec fade-in would be OK.
I don't know. 10 seconds seems quite short for something that you're waking up to. It's been 20 for a very long time so I can imagine complaints if it was changed. I think this decision should not be taken too lightly. If I remember rightly, people have previously complained that 20 is too short.
I agree with Max. The nice thing about this feature when it worked was the gentle way it waked you up with a long fade in.
Yeah, I agree too.
Change 24820. QA. Please test this every which way, including all the different types of Alarm playlist (local, current, favourite, random, internet-radio favourite). Also make sure you test some slow-to-start internet radio stations. Test both the initial alarm and the reawake after snooze.
Additional change 24825 - remove an invalid debug message and shift method into Package Methods section. No difference in functionality from Alan's previous change.
Working great in the 30th Jan nightly (7.3.3 24825)... really glad this is working again! :-) Now I'm even less likely to get up on time!!
I can't claim to have tested extensively, but after a quick test this evening, it seems to be working fine. Thanks so much for everyone's efforts on this. It makes SUCH a difference in the morning! :)
Strange result this morning (24825 build)... Alarm came on with an internet radio stream and gradually increased to my volume setting of 15 - no issues. I then hit Pause in order to make a phone call (as this is the closest thing to 'mute'). About 10 minutes later it came on much louder at 39, and I briefly caught some sort of 'timeout' error on the screen but couldn't catch the full message. This could just be some sort of anomaly with the internet radio station, but have no idea what would have caused the volume to jump to 39.
Is 39 the volume it was on when turned off the night before? Probably the paused internet radio station timed out the connection, this was caught by SC which restarted the stream, cancelling the alarm in the process, which then also restored the before-alarm volume.
Quite possibly - no way to be sure. Is it normal for SC to cancel an alarm like that? Have certainly never seen it happen before.
The alarm would have cancelled the moment Tom hit pause. It would also have restored the pre-alarm volume at that point. Any action the user takes to stop music during an alarm will also cancel the alarm.
Works well with my FM radio station that I selected... Thanks again for restoring that!!!
When will this fix be applied/ported to SqueezeNetwork? My Internet radio alarm still doesn't fade in, but I don't use SC. Thanks, -Don
Verified in 7.3.3 - 26303.
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.