Muting sound indicator in Unity Greeter does not mute sound on login

No, I don't think that volume control has anything to do with the login sound or the next user's login settings. But that makes sense that it should.

Here's some ideas:
1. The sound menu volume control should be just for the login noise.
2. The sound menu should affect the next user's login.
3. The sound menu should not show in the unity-greeter.

I do not seem to be affected anymore with the latest updates

Update:
No it isn't!Or it is!
Well,Atleast now I am sure unity has bugs as well,You can't reproduce this bug on GNOME Shell it obeys sound control,but Unity will just ignore it.
jibcha?any comments?

Confirming that the sound indicator in the greeter only controls any sounds the greeter might make. Assigning to Mika in Canonical design to specify what the behaviour of the sound indicator should be.

I don't seem to be affected by this. The sound setting is carried over from login to desktop and vice versa – all fine. That works through login/logout, restart and switching user.

I didn't get to this this cycle. It will be first thing on my list once Precise is out the door.

Ubuntu 12.04 LTS.
I can't change volume level on Greeter screen with hardware keys (Fn+VolumeUp, VolumeDown, Mute).

Assigning ~indicator-applet-developers in place of Conor. This would probably make sense to go in accountsservice as an extra field.

I'm a little uncomfortable with this whole idea though. What are the sounds played by the greeter?

* "greeter is ready" sound
* orca speech

Anything else?

It strikes me as odd that those sounds would be muted if the last user that happened to log in had their sound muted at logout time. Why would you want that level of sound-carry-over? What's the use-case?

John Lea, you marked the Ayatana task as Fix Committed without comment. I don't mean to override you, but can I get a bit more specifics from the Design team before implementing this?

(I realize that the sounds would be unmuted once you switched the selected user, but both those sounds are most useful on startup -- login lets you know the greeter is ready, orca tells you where you are.)

Another Design question: What would the volume be for non-user greeter entries like "Other" or "Remote Login"?

Marking Won't Fix for raring, as I likely won't be able to get to this and don't have all the details from Design yet (getting this off my status radar). Otherwise, hopefully we can get to it in S.

Volume is a system-wide setting. I think pulse should store the volume somewhere outside of the user's session.

Unfortunately the "Desired solution" here seems to contradict itself.

I agree with Lars and John that volume should be system-wide: "changes made to the volume control in the Unity Greeter should carry through to the logged in session and vice versa". That's unfortunate if one of your family is hard of hearing and the rest are not: you'll often be changing the volume when switching users, same as you have to with a shared TV or radio. But the alternative would be more common and worse: you'd mute sound in the session, only for startup or login screen sounds to wake everyone or scare the cat. And while on a PC it might be just annoying, on a phone it would seem especially silly to have one volume setting for the lock screen and one volume setting for everything else.

But apply that to the example given. User B logs in, mutes the sound, and locks or logs out; the login screen now has muted sound too. User A logs in, sets the volume to 100%, and locks or logs out; the login screen now has volume 100% too. User B returns and selects themselves in the login screen. What, then, would be the point of "the sound indicator [changing] to display the muted state"? After all, when B finishes logging in, they'll have volume of 100%!

I've updated the spec to define volume and sound output as global settings. <https://wiki.ubuntu.com/Sound?action=diff&rev2=104&rev1=103>

mpt, I think there's some confusion. Lars and you want a system-wide volume. John wants a per-user volume (i.e. like we have today, just with the greeter reflecting the user's volume).

With per-user volume, in your example when B logs in, B will have a muted sound. That's the point of changing the greeter volume when B is selected.

I have implemented this in the attached branch inside indicator-sound (it uses AccountsService to synchronize user volume like we do for other settings -- keyboard layout, preferred desktop session, etc).

I just discussed this with John. He explained that the motivation for making it per-user was to avoid the problem where some settings are per-user and some are system-wide, and users can't predict which is which.

Now, consider the case where you don't log in at all. You turn on your PC, and at the login screen, the drumbeat sounds much too loud. You wince and turn down the volume. Your parents, hearing you fiddling with the computer, call you away to do something else, so you shut down without logging in. When you start up your PC the next day, what should the volume of the drumbeat sound be? The volume you set previously, of course.

This illustrates that Ubuntu needs a system-level volume setting, regardless of whether there is *also* a per-user volume setting. Even if that wasn't true for volume (for example, if we had no drumbeat at the login screen), it would be true for brightness, keyboard layout, and a host of accessibility options that apply to the login screen.

Now, in many cases a device has only one user account. That's often the case with a laptop, usually the case with a tablet, and almost always the case with a phone. When there is, it would be annoying to have to set each of those settings twice, once for the login screen and once for everywhere else. That's the reasoning behind settings propagating from the login screen to the user session and vice versa.

