New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 776549 link

Starred by 4 users

Issue metadata

Status: Verified
Owner:
Closed: Nov 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug



Sign in to add a comment

3.5 mm mic is not switching on replug after manually changing the audio nodes to onboard.

Project Member Reported by sontis@chromium.org, Oct 19 2017

Issue description

ChromeOS: 10032.7.0
Chrome Version: 63.0.3239.11 

What steps will reproduce the problem?
(1) Sign in to the device.
(2) Plug in 3.5 head set.
(3) Manually change audio input and output to onboard.
(4) Unplug and re plug 3.5 mm head set.

What is the expected result?
Audio input and ouput should switch to 3.5mm head set.

What happens instead?
Audio Output : 3.5 mm head set.
Audio input : Onboard (Internal mic)



 

Comment 2 by sontis@chromium.org, Oct 19 2017

Labels: M-63

Comment 3 by ka...@chromium.org, Oct 19 2017

Owner: jen...@chromium.org
Jenny, isn't it that audio jack mic node follow same (per device only priority) pattern as the output node?

Comment 4 by gkihumba@google.com, Oct 27 2017

Status: Assigned (was: Untriaged)
Any updates?
Sorry, I was OOO until today.  kalin@, To answer your question, the logic we put in for always prioritize the 3.5mm headphone only applies to output, not the input. 

The original request is only for output. Should we also apply the same rule to 3.5mm mic, it is a PM call.
Cc: dgreid@chromium.org
Jenny - we probably want to be consistent, I imagine users would be confused if their headset earbuds worked but not the headset mic, since it's a single peripheral. Can we apply the same rule for output as well as input? Thanks!
Status: Started (was: Assigned)

Comment 8 by jen...@chromium.org, Nov 10 2017

The code change would be simple. But I will need a 3.5mm headset with 3.5mm mic to test, since I need to verify the audio device type cras sent to chrome for 3.5mm mic. kalin@, can you borrow me one such device for testing?

Comment 9 by ka...@chromium.org, Nov 10 2017

Yes, I have it at my desk.
Status: Fixed (was: Started)
Labels: Merge-TBD
[Auto-generated comment by a script] We noticed that this issue is targeted for M-63; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-63 label, otherwise remove Merge-TBD label. Thanks.
Labels: Merge-Request-63
Project Member

Comment 13 by sheriffbot@chromium.org, Nov 13 2017

Labels: -Merge-Request-63 Merge-Review-63 Hotlist-Merge-Review
This bug requires manual review: M63 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), gkihumba@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Please link this bug in the CL that fixes issue. 
Cc: abodenha@chromium.org
Here is the cl that lands in Tot. Somehow it didn't auto updated in this issue.
https://chromium-review.googlesource.com/c/chromium/src/+/762141

I talked to abodenha@, this may not be a super critical cl to merge back to R63.
I'd go further. We're very late in the 63 cycle. I'm really reluctant to accept a merge for this unless someone can explain why it's super critical.
Labels: -M-63 M-64
agreed, let's move to M-64
Labels: -Merge-Review-63
Labels: -ReleaseBlock-Stable
Project Member

Comment 20 by sheriffbot@chromium.org, Jan 19 2018

Labels: -Merge-TBD
Status: Verified (was: Fixed)
Verified.

Sign in to add a comment