Bugzilla – Bug 16100
Sound comes from headphones although Radio is set to use speaker
Last modified: 2013-08-13 19:49:04 UTC
Current server version: 7.5.0 - r30464 Current Radio firmware: 7.5.0 - r8673 After resolution of Bug#14742 I noticed that occasionally the sound would continue to come from the headphones when an alarm was triggered. James Richardson has requested that a new bug should be opened. Under some conditions the Radio enters a state where all alarms triggered come from the headphones rather than the speakers. I see this fairly often but I am unable to reproduce the steps to reliably enter this state. However, when I do not unplug the headphones my Radio seems to enter the 'bad' state within a couple of days. Once in this state I have noted that I get no interesting information either in the SBS player.alarmclock debug log or in the SqueezePlay log via SSH in /var/log. Then the Stefan Hansel directed me to do some more debugging via SSH. He asked me to execute the following command: amixer sset Endpoint Speaker ...which gave the following output: "Simple mixer control 'Endpoint',0 Capabilities: enum Items: 'Off' 'Speaker' 'Headphone' 'Speaker+Headphone' Item0: 'Speaker'" ...showing that the Radio thinks the sound is coming from the speaker. Although it is not. Furthermore, the following command: amixer sset Endpoint Speaker ...failed to remedy the situation and force output to the speaker. This situation is worse than before the resolution of Bug#14742 so really does need some attention. I am happy to allow the 'bad' state to occur and I am happy to perform whatever debugging is necessary using SSH or any other method.
*** This bug has been confirmed by popular vote. ***
Alarm went to my headphones this morning. I have 7.5.2 firmware connected to mysqueezebox.
This bug still happens occasionally to me, its very annoying.
Here is another user on the official Logitech forums with this issue: http://forums.logitech.com/t5/Squeezebox-Players/Squeeze-Box-Radio-Alarm-Sound-Sometimes-Outputting-to-External/m-p/577150
This is a dreadful bug. Nothing worse than having an unreliable alarm clock
There are changes in 7.6.0 that address this issue (specifically r9296 on the 7.6 branch) I've just been testing it on 7.6.0 firmware r9405 and I'm not able to reproduce the bug any more. Setting to RESOLVED, but if anyone is using 7.6.0 and comes across the problem, please reopen and give specific steps to reproduce (e.g., music through headphones is still playing when alarm hits, or whatever the specific scenario is)
I hadn't seen this for a very long time but it happened this morning. with 7.5.3. There were events that led up to it. The night before I had removed, inserted the headset several times while playing. I will exercise this with 7.6 to try to reproduce
Ryan, please move to 7.6 and try to reproduce there.
(In reply to comment #6) > There are changes in 7.6.0 that address this issue (specifically r9296 on the > 7.6 branch) > > I've just been testing it on 7.6.0 firmware r9405 and I'm not able to reproduce > the bug any more. > > Setting to RESOLVED, but if anyone is using 7.6.0 and comes across the problem, > please reopen and give specific steps to reproduce (e.g., music through > headphones is still playing when alarm hits, or whatever the specific scenario > is) Were you really ever able to reproduce this? If so, following what steps? If not I think it is unhelpful to mark this as resolved just because you haven't seen the issue. I am still seeing this issue frequently on 7.6.0 r32302, as always I am happy to give you any debugging information on top of what I have already provided via SSH etc.
When reproducing this issue, set Settings->Advanced->Logging->applet.AlarmSnooze to DEBUG Ryan, please try to reproduce this using 7.6 firmware on the radio. elziko, if you have reliable method to reproduce this issue, it would be helpful if you gave the exact steps to do so. I have tried what's been described so far in this bug, and have not once experienced the bug yet. I'm not saying the bug doesn't exist, but it's either dreadfully hard to reproduce, not present in 7.6 firmware, or I'm missing something in the steps to reproduce. Also, you mentioned an SBS version in you previous comment, but what version of firmware are you running on the radio? (Settings->Advanced->About). FYI, this bug is entirely client side, the server has nothing to do with whether audio comes out speaker or headphone. All debugging efforts can be focused on the client side.
The firmware version I saw this issue was 7.6.0 r9405. Even though I am affected by this bug frequently, I am unable to find the exact steps that seem to cause the problem, it almost always happens when I leave the headphones plugged in. All I can say is that I frequently listen to internet radio with the headphones before going to sleep. I have now set applet.AlarmSnooze to DEBUG and when I next have time I'll leave my headphones plugged in and see if I can get some more information.
(In reply to comment #8) > Ryan, please move to 7.6 and try to reproduce there. Server: Version: 7.6.0 - r32413 Player Model: Squeezebox Radio Firmware: 7.6.0-r9441 My experience is that the problem is there on 7.6 although it partially worked for me in that the first few seconds came through the speaker then it switched to headphones. I left my headphones in after listening to internet radio in bed. Set alarm 0530, Planet Rock. Result= a few seconds of planet rock fading in followed by a switch from speakers to headphone! Is there a fix for this or do I have to ensure I never fall asleep with headphones in? Can anyone explain why this reasonably complex behaviour resulted. Would turning fade in off help?
Created attachment 7280 [details] Messages log from Radio > My experience is that the problem is there on 7.6 although it partially worked > for me in that the first few seconds came through the speaker then it switched > to headphones. Yes I can confirm this behavior; I have now done three tests and each time the alarm would come through the speakers for around 10 seconds and then revert to the headphones. This is better but still obviously wrong. Bizarrely on one of my tests the sound STARTED off coming though the headphones for 1 second and then came out of the speakers. Then after 10 seconds it came back to the headphones. I have attached the messages log downloaded from my Radio with applet.AlarmSnooze to DEBUG. In this case my alarm was set to go off at 07:00. Ben, let me know if you need anything else, I'm happy to do the necessary. > Can anyone explain why this reasonably complex behaviour resulted. So far, it seems not! :)
> Bizarrely on one of my tests the sound STARTED off coming though the headphones > for 1 second and then came out of the speakers. Then after 10 seconds it came > back to the headphones. I dud some testing this evening and tried turning off the Fade In setting to see if it was the end of the fade in causing the transition to headphones. This didn't prove to be the case but with this setting I observed 1 second from headphones before 10 seconds or so from speaker before reverting back to the headphones. Hmmmph!
Hah! Finally (finally!) reproduced it and got a good code trace: May 17 16:49:33 squeezeplay: DEBUG applet.SqueezeboxBaby - SqueezeboxBabyApplet.lua:904 sleep: ACTIVE May 17 16:49:33 squeezeplay: DEBUG applet.SqueezeboxBaby - SqueezeboxBabyApplet.lua:989 powerState: ACTIVE->IDLE May 17 16:49:33 squeezeplay: ERROR applet.SqueezeboxBaby - SqueezeboxBabyApplet.lua:609 _setEndpoint() May 17 16:49:33 squeezeplay: stack traceback: May 17 16:49:33 squeezeplay: ...jive/applets/SqueezeboxBaby/SqueezeboxBabyApplet.lua:609: in function '_setEndpoint' May 17 16:49:33 squeezeplay: ...jive/applets/SqueezeboxBaby/SqueezeboxBabyApplet.lua:993: in function <...jive/applets/SqueezeboxBaby/SqueezeboxBabyApplet.lua:965> May 17 16:49:33 squeezeplay: (tail call): ? May 17 16:49:33 squeezeplay: ...jive/applets/SqueezeboxBaby/SqueezeboxBabyApplet.lua:189: in function <...jive/applets/SqueezeboxBaby/SqueezeboxBabyApplet.lua:189> May 17 16:49:33 squeezeplay: [C 0x65779]: in function 'pcall' May 17 16:49:33 squeezeplay: /usr/share/jive/jive/ui/Timer.lua:191: The offending code is from SqueezeboxBabyApplet not AlarmSnoozeApplet. What I see happening is that shortly after the alarm kicks in, the internally stored variable self.powerState shifts from ACTIVE->IDLE. IDLE means that the user hasn't touched any buttons for a while, and when that happens an applet method is called that (in this case) erroneously calls _setEndpoint(), which will switch the audio from speakers to headphones, even if an alarm is playing. I have a fix for this already, but will spend some time tomorrow running some tests on it to make sure it's solid.
for those interested, this is the patch I'm going to be testing. So far it looks like it fixes the bug. === SqueezeboxBabyApplet.lua ================================================================== --- SqueezeboxBabyApplet.lua (revision 50261) +++ SqueezeboxBabyApplet.lua (local) @@ -989,7 +989,18 @@ self.powerState = state - _setEndpoint(self) + -- Bug 16100, only setEndpoint if alarm is not active + if self.player then + if (self.player:getAlarmState() == 'active' or self.player:getAlarmState() == 'snooze') then + -- leave audio coming out speaker + log:info('Alarm either in progress or snooze, do not call _setEndpoint()') + else + _setEndpoint(self) + end + else + -- if self.player doesn't exist, there is no harm in setting the endpoint correctly here + _setEndpoint(self) + end _setBrightness(self, self.lcdBrightness) if (poweroff) then
== Auto-comment from SVN commit #9443 to the jive repo by bklaas == == http://svn.slimdevices.com/jive?view=revision&revision=9443 == Fixed Bug: 16100 Description: do not call _setEndpoint() in SqueezeboxBabyApplet when powerState changes (e.g. ACTIVE->IDLE) while player's alarm is in active or snooze state this fixes the problem of the audio getting pumped into the headphones erroneously at the time of an alarm
There's no way this bug has actually been verified by PQA because the firmware isn't available yet. Community members that have seen this bug, you should independently verify the fix with the next firmware I push, which will be r9443. I'll try to get that qualified and published later today.
Re-opened to verify fix.
(In reply to comment #19) > Re-opened to verify fix. I have VERIFIED this fix. (Doesn't mean CLOSED though!) Tested with headphones plugged in but not listened to (just in case). Works correctly. Tested after listening on headphones, then setting alarm, also works correctly.
(In reply to comment #20) > (In reply to comment #19) > > Re-opened to verify fix. > > I have VERIFIED this fix. (Doesn't mean CLOSED though!) Tested with > headphones plugged in but not listened to (just in case). Works correctly. > Tested after listening on headphones, then setting alarm, also works correctly. Forgot to say. A BIG THANK YOU
(In reply to comment #15) > Hah! Finally (finally!) reproduced it and got a good code trace > I have a fix for this already Well done. Really! I'm so pleased this bug has finally been attended too - it obviously was a difficult one to nail down. I have just done a quick test and it seems to work fine. I will be testing it everyday from now on, so I'll post back if I see any problems!
Changing status to resolved-Fixed. Will keep open and monitor, but will lower priority.
Very glad to hear that those experiencing the frustrating issue are seeing resolution. Cheers!
Please re-open this bug. After recent updates in the server software and the SB radio firmware, this bug has come back, although this time it seems to be reproducible and consistent. I go to sleep listening to a radio stream on headphones with the SB radio set to turn off using the sleep function. The SB radio then sleeps. My server then sleeps because of powersave settings (and because it is behind a repeater bridge, cannot be awakened by the SB radio because its MAC address is not visible - [would be nice if that were fixed and the true MAC address could be manually entered]). The SB radio alarm goes off the next morning using the backup sound (because the server is still asleep), but the alarm sounds only through the headphones and not on the main speaker. SB Radio 7.6.0 r9458 SB Server 7.6.0. - r32854
(In reply to comment #25) > Please re-open this bug. > > After recent updates in the server software and the SB radio firmware, this bug > has come back, although this time it seems to be reproducible and consistent. > > I go to sleep listening to a radio stream on headphones with the SB radio set > to turn off using the sleep function. The SB radio then sleeps. My server > then sleeps because of powersave settings (and because it is behind a repeater > bridge, cannot be awakened by the SB radio because its MAC address is not > visible - [would be nice if that were fixed and the true MAC address could be > manually entered]). > > The SB radio alarm goes off the next morning using the backup sound (because > the server is still asleep), but the alarm sounds only through the headphones > and not on the main speaker. > > SB Radio 7.6.0 r9458 > > SB Server 7.6.0. - r32854 I'm afraid I agree the bug has returned!
Reopening
*** Bug 14742 has been marked as a duplicate of this bug. ***
Man, I'm really surprised this is back. I'm no longer at Logitech and will not be working on this bug, but my recommendation is to begin by looking at what I did in comment #16, and focus on what's going on in SqueezeboxBabyApplet.lua and _setEndpoint() good luck Felix or Michael or whomever gets this hot potato :-/
I did some tests with mysb.com and SbS - here are my findings: - connected to mysb.com when alarm is firing - ok, sound from speakers - connected to SbS when alarm is firing - ok, sound from speakers - not connected to server at alarm time - not ok, sound still from headphones So it looks like the issue only occurs with the fallback alarm sound.
7.6.1-r9482 Twice this week Alarm through headphones. First time I didn't notice the alarm sound, This morning it played the intended stream not the fallback alarm.
Some technical note regarding alarmState, a player variable: - When a regular alarm fires alarmState changes from 'set' to 'active' - When a fallback alarm fires alarmState value stays at 'set' this means the code Ben added in comment #16 does not cover the fallback alarm case.
== Auto-comment from SVN commit #9537 to the jive repo by fmueller == == http://svn.slimdevices.com/jive?view=revision&revision=9537 == Bug: 16100 Description: Fallback alarm - fix to make it sound from the speaker even though headphones are plugged in
== Auto-comment from SVN commit #9538 to the jive repo by fmueller == == http://svn.slimdevices.com/jive?view=revision&revision=9538 == Bug: 16100 Description: Fallback alarm - fix to make it sound from the speaker even though headphones are plugged in
This week three days in a row I had the alarm through my headset. Two of them were definitely not the fallback alarm. Last night I power cycled my radio and this morning the alarm fired through the speaker as intended.
I have recently observed another behavior related to this bug. This still may not be 100% reproducible. Several weeks ago I had a number of days in a row where my alarm played through the headphone instead of the speaker. At some point I accessed MSB.com and logged out. The alarm had been reliable since. Again this week after I had logged into MSB.com and made some changes and closed my browser without first logging off my alarm began to play through the headphone. I have since logged out of MSB.com and my alarm has been normal (through the speaker).
I was working in this area as part of my SBR trigger project <http://forums.slimdevices.com/showthread.php?97759-Amplifier-trigger-from-Squeezebox-Radio&p=754227&viewfull=1#post754227> One thing that I noticed might be helpful. Although the underlying control models the audio output [aka endpoint] as a tristate (Headphone, Speaker and Off), it might make the implementation simpler and more robust when working with the power control (function setPowerState) to separate the model into two parts: a. Audio output selection : Headphone, Speaker b. Audio output power : On, Off Doing this means that setPowerState can concern itself simply with changing the audio output power (On vs Off) -- and not confuse or lose the active selection. Things like the alarm and headphone insertion (function _setEndPoint) can concern themselves with configuring the audio output selection (Headphone vs Speaker) -- and not confuse or lose the current power state. Then the mixer (bsp:setMixer) is configured by inspecting the four possible input states (Headphone,Off or Headphone,On or Speaker,Off or Speaker,On).