The point I tried to make is that I don't see any functional difference between that and just having a system-wide volume setting. When B logs in, does the sound volume get propagated from the login screen to B's session, or doesn't it? If it does propagate, then there's no point in momentarily showing B as having a volume that they won't actually have. And if it doesn't propagate, then how do you avoid the annoyance of having to set the volume twice when B's account is the only one?

You could make settings propagate if there is one user account, and not if there's more than one. But that would mean different behavior on different Ubuntu installations. It would introduce unpredictability, exactly the problem that user-specific settings were intended to solve in the first place.

I hear you, mpt. Startup sounds (drums / orca) are interesting problems, particularly if a11y is involved. You almost want an a11y setting that says "on startup, always use X volume."

I still don't understand your A/B scenario problem. Using the behavior from the bug description (and my branches), the following will happen:
- A logs out with volume at 100%, greeter shows volume at 100%
- B sits down, switches to their account, greeter switches sound to muted status
- B logs in, gets muted session

You say you talked to John about this, but don't mention if there was a consensus reached. The design plan of record is what I described above and this bug description outline. I don't have a dog in this race, I just want to fix this problem one way or the other.

Another point to mention here is SilentMode. Matthew, you describe wanting volume/mute to be system wide. I'm guessing you would like to make SilentMode that way too? (harder technically, but seems semantically related to mute)

> - B sits down, switches to their account, greeter switches sound to muted status

Ah, that's the part I missed. Does that mean if you're using a screenreader and scrolling through the list of accounts, every user account name will be read out at a different volume, regardless of the volume you set at the greeter? Or does it mean that the volume you see in the sound indicator at the greeter will not, in fact, be the volume currently in effect at the greeter? The former would be an accessibility problem, and the latter would be misleading.

> Matthew, you describe wanting volume/mute to be system wide. I'm guessing you would like to make SilentMode that way too? (harder technically, but seems semantically related to mute)

Absolutely. On some devices, Silent Mode may be toggled by a hardware switch (as it is on iPhones and iPads, for example), so that you can set it even when the device is locked and/or in your pocket or bag. But I highly doubt any device would include the ability for software to move that hardware switch itself!

> Does that mean if you're using a screenreader and scrolling through the list of accounts, every user account name will be read out at a different volume, regardless of the volume you set at the greeter?

Yes, and it is an a11y issue. I mentioned this problem in the email thread, but that thread didn't go anywhere.

But honestly with both methods, we have a11y issues with shared machines (user B will always be able to mute sound and turn off machine, meaning that blind user A will not hear it boot up). So we'd need something else to cater to that case.

> Sound volume, and the primary sound output, should be global settings. Other settings should be specific to individual user accounts.

Assuming "other settings" mean "all other sound related settings", does this mean that the primary sound *input* should be handled differently than the primary sound *output* ?

> But honestly with both methods, we have a11y issues with shared machines

Sure, but it's much less with system-wide volume: all a blind user needs to remember is roughly how long the machine takes to start up. Then if they haven't heard the drumbeat, they can adjust the volume, and that volume will actually work for the screen reader.

> does this mean that the primary sound *input* should be handled differently than the primary sound *output* ?

No, it's just that primary sound input isn't yet specified in the way primary sound output is.

This bug was fixed in the package indicator-sound - 12.10.2+14.04.20140324-0ubuntu1

---------------
indicator-sound (12.10.2+14.04.20140324-0ubuntu1) trusty; urgency=low

  [ Michael Terry ]
  * Sync volume and mute settings with AccountsService. (LP: #840777)

  [ Ted Gould ]
  * Add an apport hook for debugging
  * Synchronize process management across indicators
  * Export currently running player to Accounts Service
  * Create players on the phone greeter based on the accounts service
    data
  * Allow the phone greeter player to control the running player in the
    session.
 -- Ubuntu daily release <email address hidden> Mon, 24 Mar 2014 15:03:16 +0000

This bug was fixed in the package gsettings-ubuntu-touch-schemas - 0.0.1+14.04.20140401-0ubuntu1

---------------
gsettings-ubuntu-touch-schemas (0.0.1+14.04.20140401-0ubuntu1) trusty; urgency=low

  [ Michael Terry ]
  * Add Muted and Volume properties for sharing with the greeter. (LP:
    #840777)

  [ Ubuntu daily release ]
  * New rebuild forced
 -- Ubuntu daily release <email address hidden> Tue, 01 Apr 2014 23:16:43 +0000

Is this bug still relevant to pulseaudio?

Thank you for reporting this bug to Ubuntu.
Ubuntu 11.10 (oneiric) reached end-of-life on May 9, 2013.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test.

Closed due to no response.