Adding some people who may know more about how this is supposed to work.

I don't know anything about it, but from glancing at the code, it looks like chromeos/dbus/cras_audio_client.cc listens for an OutputMuteChanged D-Bus signal from CRAS. TrayAudio::OnOutputMuteChanged in ash/system/audio/tray_audio.cc appears to be responsible for updating the UI in response to changes. Not sure why that'd be broken in mash, though.

This might be related https://chromium-review.googlesource.com/c/chromiumos/third_party/adhd/+/627973

I will take a look.

I could not reproduce this on 9914 image on chell.
dbus-monitor --system shows there is OutputMuteChanged from CRAS when I press mute button. 

signal time=1504670258.681665 sender=:1.37 -> destination=(null destination) serial=467 path=/org/chromium/cras; interface=org.chromium.cras.Control; member=OutputMuteChanged
   boolean false
   boolean true

I played with mute button with headphone and internal speaker for a while but have not seen this issue.

Kalin, could you please test/verify this more thoroughly and see how to repro this ?

Thanks!
Thanks!

Are you running Chrome with --mash? It sounds like that may be a requirement to repro the issue.

I added --mash in /etc/chrome_dev.conf
But then ui keep restarting in a loop at login menu.
ui.LATEST attached.

Could you please list the step to use mash ?
I have never used it before.

Thanks!

Deleted: ui.LATEST 17.9 KB

ui.LATEST 17.9 KB Download

Link was tested on M63-9914.0.0 / 63.0.3203.0

Mute and VolUp/Down keys behaved as expected related to sound and tray volume bar.
I observe both the bar and the mute icon appear as expected -https://screenshot.googleplex.com/ToHydqCN54o

Feedback after the issue is reproduced will be helpful. Is it one-time observation?

James, can you help the audio team get a working mash setup?

The "mash" configuration is part of the go/mustash project. It runs the chrome system UI ("ash") in a separate process. It's hidden behind a flag.

Putting --mash in /etc/chrome_dev.conf is the right thing to do. It sounds like you're hitting some other startup crash in chrome. If it's easy for you to do can you get a chrome stack trace somehow?

chrome --mash works for me on link with the latest canary (Chrome 63.0.3207.0 OS 9917), and I still see the issue as described. It also happens at the signin screen. I see the same issue with internal speakers and with headphones.

dbus-monitor --system shows this for me:
method call time=1504737319.302705 sender=:1.7 -> destination=org.chromium.cras serial=252 path=/org/chromium/cras; interface=org.chromium.cras.Control; member=SetOutputUserMute
   boolean true
method return time=1504737319.302732 sender=:1.2 -> destination=:1.6 serial=78 reply_serial=172
method return time=1504737319.302793 sender=:1.28 -> destination=:1.7 serial=190 reply_serial=252

The "member" field is different for me -- did something change on this dbus interface and maybe there's some chrome code that doesn't know?

It's also possible this has never worked in --mash. We currently use CrasAudioHandler::InitializeForTesting() under mash, which surprisingly works for volume control:

https://cs.chromium.org/chromium/src/ash/mus/window_manager_application.cc?l=108

I'll take this issue, since it looks like mash is not initializing things properly. Please let me know if the dbus difference is expected, though.

Note to self: CrasAudioHandler::Initialize() depends on AudioDevicesPrefHandlerImpl which depends on local state prefs. ash::Shell can access local state prefs, but not immediately at startup. Attempting to do CrasAudioHandler initialization in ash after prefs are available causes crashes in TrayAudio initialization, which also happens at startup. This may require prefs and/or startup refactoring to work around startup deadlocks, see issue 594852.

It seems that crash reporter does not work properly when the issue happens.
I enable the core dump and this is what I got in gdb.
It is 100% reproducible on chell so you should be able to debug it further.

The stack trace I got:

(gdb) bt
#0  0x00005fd2e9bdd6aa in ui::DrmOverlayManager::~DrmOverlayManager() () at ../../../../../../../home/chrome-bot/chrome_root/src/ui/ozone/platform/drm/host/drm_overlay_manager.cc:41
#1  0x00005fd2e9be24cb in ui::(anonymous namespace)::OzonePlatformGbm::~OzonePlatformGbm() () at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4/bits/unique_ptr.h:76
#2  0x00005fd2e9be26ce in ui::(anonymous namespace)::OzonePlatformGbm::~OzonePlatformGbm() () at ../../../../../../../home/chrome-bot/chrome_root/src/ui/ozone/platform/drm/ozone_platform_gbm.cc:87
#3  0x00005fd2eb5103c7 in ui::Service::~Service() () at ../../../../../../../home/chrome-bot/chrome_root/src/services/ui/service.cc:164
#4  0x00005fd2eb5105ce in ui::Service::~Service() () at ../../../../../../../home/chrome-bot/chrome_root/src/services/ui/service.cc:150
warning: (Internal error: pc 0x5fd2ec2cd96b in read in psymtab, but not in symtab.)

warning: (Internal error: pc 0x5fd2ec2cd96b in read in psymtab, but not in symtab.)

#5  0x00005fd2ec2cd96c in service_manager::ServiceContext::~ServiceContext() () at /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/4.9.x/include/g++-v4/bits/unique_ptr.h:76
#6  0x00005fd2eb52a6bb in base::internal::Invoker<base::internal::BindState<service_manager::(anonymous namespace)::RunService(service_manager::MainDelegate*)::$_0, service_manager::MainDelegate*, int*>, void (mojo::InterfaceRequest<service_manager::mojom::Service>)>::Run(base::internal::BindStateBase*, mojo::InterfaceRequest<service_manager::mojom::Service>&&) () at ../../../../../../../home/chrome-bot/chrome_root/src/services/service_manager/embedder/main.cc:314
#7  0x00005fd2e9f4e2be in service_manager::RunStandaloneService(base::RepeatingCallback<void (mojo::InterfaceRequest<service_manager::mojom::Service>)> const&) () at ../../../../../../../home/chrome-bot/chrome_root/src/base/callback.h:92
#8  0x00005fd2eb52a064 in service_manager::Main(service_manager::MainParams const&) () at ../../../../../../../home/chrome-bot/chrome_root/src/services/service_manager/embedder/main.cc:285
#9  0x00005fd2eb507601 in content::ContentMain(content::ContentMainParams const&) () at ../../../../../../../home/chrome-bot/chrome_root/src/content/app/content_main.cc:19
#10 0x00005fd2e9a81ee5 in ChromeMain () at ../../../../../../../home/chrome-bot/chrome_root/src/chrome/app/chrome_main.cc:122
#11 0x00007a02cd3f3736 in ?? ()
#12 0x00007ffd7016cdb0 in ?? ()
#13 0x00007ffd7016ce58 in ?? ()
#14 0x000000217016cdb0 in ?? ()
#15 0x00005fd2e9a81e10 in frame_dummy ()
#16 0x0000000000000000 in ?? ()


When --mash is not applied, I can see these from dbus-monitor --system:


method call time=1504670338.631365 sender=:1.11 -> destination=org.chromium.cras serial=704 path=/org/chromium/cras; interface=org.chromium.cras.Control; member=SetOutputUserMute
   boolean true
method return time=1504670338.631419 sender=:1.37 -> destination=:1.11 serial=605 reply_serial=704
signal time=1504670338.631774 sender=:1.37 -> destination=(null destination) serial=606 path=/org/chromium/cras; interface=org.chromium.cras.Control; member=OutputMuteChanged
   boolean false
   boolean true


SetOutputUserMute is chrome asking CRAS to set mute to true.
OutputMuteChanged is CRAS sending a signal saying system mute (false) and user mute(true).


Hope this helps!
Thanks!

Note to self: Stack looks like shutdown crash in service manager process, possibly there's another crash elsewhere first.

Also, I wasn't getting the signal from CRAS -> chrome (or ash?) that mute was changed.

Mute works fine in SingleProcessMash.

Mute still has problems as described with (multi-process) Mash. Tagging so mustash-team can look at it later.

Bulk-assigning unassigned status area bugs to me.