Reviewed logs and found this error on Mar 10:

2016-03-10T16:03:57.073869+00:00 INFO kernel: [    6.123691] usb 1-6: New USB device found, idVendor=0b0e, idProduct=0410
2016-03-10T16:03:57.073870+00:00 INFO kernel: [    6.123718] usb 1-6: New USB device strings: Mfr=0, Product=2, SerialNumber=3
2016-03-10T16:03:57.073872+00:00 INFO kernel: [    6.123737] usb 1-6: Product: Jabra SPEAK 410 USB
...
2016-03-10T16:03:59.667331+00:00 ERR cras_server[7603]: USB card: vendor:0b0e, product:0410, checksum:3ac16078
2016-03-10T16:03:59.686859+00:00 ERR cras_server[7603]: Can not open ucm for card Jabra SPEAK 410 USB, rc = -2

I would recommend to have customer try https://test.webrtc.org and check if starting video Hangouts is really the trigger of this issue.

That ucm log is a normal message, not an error, we should change the print level on it.

As far as I know, there's nothing at the WebRTC layer to automatically trigger an input device switch. I therefore think something at the Hangouts or other "higher" layer is somehow requesting an input change.

mnilsson@ - can you help get this routed to the right folks? Note that the reports appear to be from ChromeOS versions based on Chrome 48, but it looks like ChromeOS based on Chrome 49 was pushed to stable on March 15[1]. I'm not sure if the Chromeboxes mentioned here should have Chrome 49 by now.

It works as expected that a mic on webcam got auto-selected when it hotplugged.
If the mic input do exists but not appear in the Chrome OS audio settings, then that is a bug.

Can you attach the log generated by 'generate_logs' command? or use alt+shift+i to send a report.

 Issue 599429  has been merged into this issue.

We finally got diagnostic_logs from the customer as requested by comment #6.
Could you investigate using this logs?

[diagnostic_logs]
https://drive.google.com/a/google.com/file/d/0B8hJbBKk0-c4U25jRXVYSktiTUk/view?usp=sharing

I think the web cam has been recognized on the device layer.
./lsusb_output.txt
Bus 001 Device 011: ID 145f:01a1 Trust 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass          239 Miscellaneous Device
  bDeviceSubClass         2 ?
  bDeviceProtocol         1 Interface Association
  bMaxPacketSize0        64
  idVendor           0x145f Trust
  idProduct          0x01a1 
  bcdDevice            0.02
  iManufacturer           3  
  iProduct                1 Trust HD Webcam
  iSerial                 0 
  bNumConfigurations      1

./system_level_logs/log/messages
2016-06-14T15:23:27.937463+00:00 INFO kernel: [  174.552608] usb 1-6: USB disconnect, device number 6
2016-06-14T15:23:28.223723+00:00 INFO kernel: [  174.838959] usb 1-6: new high-speed USB device number 8 using xhci_hcd
2016-06-14T15:23:28.326981+00:00 ERR cras_server[6020]: No chmap queried!
2016-06-14T15:23:28.347724+00:00 INFO kernel: [  174.963348] usb 1-6: New USB device found, idVendor=145f, idProduct=01a1
2016-06-14T15:23:28.347744+00:00 INFO kernel: [  174.963368] usb 1-6: New USB device strings: Mfr=3, Product=1, SerialNumber=0
2016-06-14T15:23:28.347747+00:00 INFO kernel: [  174.963382] usb 1-6: Product: Trust HD Webcam
2016-06-14T15:23:28.347750+00:00 INFO kernel: [  174.963393] usb 1-6: Manufacturer:  
2016-06-14T15:23:28.351718+00:00 INFO kernel: [  174.967727] uvcvideo: Found UVC 1.00 device Trust HD Webcam (145f:01a1)
2016-06-14T15:23:28.733978+00:00 DEBUG kernel: [  175.347282] ieee80211 phy0: device no longer idle - scanning
2016-06-14T15:23:32.688710+00:00 DEBUG kernel: [  179.303698] ieee80211 phy0: device now idle

