light-locker mutes audio on lock, does not un-mute

Bug #1325228 reported by Simon Lock
30
This bug affects 6 people
Affects Status Importance Assigned to Milestone
light-locker (Ubuntu)
Expired
Undecided
Unassigned

Bug Description

Description: Ubuntu 14.04 LTS
Release: 14.04

Xubuntu 14.04 LTS x64
light-locker 1.4.0

Using light locker mutes audio on lock (either on screen saver or via light-locker-command -l) but does not un-mute audio at lightdm login / resume.

My user account belongs to 'audio' group.

I would expect either audio to un-mute on unlock or an option not to mute audio for the locked session.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in light-locker (Ubuntu):
status: New → Confirmed
Revision history for this message
Morten Guldager (spamtrap-f) wrote :

I can confirm this on a x86 xubuntu 14.04 patched up to date. After unlock I find 3 channels muted in my mixer: Master, Headphone and Front.

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

It's annoying that this doesn't work anymore, but it's actually not due to something that light-locker is doing. It's due to the VT switch that happens when locking. So there's nothing we can do about it in light-locker.

Maybe something in ConsoleKit or pulseaudio changed so that this doesn't work anymore. You can try to debug it a bit with the information on this page to find out what really causes the problem: https://wiki.ubuntu.com/Audio/TheAudioGroup

Changed in light-locker (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Martin Spacek (mspacek) wrote :

@ochosi:

"it's actually not due to something that light-locker is doing. It's due to the VT switch that happens when locking. "

Um, isn't it light-locker that's executing the VT switch? Doesn't that make light-locker responsible for all the downsides that come with VT switching, including audio interruption? (see #1336647, ie https://bugs.launchpad.net/bugs/1336647).

FWIW, audio does seem to resume playback after unlock for me in Xubuntu 14.04 on my Thinkpad W510 with light-locker installed. But the interruption on locking is completely unacceptable.

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

@mspacek: You're free to use another locker, however, this bugreport is assigned to the wrong package.

Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for light-locker (Ubuntu) because there has been no activity for 60 days.]

Changed in light-locker (Ubuntu):
status: Incomplete → Expired
Revision history for this message
Kevin Otte (nivex) wrote :

My machine was behaving correctly, but I had the sound muted at the local LUG meeting last week when it locked and now it always mutes on lock.

Kevin Otte (nivex)
Changed in light-locker (Ubuntu):
status: Expired → Confirmed
Revision history for this message
Pasi Lallinaho (knome) wrote :

Setting to Invalid per comment #3.

Changed in light-locker (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Fred Cooke (fred-cooke) wrote :

@ochosi you could at least confirm or correct @mspacek's VT switch root cause comment. Dismissing it out of hand and setting to invalid is not at all helpful. To me it seems as if he's right, and you're not, however I'm skeptical of my own findings as you're the dev and are likely to know best. If the VT switch is not initiated by and controlled by light-locker, why is it that when I use gnome-screensaver with lightdm it does not seem to switch VTs? At least, I don't get the same symptoms. My symptom is JS clients in my browser becoming disconnected. It seems comparable to the audio dies and network manager dies problem. If gnome-screensaver is indeed switching, how is it switching without causing these dramas and why can't light-locker do it this way instead? Cheers.

Changed in light-locker (Ubuntu):
status: Invalid → Confirmed
Revision history for this message
Ian Phillips (ianfp) wrote :

@ochosi

"You're free to use another locker, however, this bugreport is assigned to the wrong package."

Since light-locker seems to be the default screen locker for Xubuntu (I might be mistaken here), I'd say this is a usability bug for Xubuntu. If the solution is indeed to "use another locker", then Xubuntu should probably not use light-locker as the default.

Is there an appropriate place to log a bug against Xubuntu that says "Don't use light-locker as the default"?

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

@ianfp: Feel free to read through the rationale for our decision here: http://xubuntu.org/news/screen-locking-in-xubuntu-14-04/

If you want this sort of change in Xubuntu, the best way is to join the team and contribute.

Revision history for this message
Ian Phillips (ianfp) wrote :

@ochosi: Thanks for the link -- it's useful context. I didn't realize that the switch to light-locker was that recent. Given that it was recent and very intentional, my saying "don't use light-locker as the default" doesn't seem like a very constructive route to take.

Revision history for this message
Simon Steinbeiß (ochosi) wrote :

@ianfp: No worries. But yeah, if you want to make a difference in Xubuntu join us and contribute! :)

Revision history for this message
Theo Linkspfeifer (lastonestanding) wrote :

Is anyone still affected by the initial problem?

Like said before, switching VTs can result in unexpected behavior. This particular issue may have been fixed by an update of one of the core components (kernel, xorg, pulseaudio).

Changed in light-locker (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for light-locker (Ubuntu) because there has been no activity for 60 days.]

Changed in light-locker (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.