Bugzilla – Bug 14742
When headphones plugged in, alarm should come through main speaker
Last modified: 2011-08-12 08:46:05 UTC
Mule finds that he alarm comes through headphones. http://forums.slimdevices.com/showthread.php?t=67916
QA confirmed...is this yours to handle Richard?
Richard, perhaps Tom or Felix maybe?
*** Bug 14916 has been marked as a duplicate of this bug. ***
I just got my radio yesterday and came up against this on my first alarm call this morning. I have to say I am amazed that this wasn't specifically tested for! I hope it gets fixed very soon.
I don't understand why importance is set to "normal" which is declared as "regular issue, some loss of functionality under specific circumstances" instead of "Major". There are NO specific circumstances. This bug ALLWAYS appears when headphones plugged in. And plugging headphones into a device with a headphone jack is certainly nothing unusual, isn't it?
Still, with 7.5 beta the Radio alarm will not sound through the speakers when the headphones are plugged in. However, the Boom works as expected in this respect.
It's gone quite here and the priority is still set as "normal". Ben Klaas is currently atempting to make the alarm reliable. He can't succeed if this fault is not addressed.
Vahid to have a look
This bug exists on SB Radio and does not apply to Fab4.
After missing another alarm due to headphones being plugged in I would really like to at least see a firm target for this bug. I'm surprised that alarm issues aren't given higher priority - we have been suffering from this bug for over a quarter of a year!
I approve of your comment "we have been suffering from this bug for over a quarter of a year!"
This bug is really annoying and it takes too long to get it fixed.
Created attachment 6486 [details] Patch to route alarm always trough speaker This patch routes all alarm audio to the speaker. When the alarm window is canceled old state is reverted (audio will go through headphones again if plugged). If the user (un)plugs headphones while the alarm is playing then his action overrides the speaker-routing of course.
(In reply to comment #13) > Patch to route alarm always trough speaker Thanks for spending the time to do this! Now if it could be applied to the official release in time for v7.2 instead of v7.5, that would be great! :)
Many thanks for the patch Stefan. I've reviewed it but think Felix should also give it a look, so reassigning the bug to him. FYI, there is absolutely zero chance I recommend this goes into 7.4.2. This will be a 7.5 change, esp. because the io.popen and os.execute calls in the patch are much riskier than we typically do in Lua applets. We're very near release of 7.4.2 and sneaking in a fix like this would be a terrible choice. Sorry. Felix, I'd like your feedback on whether you think this is a good approach. Bug can probably be reassigned to me after that.
(In reply to comment #15) > FYI, there is absolutely zero chance I recommend this goes into 7.4.2. This > will be a 7.5 change I thought that would be the case and I understand the rationale. Thanks anyway.
Patch looks ok to me. I don't think there is another way to switch between headphone and speaker than using os.execute(). Using shell commands should not be an issue on Radio as memory usage isn't that tight (yet).
== Auto-comment from SVN commit #8479 to the repo by bklaas == == https://svn.slimdevices.com/?view=revision&revision=8479 == Fixed Bug: 14742 Description: Patch from Stefan (vielen Dank) to pipe alarm output always out speaker and not headphones
I've tested this and felt it ready for checkin to 7.5. If you see an issue with 7.5 firmware >=r8479, please reopen this or start a new bug This change won't be seen until the next firmware push for 7.5 to Radio
Shouldn't the fix also be in 7.4.3 if looking at the version number of the new baby fw of 7.4.3 or am i wrong? Just tried it and once again the alarm sound came through headphones instead of the speakers?!
No the revision number just shows the order developers fix certain bugs, they don't tell if it will be in the 7.4.x-branch or 7.5.x-branch of the firmware. The version control used numbers the following way: --- r1 --- r2 ----------- r5 ------ r7 ---------- r8553 (7.4.x-branch) \ \ \--------- r3 ---- r4 ---- r6 -------- r8479 (7.5.x-branch) So if somthing has been fixed in r8479 (on the 7.5.x-branch) it doesn't mean it is fixed in r8553 (which is on the 7.4.x) branch, just because it is a higher number. You'd have to switch to 7.5. Beta to see this bug fixed.
Nicely described Stefan :) The fix for this bug is in 7.5.0 firmware only.
(In reply to comment #22) > Nicely described Stefan :) > > The fix for this bug is in 7.5.0 firmware only. Hello This update has not been pushed yet even for 7.5.0 branch ? - My server is 7.5.0 / r30234 - My radio is 7.5.0 / r8445 (no automatic firmware update during the last weeks)
(In reply to comment #23) > This update has not been pushed yet even for 7.5.0 branch ? No, see this thread so that you know when the change makes it into a nightly: http://forums.slimdevices.com/showthread.php?t=75176
Problem has been fixed yesterday: firmware 7.5.0 r8594 has been pushed for SB Radio. I tested it: it's OK
Only downside: Fade in doesn't work! Maybe the switch to the speakers comes to late?! TheMule!
Although I am pleased that the alarm now comes from the speaker rather than the headhones, I can also confirm that this fix breaks alarm fade-in.
Created attachment 6723 [details] Logs to show the alarm during failure and when working correctly. I think there is a bug in this fix. Occasionally I still have the alarm coming though the headphones. Server: v7.5.0 - r30409 Radio: v7.5.0-r8661 I am always connected via SBS and have no connectivity problems. I have set the log to output debug info and attached working and non-working logs although I can see no significant difference between the two. I don't know how the radio gets into the the non working state but it has happened three times so far. When it does happen neither restarting the Radio nor the Server will fix the problem. The only way to fix it is by unplugging the headphones before plugging them straight back in - the next alarm then comes out of the speakers as expected.
Reopening, but it should be noted that the previous fix was tested as working. There appears to be situations where it is buggy, and that is now the scope of the bug. First goal will be to find the reproducible case where it fails.
Yesterday I updated to the final v7.5 release of SBS and this has happened again this morning. In logging, I have player.alarmclock set to Debug and nothing interesting is showing up in the log. Are there any other logs I should be looking at when this happens?
Just an update - I have extracted the log on the Radio itself from /var/log - no log entries at the time of the alarm at all. Until I unplug my headphones I can consistently observe this failure and I am happy to extract logs and replace files via SSH if needs be. Whatever is necessary. Make use of me whilst my Radio is in this state! :) I will hold off unplugging my headphones for a while.
elizko, could you try the following: - start some tune (should be coming through headphone) - connect with SSH - type 'amixer cget name="Headphone Switch"' - what is the output on the console ? - type 'amixer -q sset Endpoint Speaker' - what is the output on the console ? Is the sound coming through speaker now ? - type 'amixer -q sset Endpoint Headphone' - Is the sound coming back from speakers. As background information: these command are issued from the applet to switch the output channels and I'm interested in if they work 'standalone'.
(In reply to comment #32) > - type 'amixer cget name="Headphone Switch"' > - what is the output on the console ? amixer: Cannot find the given element from control default > - type 'amixer -q sset Endpoint Speaker' > - what is the output on the console ? There is no console output. > - Is the sound coming through speaker now ? No, it is still coming from the headphones. > - type 'amixer -q sset Endpoint Headphone' > - Is the sound coming back from speakers. There is no console output and the sound remains in the headphones. > As background information: these command are issued from the applet to switch > the output channels and I'm interested in if they work 'standalone'. Well, I'm not sure if the missing element is relevant but this certainly shows a failure to switch to the speaker. I'll leave my Radio in this state in case there is further debugging required. Thanks!
what is the output of amixer sset Endpoint Speaker (no -q this time, as this omits the output 8-) )
(In reply to comment #34) > what is the output of > > amixer sset Endpoint Speaker > > (no -q this time, as this omits the output 8-) ) In the current state the output is: "Simple mixer control 'Endpoint',0 Capabilities: enum Items: 'Off' 'Speaker' 'Headphone' 'Speaker+Headphone' Item0: 'Speaker'" Did you want me to execute a particular "sset Endpoint" first?
No - but the strange thing is, that this command shows, that your Radio thinks the sound is coming from the speaker. "Item0: 'Speaker'" I have no idea why it would still come from from the headphones. Guess some firmware/linux guys need to answer this.
(In reply to comment #36) > No - but the strange thing is, that this command shows, that your Radio thinks > the sound is coming from the speaker. Yes, strange. I did double check it is still coming out of the headphones after that command. It is. > Guess some firmware/linux guys need to answer this. Are the guys that need to look into this aware of this bug? Should they be notified/added to the CC list? I'll leave my radio in this state for a little longer in case someone needs me to do something else.
My issues with the sound coming from the headphones have been moved to Bug#16100 at the request of James Richardson. I have added some of you from this bug to the CC list where I think it was appropriate. Apologies in advance if anyone added is not involved.
The 'UI' component is being removed. This bug is being shifted to the appropriate new component.
*** Bug 16541 has been marked as a duplicate of this bug. ***
I have not reproduced this since September
OK, so perhaps the original remit of this bug has been completed but this is NOT working for everyone: If you must close this bug can we at least get someone assigned to work on Bug#16100, please. I am seeing new bugs raised in Bugzilla and forum posts about this lately. It is a genuine problem.
Verified on 7.6.0 32427 Alarms heard through speaker, even though the headphones were still attached
It's back!!! Since the 7.6.0 update I have had 2 occurrences of the alarm playing through the headphones.
*** This bug has been marked as a duplicate of bug 16100 ***