Audio volume is reduced, and only returned to normal after reboot |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Issue descriptionSeen on Caroline an Kevin: Kevin: https://listnr.corp.google.com/report/74337811152 Description: Sound is low. Volume is all the way up but sound is anemic. Caroline: https://listnr.corp.google.com/report/74363306854 Description: dgreid: caroline volume too low. maybe some volume control got set incorrectly?
,
Oct 13 2017
Another report. https://listnr.corp.google.com/product/208/report/75914385258 This appears to be happening to all Skylake boards.
,
Oct 13 2017
Just to add another data point. I'm also getting it, both on headphone and speakers. Google Chrome 62.0.3202.43 (Official Build) beta (64-bit) Revision 0 Platform 9901.35.1 (Official Build) beta-channel chell Firmware Version Google_Chell.7820.314.0 Customization ID CHELL ARC 4369606 Not sure what the code name of my device is, it's the corp HP 13" G1. Also, from my testing, it doesn't need a full reboot, even closing and opening the laptop resets the max volume, though it lowers back again fairly quickly over a minute or two.
,
Oct 16 2017
On Kevin, https://listnr.corp.google.com/report/74337811152 The headphone was not plugged. Speaker volume was at 100. Kevin speaker has no volume control so CRAS controls software volume. If the volume is too low, there might be issue in software volume. But we don't have software volume change recently. In this report https://listnr.corp.google.com/product/208/report/74363306854 Headphone was at volume 100: Stable Id ID Vol Plugged L/R swapped Time Hotword Type Name (34cb7f6c) 12:0 100 no no 0 HDMI HDMI/DP, pcm=6 Jack (48b0443e) 11:0 100 no no 0 HDMI HDMI/DP, pcm=5 Jack (7a4f63c9) 10:0 100 no no 0 HDMI HDMI/DP, pcm=4 Jack (9e934263) 6:0 100 yes no 1506448475 HEADPHONE *Headphone (72a57953) 6:1 56 yes no 1506354801 INTERNAL_SPEAKER Speaker Volume 100 corresponds to -5.5 dB as stated in the volume table https://cs.corp.google.com/chromeos_public/src/overlays/overlay-caroline/chromeos-base/chromeos-bsp-caroline/files/audio-config/cras-config/sklnau8825adi?l=106 The "Headphone" volume control was at 57 out of 63. Simple mixer control 'Headphone',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 63 Front Left: 57 [90%] [-5.15dB] Front Right: 57 [90%] [-5.15dB] Which was about right. In this report https://listnr.corp.google.com/product/208/report/75914385258 It said: "Volume seems much lower on every site after the latest Beta update." The control for headphone volume was at 35 out of 63. Simple mixer control 'Headphone',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 63 Front Left: 35 [56%] [-24.00dB] Front Right: 35 [56%] [-24.00dB] Volume of headphone was at 56 out of 100. Output Nodes: Stable Id ID Vol Plugged L/R swapped Time Hotword Type Name (34cb7f6c) 12:0 100 no no 0 HDMI HDMI/DP, pcm=6 Jack (48b0443e) 11:0 100 no no 0 HDMI HDMI/DP, pcm=5 Jack (7a4f63c9) 10:0 100 no no 0 HDMI HDMI/DP, pcm=4 Jack (9e934263) 6:0 56 yes no 1507765701 HEADPHONE *Headphone (72a57953) 6:1 24 yes no 1507756815 INTERNAL_SPEAKER Speaker The volume curve stated that volume at 56 is -24 dB https://cs.corp.google.com/chromeos_public/src/overlays/overlay-caroline/chromeos-base/chromeos-bsp-caroline/files/audio-config/cras-config/sklnau8825adi?l=150 So, the control was set correctly. We should try to reproduce the issue on caroline and check at that time, whether the control has any effect. Or, maybe there are other controls affecting the volume. We should try to reproduce the issue on kevin and see at that time, whether software volume has any effect.
,
Oct 16 2017
,
Oct 16 2017
Observation on my Caroline 60.0.3112.80 beta: 1. Cras_test_client shows HEADPHONE @ 100 before plug-in, plug a headphone, it drops to 75, and reflected on UI as well. 2. Suspend / Resume didn't change the volume both on UI and cras server Download from gs://chromeos-releases/dev-channel/caroline/9901.21.0/ChromeOS-test-R62-9901.21.0-caroline.tar.xz ( https://listnr.corp.google.com/product/208/report/74363306854 ) Try to reproduce on 62.0.3202.28 dev 1. Cras_test_client shows HEADPHONE @ 75 before plug-in, plug a headphone, enhence from UI to 100% . cras_test_client looks fine. 2. Suspend / Resume didn't change the volume both on UI and cras server 3. Reboot doesn't help.
,
Oct 16 2017
Hi Chris, Will be appreciate on steps to reproduce it.
,
Oct 17 2017
Cannot reproduce. Lowering the priority.
,
Oct 19 2017
Not sure if these logs help, but it's from Caroline. https://listnr.corp.google.com/report/76746443315 Description: Caroline M7: Default volume is extremely low. At 50% I can barely hear my music through headphones. Need to turn it to 100% to listen at a decent level in a quiet office.
,
Oct 20 2017
In the log of #9, Headphone volume was at 47 (9e934263) 6:0 47 yes no 1508442565 HEADPHONE *Headphone Headphone control was at -27.43 dB. Simple mixer control 'Headphone',0 Capabilities: volume Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 63 Front Left: 31 [49%] [-27.43dB] Front Right: 31 [49%] [-27.43dB] That was close to what volume curve specifies: https://cs.corp.google.com/chromeos_public/src/overlays/overlay-caroline/chromeos-base/chromeos-bsp-caroline/files/audio-config/cras-config/sklnau8825adi?l=159 Based on this and #4, I think we can confirm: 1. volume table loaded fine. 2. control set correctly. Possible reason I can think of : 1. Perhaps the samples got attenuated by Chrome or CRAS. 2. Control set correctly but did not take effect. If we playback using aplay -D to bypass CRAS we can tell which cause it might be. But we will need to reproduce the issue on a test image first.
,
Oct 24 2017
I get this very often. Is there anything I can do or run or extract while it's happening to help here?
,
Oct 24 2017
,
Oct 24 2017
Here are two HP 13 users reporting. Sound volume dropping after some time in online videos - Google Product Forums https://productforums.google.com/forum/#!topic/chromebook-central/BkpTFLDtZK4
,
Oct 24 2017
,
Nov 7 2017
Corp issued HP 13, experienced "volume is too low" problem. Observed that lowering the volume and restarting the computer helps. It looks like the volume before the restart is used as a new baseline (e.g. in was 75% before, after the restart you'll be able to only increase it by 25%, although in reality it is set to a much lower value). Google Chrome 63.0.3239.26 (Official Build) beta (64-bit) Revision 0 Platform 10032.21.0 (Official Build) beta-channel chell Firmware Version Google_Chell.7820.314.0 Customization ID CHELL ARC 4421479
,
Nov 10 2017
I'm also seeing this on an HP Chromebook 13 G1 (chell) when using headphones - the issue started when I updated from M61 to M62. Version 62.0.3202.82 (Official Build) (64-bit) Platform 9901.66.0 (Official Build) stable-channel chell Firmware Google_Chell.7820.314.0
,
Nov 13 2017
I'll take a look.
,
Nov 13 2017
Hi ehsankia@, Since the issue happens very often on your device, it will be more efficient for us to take your device to debug. If you agree to swap the device, I will sent out a mail to arrange the shipping. Thanks!
,
Nov 13 2017
I got a chell and flashed it to 9901.66.0. There was no audio at all. I saw some snd_soc_skl errors in dmesg. 2017-11-13T18:12:21.234457+08:00 ERR kernel: [ 243.090458] snd_soc_skl 0000:00:1f.3: ipc: delete pipeline failed, err -110 2017-11-13T18:12:21.234459+08:00 ERR kernel: [ 243.090485] snd_soc_skl 0000:00:1f.3: Failed to delete pipeline 2017-11-13T18:12:21.235422+08:00 ERR kernel: [ 243.595449] snd_soc_skl 0000:00:1f.3: ipc: set dx failed, err -110 2017-11-13T18:12:21.235428+08:00 ERR kernel: [ 243.595470] snd_soc_skl 0000:00:1f.3: D3 request to FW failed, continuing reset: -110 2017-11-13T18:17:42.482475+08:00 ERR kernel: [ 453.198194] snd_soc_skl 0000:00:1f.3: skl_is_pipe_mcps_avail: module_id 3 instance 0 2017-11-13T18:17:42.482488+08:00 ERR kernel: [ 453.198213] snd_soc_skl 0000:00:1f.3: exceeds ppl mcps available 30000000 > mem -1000000 2017-11-13T18:17:42.482491+08:00 ERR kernel: [ 453.198228] snd_soc_skl 0000:00:1f.3: ASoC: PRE_PMU: media0_in cpr 0 event failed: -16 2017-11-13T18:17:42.482494+08:00 ERR kernel: [ 453.198242] snd_soc_skl 0000:00:1f.3: skl_is_pipe_mcps_avail: module_id 2 instance 0 2017-11-13T18:17:42.482496+08:00 ERR kernel: [ 453.198255] snd_soc_skl 0000:00:1f.3: exceeds ppl mcps available 30000000 > mem -1000000 2017-11-13T18:17:42.482498+08:00 ERR kernel: [ 453.198268] snd_soc_skl 0000:00:1f.3: ASoC: PRE_PMU: codec0_out mo event failed: -16
,
Nov 13 2017
Audio is back after I updated the firmware. chromeos-firmwareupdate --mode=autoupdate
,
Nov 13 2017
I reproduced once using chell R62 9901.35.1. The max volume using headphone became lower. It's recovered after unplugging and plugging headphone. I could only reproduce once. I'm not sure about the repro steps. I was watching a youtube video. Changing volumes. Changing output between headphone and internal. Doing suspend / resume. Then the issue happened. It's hard to repro. I'll continue trying. Jimmy suggested dumping audio_diagnostics when the issue happens and doesn't happen.
,
Nov 13 2017
I reproduced again with bluetooth headset Bose QuiteComfort 35. The max volume using bt was low. I'm not sure the repro steps. I was doing the following things and the issue happened. I could only reproduce once. (1) Play a youtube video. (2) Plug a headphone. (3) Connect bt headset. (4) Change the volumes of each output. (5) Switch between each output. (6) Suspend / resume. After it happened, I tried the following things and it didn't recover (1) Disable / enable bt. (2) Turn off / turn on bt headset. (3) Unplug / plug headphone. But after I did "sox -b 16 -r 48000 -c 2 -n -t alsa hw:0,0 synth sine 300 sine 300" and cancel it, the volume of bt recovered. I've attached the logs when it happened and the logs after reboot. After reboot, bt volume was back to normal.
,
Nov 13 2017
I'm not sure if capped volume of bt and headphone are the same problem. I reproduced on bt again. I reboot DUT and the issue was not fixed. I pressed the volume key on bt headset. The volume UI jumped from 100% to 50%. It looked like DUT suddenly realized the volume was not 100. Then I changed the volume to max and the issue was gone (the volume was loud enough).
,
Nov 14 2017
No progress today. I spent 40 minutes and couldn't reproduce the issue.
,
Nov 15 2017
I'm having the same issue as well. Replaced a different unit but still facing the same issue.
,
Nov 15 2017
Hi all, Please provide the following information when you see this issue: - ChromeOS version and device name. - Submit a feedback report and add 769446 to the description. So we can find it easily. - Repro steps. I'm having a hard time reproducing the issue. - Whether the issue is persistent or gone after reboot.
,
Nov 15 2017
b/69087090 is the same bug.
,
Nov 16 2017
No progress today. I brought cave 9901.54.0 with me. I watched youtube and local videos using BT and 3.5mm headphone. I couldn't reproduce the issue.
,
Nov 16 2017
I'm suspecting maybe the issue happens more easily after an update. IIRC, after I flash the image, I reproduced on chell on the first try. I'll test the theory tomorrow.
,
Nov 16 2017
My HP Chromebook 13 (chell) running Chrome OS stable (62.0.3202.82) is in this state right now - I just filed feedback from my google.com account with 769446 in the description. I don't have any specific repro steps, it just seems to happen randomly. Rebooting fixes the problem.
,
Nov 17 2017
,
Nov 17 2017
I collected all reports in a spreadsheet (see b/69087090). Some observations: - 5 reports on cave, 5 on caroline, and 5 on chell. 1 on kevin and 1 on bob. Most reports are on Skylake-Y. - 12 reports on M62, 1 M60 (kevin), 1 M61, 2 M63, 1 M64. - 13 reports on headphone, 1 headphone and internal speaker, 1 internal speaker - Three reports said the issue happened after an update.
,
Nov 17 2017
Cave, caroline, chell are SKY-Y. Kevin and bob are RK3399.
,
Nov 17 2017
I tried again on chell and couldn't reproduce the issue. - Flash to M61 9765.85.0. - chromeos-firmware -m autoupdate - Flash to M62 9901.35.1 - chromeos-firmware -m autoupdate I'll try caroline next.
,
Nov 17 2017
We reproduced this issue on a caroline device. Then, we compare the audio_diagnostics result and nau8825 registers when issue happened (bad) and recovered (good) after reboot. We found that there are some difference in the mixer setting by comparing ad.good and ad.bad. Then, we manually change the mixer controls on the recovered device, trying to reproduce the issue. We still can not trigger the issue. The audio_diagnostic result and registers were in ad.change_to_bad_manually and reg.change_to_bad_manually. First, we compared mixer control difference between ad.bad and ad.good. In ad.bad, 'DACR Mux' is set to 'DACL'. This does not look correct. This is the first clue we should look into. In ad.bad, 'Headphone Crosstalk' is set to 140, while it is 141 in ad.good. Other changes were in mic and speaker, which should not be related to this issue. After we manually change all the controls to the same as the bad one, we compare reg.change_to_bad_manually and reg.bad. We still see some difference. There was no mixer control difference We found some interesting difference between reg.change_to_bad and reg.bad 1: 037f | 01: 077f 11: 0000 | 11: 0100 33: 00cf | 33: 0000 34: 00cf | 34: 0000 4d: 4fb2 | 4d: 54f6 81: 002c | 81: 0008 We don't really know how come they are different. We think crosstalk function might be related. The patch series https://chromium-review.googlesource.com/#/c/chromiumos/third_party/kernel/+/640290/1 was merged to R62. for issue https://b.corp.google.com/issues/35574278 Since the function was added in R62, but the device does not use FW new enough (>7820.336 for caroline) to bypass crosstalk function. There are boards running crosstalk function, and we suspect that cause some registers set incorrectly sometimes.
,
Nov 17 2017
+kchsu for nau8825. Hi KC, could you please check why registers does not look right ? Thanks!
,
Nov 17 2017
Here are some more details for #35. The bug is in kernel or below. The bug is not in cras or chrome. In low volume state, we played a video using sox (bypassing cras and chrome). The volume was still low. Jimmy and I got three caroline today. I couldn't reproduce on one of the caroline. The other two were in low volume state when I got them from the coworkers. One is in not the dev mode. So we filed a feedback and rebooted it. The low volume issue was gone. We used the last one to get the information in #35. I checked the firmware of all feedback reports. The version was all 7820.329.0 or before.
,
Nov 17 2017
,
Nov 18 2017
The registers are incorrect and strange when the device is bad. The registers of reg.bad in comment 35 show as follows: 30: 0000 //Driver should not set the value except of abnormal crosstalk sequence. 33: 0000 //Same as above. It will affect the output volume. 34: 0000 //Same as 33. 2f: 8c8c //The value should keep 0 if bypassing crosstalk. The issue of headphone should relate to crosstalk sequence. I guess the sequence is stop accidentally and recover the wrong value. But the final solution bypasses the crosstalk totally, it should not happen in the case. Could you help to check the property "nuvoton,crosstalk-bypass" is set in bad device? Open debug message of nau8825 and you can see the value as well.
,
Nov 20 2017
Please help to add debug message as the patch doing. Then get the debug message by command "dmesg | grep 8825" when the issue happens. We want to know what's happened in crosstalk sequence. Why do these register become strange?
,
Nov 20 2017
kchsu0@ It was super hard for us to reproduce it. Most devices in a bad state were from other coworkers. We can add the debug message but I don't think we can reproduce it. I think we should go ahead and set "nuvoton,crosstalk-bypass" for M62. I will check what firmware is used by SKL in M62 and M63 later today.
,
Nov 20 2017
Thank you KC. Summarize the status of each project: These five has property set in firmware: Lars @ 7820.346.0 https://chromium-review.googlesource.com/#/c/chromiumos/third_party/coreboot/+/741383/ Chell @ 7820.332.0 https://chromium-review.googlesource.com/#/c/chromiumos/third_party/coreboot/+/615028/ Cave @ 7820.342.0 https://chromium-review.googlesource.com/#/c/chromiumos/third_party/coreboot/+/720346/ Sentry @ 7820.341.0 https://chromium-review.googlesource.com/#/c/chromiumos/third_party/coreboot/+/681155/ Caroline @ 7820.336.0 https://chromium-review.googlesource.com/#/c/chromiumos/third_party/coreboot/+/680695/ All of them do NOT have chromeos-firmwareupdater uprev to version new enough to include the change Caroline @ 9901.23.0 uprev to 7820.329.0 https://chrome-internal-review.googlesource.com/#/c/chromeos/overlays/overlay-caroline-private/+/459512/ Chell @ 9843.0.0 uprev to 7820.314.0 https://chrome-internal-review.googlesource.com/#/c/chromeos/overlays/overlay-chell-private/+/405128/ Lars @ 9742.0.0 uprev to 7820.314.0 https://chrome-internal-review.googlesource.com/#/c/chromeos/overlays/overlay-lars-private/+/405065/ Cave @ 9901.9.0 uprev to 7820.329.0 https://chrome-internal-review.googlesource.com/#/c/chromeos/overlays/overlay-cave-private/+/449892/ Sentry @ 9820.0.0 uprev to 7820.314.0 https://chrome-internal-review.googlesource.com/#/c/chromeos/overlays/overlay-sentry-private/+/405088/ These three have NO property set in firmware: pbody, lili, asuka
,
Nov 20 2017
According to #42, the issue exists in M62, M63, and M64.
,
Nov 20 2017
Great news. After reading the code, I can reproduce this consistently now. Repro steps: - Reboot - Login - Suspend/resume by closing and opening the lid. (after this step, register 0x33 and 0x34 will become 0) - Play a YouTube video. - Plug a low impedance headphone. - Set volume to 48. - Repeat plugging and unplugging headphone. Observed: Headphone volume became small. I'll debug more. Some of the repro steps may not be necessary.
,
Nov 20 2017
- In repro steps of #44, plugging the headphone once is enough. - I added some kernel logs. nau8825.c has a register backup/restore mechanism during crosstalk. By default, all backup variables are 0. The variables will be initialized in the first backup. Suppose we haven't used headphone at all after reboot (meaning backup has never been called). If we do suspend/resume, restore will be triggered and 0 will be written to 0x33 and 0x34. 0x33 and 0x34 will be stuck at 0 forever. - After suspend/resume, xtalk_protect is set to true in nau8825_resume. Then nau8825_eject_jack is called, which triggered the restore. See the logs for the detail call sequence. 2017-11-20T16:08:17.519841+08:00 ERR kernel: [ 25.859536] nau8825_resume 2017-11-20T16:08:17.519865+08:00 ERR kernel: [ 25.862616] nau8825_set_bias_level: level=1 2017-11-20T16:08:17.519867+08:00 ERR kernel: [ 25.863404] nau8825_eject_jack 2017-11-20T16:08:17.519869+08:00 ERR kernel: [ 25.863413] nau8825_xtalk_cancel 2017-11-20T16:08:17.519870+08:00 ERR kernel: [ 25.863421] nau8825_xtalk_cancel: xtalk_protect==true 2017-11-20T16:08:17.519872+08:00 ERR kernel: [ 25.863432] nau8825_xtalk_clean 2017-11-20T16:08:17.519875+08:00 WARNING kernel: [ 25.863640] nau8825 i2c-10508825:00: Disable clock for power saving when no headset connected 2017-11-20T16:08:17.519877+08:00 ERR kernel: [ 25.864010] nau8825_xtalk_restore 2017-11-20T16:08:17.519878+08:00 ERR kernel: [ 25.864192] nau8825_xtalk_restore: i=0, def=0 2017-11-20T16:08:17.519880+08:00 ERR kernel: [ 25.864370] nau8825_xtalk_restore: i=2, def=0 2017-11-20T16:08:17.519881+08:00 ERR kernel: [ 25.864555] nau8825_xtalk_restore: i=3, def=0 2017-11-20T16:08:27.728343+08:00 ERR kernel: [ 36.379760] nau8825_interrupt: NAU8825_HEADSET_COMPLETION_IRQ 2017-11-20T16:08:27.728368+08:00 ERR kernel: [ 36.379967] nau8825_interrupt: jack inserted: jack inserted. xtalk_bypass=0, nau8825->high_imped=0 2017-11-20T16:08:27.728371+08:00 ERR kernel: [ 36.380171] nau8825_jack_insert: high_imped=0 2017-11-20T16:08:27.730614+08:00 ERR kernel: [ 36.381092] nau8825_interrupt: scheduled xtalk_work 2017-11-20T16:08:27.730627+08:00 ERR kernel: [ 36.381117] nau8825_xtalk_work 2017-11-20T16:08:27.730630+08:00 ERR kernel: [ 36.381129] nau8825_xtalk_measure: nau8825->xtalk_state=0 2017-11-20T16:08:27.730632+08:00 ERR kernel: [ 36.381136] nau8825_xtalk_prepare 2017-11-20T16:08:27.730633+08:00 ERR kernel: [ 36.381140] nau8825_xtalk_backup 2017-11-20T16:08:28.338515+08:00 ERR kernel: [ 36.989185] nau8825_interrupt: NAU8825_IMPEDANCE_MEAS_IRQ. scheduled xtalk_work 2017-11-20T16:08:28.338541+08:00 ERR kernel: [ 36.989217] nau8825_xtalk_work 2017-11-20T16:08:28.338544+08:00 ERR kernel: [ 36.989236] nau8825_xtalk_measure: nau8825->xtalk_state=1 2017-11-20T16:08:28.661474+08:00 ERR kernel: [ 37.312225] nau8825_interrupt: NAU8825_IMPEDANCE_MEAS_IRQ. scheduled xtalk_work 2017-11-20T16:08:28.661494+08:00 ERR kernel: [ 37.312263] nau8825_xtalk_work 2017-11-20T16:08:28.661496+08:00 ERR kernel: [ 37.312269] nau8825_xtalk_measure: nau8825->xtalk_state=2 2017-11-20T16:08:28.812209+08:00 ERR kernel: [ 37.463073] nau8825_xtalk_measure: nau8825->xtalk_state=3 2017-11-20T16:08:28.812238+08:00 ERR kernel: [ 37.463260] nau8825_xtalk_clean 2017-11-20T16:08:28.815209+08:00 ERR kernel: [ 37.466078] nau8825_xtalk_restore 2017-11-20T16:08:28.815227+08:00 ERR kernel: [ 37.466251] nau8825_xtalk_restore: i=0, def=0 2017-11-20T16:08:28.815229+08:00 ERR kernel: [ 37.466418] nau8825_xtalk_restore: i=2, def=0 2017-11-20T16:08:28.815231+08:00 ERR kernel: [ 37.466586] nau8825_xtalk_restore: i=3, def=0 2017-11-20T16:08:28.815233+08:00 ERR kernel: [ 37.466592] nau8825_xtalk_measure: NAU8825_XTALK_IMM 2017-11-20T16:08:28.874206+08:00 ERR kernel: [ 37.525772] nau8825_set_bias_level: level=2 2017-11-20T16:08:28.875288+08:00 ERR kernel: [ 37.526533] nau8825_set_bias_level: level=3 2017-11-20T16:08:28.888206+08:00 ERR kernel: [ 37.539697] nau8825_set_bias_level: level=2 2017-11-20T16:08:28.890160+08:00 ERR kernel: [ 37.541851] nau8825_set_bias_level: level=1 2017-11-20T16:08:47.203250+08:00 ERR kernel: [ 55.854034] nau8825_set_bias_level: level=2 2017-11-20T16:08:47.229245+08:00 ERR kernel: [ 55.880000] nau8825_set_bias_level: level=3 2017-11-20T16:09:09.965227+08:00 ERR kernel: [ 78.616539] nau8825_set_bias_level: level=2 2017-11-20T16:09:09.979427+08:00 ERR kernel: [ 78.630920] nau8825_set_bias_level: level=1
,
Nov 20 2017
Uploaded https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/778501 for review.
,
Nov 20 2017
This is the step to dump registers. cd /sys/kernel/debug/regmap/i2c-10508825\:00/ echo 1 > cache_bypass cat registers
,
Nov 20 2017
Yes, the analysis of comment #45 is correct. The driver will restore wrong value if never plugin and eject IRQ happens. After reviewing the sequence, there are two weakness which we need to fix. At First, the default restore value should not assign to zero, but as the value after initiation. The second one, all entry point should block if the property "nuvoton,crosstalk-bypass" is set. We will try to duplicate the issue locally and release the patch to kernel. Could you help to try run the patch if need your confirm?
,
Nov 20 2017
John. I can help verify your patch after your test it on your side. Please also upload the patch for upstream review. I also uploaded a patch to ChromeOS gerrit because I want to create a very small one to merge back to M62 and M63. Please help review it. https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/778501. After your proper patch is accepted in upstream, we can revert mine in ChromeOS tot and merge yours.
,
Nov 20 2017
Hi Wu-Cheng, Thank you for help. I'll make a solution to fix the issue. Then release to you, and do upstream. OK, I'll review it.
,
Nov 20 2017
#42 missed kunimitsu (reference board for skylake U)
,
Nov 20 2017
I found another bug of crosstalk. http://crbug.com/786989 . John. Is crosstalk used by any ChromeOS or non ChromeOS project? If not, how do you think removing it? I think it complicates the code. There are lots of code paths and hard to make it right.
,
Nov 21 2017
We are going to test and uprev cave firmware to 7820.347.0. If there's any kernel change should go together, please let me know. Thanks.
,
Nov 21 2017
Please apply the CL as follows which checked in by Wu-Cheng: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/778501 There is still a weakness even bypassing the crosstalk. The CL can fix the issue.
,
Nov 21 2017
- The firmware 7820.347.0 alone cannot fix this issue. CL 778501 is required to fix this issue. - This kernel change and firmware can be merged separately. If they are both merged, http://crbug.com/786989 will also be fixed. - I think it's too risky to cherry-pick 7820.347.0 to M62. Cherry-picking 778501 to M62 is less risky.
,
Nov 21 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5802908af5d6a7d93b2f0d0f03542e91dbe9ade2 commit 5802908af5d6a7d93b2f0d0f03542e91dbe9ade2 Author: Wu-Cheng Li <wuchengli@google.com> Date: Tue Nov 21 09:59:12 2017 CHROMIUM: ASoC: nau8825: fix low volume of headphone. nau8825_xtalk_baktab is used to backup and restore registers in crosstalk. The values are 0 by default and initialized in backup. Suppose a device has not plugged a headphone after boot, which means backup has never been called. After suspend/resume, restore will be called and 0 will be written to the registers. Both nau8825_xtalk_baktab and resgisters will be 0. The headhpone volume will be stuck low. Add a variable to indiciate if nau8825_xtalk_baktab has been initialized. BUG= chromium:769446 BUG=b:69087090 TEST=On caroline, (1) reboot (2) login (3) suspend/resume (4) plug a low impedance headphone (5) play youtube Change-Id: I33a4c880ce434d1c3901923b8bb4e033bf4cb467 Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/778501 Reviewed-by: John Hsu <kchsu0@nuvoton.corp-partner.google.com> Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org> [modify] https://crrev.com/5802908af5d6a7d93b2f0d0f03542e91dbe9ade2/sound/soc/codecs/nau8825.c [modify] https://crrev.com/5802908af5d6a7d93b2f0d0f03542e91dbe9ade2/sound/soc/codecs/nau8825.h
,
Nov 21 2017
+Grace and Bernie, Requesting a merge of CL in #56 to M62 and M63. This patch affects only the devices that use nau8825 codec: Caroline, Cave, Chell, Lars, Sentry, pbody, lili, asuka, kunimitsu. The CL is not big and should be low risk. We should definitely merge it to M63. Given the severity of the issue, I suggest merging this to M62 as well. 10150.0.0 picked up the fix. Builder hasn't generated the image. I'll test it tomorrow.
,
Nov 21 2017
62 has no more releases so it is too late there, for 63 I defer to Grace.
,
Nov 22 2017
John. When is NAU8825_IMPEDANCE_MEAS_IRQ triggered? nau8825_xtalk_work will be called when the driver gets this IRQ.
} else if (active_irq & NAU8825_IMPEDANCE_MEAS_IRQ) {
schedule_work(&nau8825->xtalk_work);
clear_irq = NAU8825_IMPEDANCE_MEAS_IRQ;
}
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/chromeos-3.18/sound/soc/codecs/nau8825.c#1719
,
Nov 22 2017
There are four states in the crosstalk measurement as follows: 1.Prepare state 2.HPR IMM state 3.HPL IMM state 4. IMM state The IRQ,IMPEDANCE_MEAS_IRQ, is happened in state 2 and 3. If the driver disables the crosstalk, it will never touches state 1. There is no chance to go into state 2 and later, and the interrupt will not be triggered.
,
Nov 22 2017
Here's a workaround for people who need it. (1) Reboot (2) Login (3) Plug in an earphone (high impedance headphone won't work). Earphone/phone volume will be normal after that. The point is don't do suspend/resume (closing lid) before plugging in an earphone.
,
Nov 22 2017
I verified the issue was fixed in 10151.0.0 on cave. Grace. We're requesting a merge to M63. Thanks.
,
Nov 22 2017
Verified on kevin & caroline with M64 build 10152.0.0
,
Nov 22 2017
+agnes from c#53, do we need to uprev firmware for the following ? glados family: caroline (pyeh), cave(agnescheng), chell(yungleem) kunimitsu family: asuka(stevenh), lars/lili(vwang), sentry(ssmadan) pbody is canceled, lili is zerg of lars that uses the same FW. I cc-ed to the device owner to drive the firmware update.
,
Nov 22 2017
,
Nov 22 2017
This bug requires manual review: We don't branch M64 until 2017-11-30. Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 22 2017
This bug requires manual review: We are only 12 days from stable. 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
,
Nov 22 2017
,
Nov 22 2017
+wuchengli@ can you confirm what is needed to fix this bug ? FW and patch in c#56? in c#64, sontis@ was able to see it is fixed in 10152 (was able to repo on older M64 binary) but did not change any FW.
,
Nov 22 2017
Able to reproduce this issue on M64 build 10149.0.0. And NOT able to reproduce the same on M64 build 10152.0.0. This issue is fixed and verified on ToT (M64).
,
Nov 22 2017
Wuchengli, does this fix also require fw uprev? I'm hesitant to approve fw merges less than 2 weeks to stable for M63. According to c#55, fw merge seems risky. Also, how risky is the kernel change? I'd like it to bake on tot for a while before merging to 63, as it's affecting multiple devices on 3.18
,
Nov 22 2017
Re #65, #70 and #72: No fw uprev is required for this issue. Upreving fw won't fix this. Only one kernel patch is required. Re #72: I believe the kernel change is low risk. Basically it adds a boolean variable check. The rest of the code change was just moving things around. Sure. Baking it on tot for several days is fine. Re #66: Sorry. I forgot to add Merge-Request-63 label.
,
Nov 28 2017
,
Nov 29 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/3a92f5686de1802bdf3c27a7510c007e1e6d16ad commit 3a92f5686de1802bdf3c27a7510c007e1e6d16ad Author: Wu-Cheng Li <wuchengli@google.com> Date: Wed Nov 29 08:20:09 2017 CHROMIUM: ASoC: nau8825: fix low volume of headphone. nau8825_xtalk_baktab is used to backup and restore registers in crosstalk. The values are 0 by default and initialized in backup. Suppose a device has not plugged a headphone after boot, which means backup has never been called. After suspend/resume, restore will be called and 0 will be written to the registers. Both nau8825_xtalk_baktab and resgisters will be 0. The headhpone volume will be stuck low. Add a variable to indiciate if nau8825_xtalk_baktab has been initialized. BUG= chromium:769446 BUG=b:69087090 TEST=On caroline, (1) reboot (2) login (3) suspend/resume (4) plug a low impedance headphone (5) play youtube Change-Id: I33a4c880ce434d1c3901923b8bb4e033bf4cb467 Signed-off-by: Wu-Cheng Li <wuchengli@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/778501 Reviewed-by: John Hsu <kchsu0@nuvoton.corp-partner.google.com> Reviewed-by: Cheng-Yi Chiang <cychiang@chromium.org> (cherry picked from commit 5802908af5d6a7d93b2f0d0f03542e91dbe9ade2) Reviewed-on: https://chromium-review.googlesource.com/795491 [modify] https://crrev.com/3a92f5686de1802bdf3c27a7510c007e1e6d16ad/sound/soc/codecs/nau8825.c [modify] https://crrev.com/3a92f5686de1802bdf3c27a7510c007e1e6d16ad/sound/soc/codecs/nau8825.h
,
Nov 29 2017
Merged to M63.
,
Jan 12 2018
,
Jan 22 2018
,
Jan 23 2018
,
Jul 2
Volume is still reduced on my HP chromebook 13 on the latest stable channel, well after this fix went into M63.
,
Jul 27
I also have this issue on my HP 13 G1. Audio returns to normal after unpause, then suddenly drops again after 5 or so seconds. FW is Google_Chell.7820.315.2 10718.58.0 (Official Build) beta-channel chell
,
Jul 27
I believe vodot7@gmail.com filed this feedback (link not accessible by the public) https://listnr.corp.google.com/report/85570281410 URL: https://www.netflix.com Product Version: 68.0.3440.70 beta User Agent: Mozilla/5.0 (X11; CrOS x86_64 10718.58.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.70 Safari/537.36 UI Language: en-US Description: Issue# 769446 Volume drops 5 or so seconds into playing netflix videos. Gets suddenly louder again after pausing for a minute, then unpausing, before before dropping way off after a few more seconds. Product Specific Data (whitelisted): CHROME VERSION: 68.0.3440.70 beta CHROMEOS_ARC_STATUS: enabled CHROMEOS_AUSERVER: <URL: 2> CHROMEOS_RELEASE_BOARD: chell-signed-mpkeys CHROMEOS_RELEASE_DESCRIPTION: 10718.58.0 (Official Build) beta-channel chell |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by dgreid@chromium.org
, Sep 27 2017Owner: cychiang@chromium.org
Status: Assigned (was: Untriaged)