Just a quick question, is there any update? thx :)

+jennyz for node selection

I checked the log:

Output Devices:
        ID      Name (Stable ID)
        11      HDA Intel PCH: ALC283 Analog:3,0 (8161f03b)
        10      HDA Intel MID: HDMI 2:2,8 (86c29701)
        9       HDA Intel MID: HDMI 1:2,7 (ed2c8a6a)
        8       HDA Intel MID: HDMI 0:2,3 (d00448ec)
        5       Jabra SPEAK 410 USB: USB Audio:0,0 (33d84009)
Output Nodes:
         ID      Vol   Plugged  L/R swapped           Time      Type             Name
        11:0      100       no              no           0      HEADPHONE        Headphone Jack
        10:0      100       no              no           0      HDMI             HDMI/DP,pcm=8 Jack
        9:0       100       no              no           0      HDMI             HDMI/DP,pcm=7 Jack
        8:0       100      yes              no  1465917643      HDMI             
        8:1       100       no              no           0      HDMI             HDMI
        5:0        75      yes              no  1465917642      USB             *Jabra SPEAK 410 USB: USB Audio:0,0: Headset
Input Devices:
        ID      Name (Stable ID)
        16      Trust HD Webcam: USB Audio:1,0 (e2cca971)
        12      HDA Intel PCH: ALC283 Analog:3,0 (8161f03b)
        6       Jabra SPEAK 410 USB: USB Audio:0,0 (33d84009)
        4       Post DSP Loopback (8c74f766)
        3       Post Mix Pre DSP Loopback (8a04af91)
Input Nodes:
         ID     Gain   Plugged  L/R swapped           Time      Type             Name
        16:0        0      yes              no  1465917891      USB             *Trust HD Webcam: USB Audio:1,0: Mic    ------> Selected because it is the latest plugged node
        12:0        0       no              no           0      MIC              Mic
        12:1        0       no              no           0      MIC              Mic Jack
        6:0         0      yes              no  1465917643      USB              (default)                       -----------> Should select this one instead
        4:0         0      yes              no           0      POST_DSP_LOOPBACK Post DSP Loopback
        3:0         0      yes              no           0      POST_MIX_LOOPBACK Post Mix Pre DSP Loopback


The node 6:0 is shown as (default) in cras_test_client --dump_s output, but Chrome will name it using USB card name and device name
"Jabra SPEAK 410 USB: USB Audio:0,0."

Since Chrome UI selects nodes based on its own logic, CRAS can not help here.
I am not sure if Hangout app can control the node selection.
chrome.audio API https://developer.chrome.com/apps/audio provides OnDevicesChanged method, but that is only experimental and is only available for dev channel.

Hi Jenny, should this be taken care of in Chrome ?
Thanks!

I can imagine that user often doesn't know there's a mic on webcam, and it's hard to notice if input device has changed.
Maybe Chrome UI can scan if the node name contains 'webcam' and lower the priority on hotplug?

If hangouts selects the webcam when it is starting, then one of two things have happened:
1 - the user has previously used the hangouts device selection dialog to save a device selection involving the webcam.
2 - the previously saved device can't be found on the system, then hangouts selects a replacement device in its stead.

The saved selection is kept in HTML5 local storage.

It is known that USB device names may change across reboots. When a device is hot plugged, it gets a new usb device name and after reboot it might not get the same one again.

CfM addresses this use case specifically, but I'm not sure how hangouts on chromeos box in desktop mode behaves. I believe that it should be possible to alleviate this problem by:
1 - keep all the desired devices plugged in and reboot
2 - start a hangouts session, go to the settings dialog and ensure the right devices are selected, save and close the settings dialog.
3 - reboot and go to hangouts, check the device settings again; should still be correct.

Chrome tries to activate a hotplugged device. Where CfM counteracts that and tries to always reinstate the desired device, Hangouts goes with chrome's suggestion. The latter behavior is fine for a personal device, while CfM is a centrally managed device.

Can you see if my suggestions work?

Activating. Please assign to the right owner and the appropriate priority.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.