This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 1002826 - ALSA/HDA: Conexant CX20588: Mic boost is shared for both external and internal mics (pulseaudio is confused) [NEEDINFO]
ALSA/HDA: Conexant CX20588: Mic boost is shared for both external and interna...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jaroslav Kysela
Fedora Extras Quality Assurance
:
: 1001321 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-30 01:37 EDT by Jan Pazdziora
Modified: 2014-03-10 10:42 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-10 10:42:39 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
jforbes: needinfo?


Attachments (Terms of Use)
Alsa Info for my hardware (31.64 KB, text/plain)
2013-09-11 18:22 EDT, Nathanael Noblet
no flags Details
Patch that allows pulse to control the channel... (484 bytes, patch)
2013-09-11 18:26 EDT, Nathanael Noblet
no flags Details | Diff
Firmware patch file (202 bytes, text/plain)
2013-10-09 16:35 EDT, Nathanael Noblet
no flags Details
Modprobe.d conf file (222 bytes, text/plain)
2013-10-09 16:36 EDT, Nathanael Noblet
no flags Details

  None (edit)
Description Jan Pazdziora 2013-08-30 01:37:24 EDT
Description of problem:

I can see microphone not working on my Acer Aspire One 722. I believe it is because the Mic Boost is set to zero upon boot and resume from suspend, rather than being set to 100 as I set it manually.

Version-Release number of selected component (if applicable):

# rpm -qf /usr/lib/systemd/system/alsa-state.service
alsa-utils-1.0.27.2-2.fc19.x86_64

How reproducible:

Pretty much deterministic.

Steps to Reproduce:
1. Start alsamixer, using F5 and F6 select the correct card and set the Mic Boost to 100.
2. Run alsactl store.
3. Copy /var/lib/alsa/asound.state aside.
4. Reboot.
5. Run alsamixer to check the Mic Boost setting.

Actual results:

It is down to 0. Running diff of /var/lib/alsa/asound.state and the backup made when the setting was to 100 sometimes shows a difference and sometimes it does not.

Restoring the /var/lib/alsa/asound.state from the backup and stopping and starting alsa-state service restores the value to 100.

Expected results:

If the value in /var/lib/alsa/asound.state was once set to 100 (via manual alsactl store), it should not go back to zero upon boot and resume from suspend, and it should be respected by the system.

Additional info:
Comment 1 Nathanael Noblet 2013-08-30 11:37:05 EDT
So actually I think this is a pulse bug. If you look, there is a /var/lib/gdm/.pulse/default.pa file. In there there are load modules, the first two are restoring card volumes. I *think* I commented out the first two lines and successfully had the mic boost volume stay up. I can't remember at this point as I've done so many things to get this working its hard to keep them straight. The issue for me is that if the volume is changed then micboost gets reset to 0.
Comment 2 Jan Pazdziora 2013-09-01 00:04:45 EDT
I don't have /var/lib/gdm/.pulse/default.pa sind I use lightdm, not gdm, and I do not have ~/.config/pulse/default.pa which is mentioned by default.pa man page. That leaves me with /etc/pulse/default.pa. When I commented out the lines

load-module module-device-restore
load-module module-stream-restore
load-module module-card-restore

(the first non-comment lines in that file), nothing changed -- after reboot, the mic boost as shown by alsamixer is still down to zero.
Comment 3 Nathanael Noblet 2013-09-11 18:22:29 EDT
Created attachment 796557 [details]
Alsa Info for my hardware
Comment 4 Nathanael Noblet 2013-09-11 18:26:06 EDT
Created attachment 796558 [details]
Patch that allows pulse to control the channel...

So I don't know if this is exactly the same bug. For me the boost channel was always being reset to 0. However even bigger than that was that when adjusting the microphone volume it didn't employ the boost channel so the mic was never sensitive enough to pick up anything of use.

In chatting with diwic in #pulseaudio he had me make the changes included in this attachment and restart pulseaudio. Now pulse uses the mic boost channel and my mic is useable... I emailed him personally and sent the results as he said he'd try to get it fixed in the kernel... not sure what's wrong with the kernel.

If pulse is properly using your mic boost channel but it always starts at 0... then we have two different problems. If your problem is similar to mine above then this may be stage one of that fix.
Comment 5 Jan Pazdziora 2013-09-11 19:57:39 EDT
I thought this bugzilla was about alsa. Is it about pulseaudio? What is the relationship WRT (re)setting the values?
Comment 6 Nathanael Noblet 2013-09-12 01:12:02 EDT
Here are my thoughts on this...

When I was trying to get this to work I followed a handful of attempted work arounds. The only one that seemed to keep the mic boost levels occurred when I *didn't* login to X. So I would set the level, reboot and it would stay. However once I logged into X (Gnome Shell for me) the boost level was back at 0. This leads me to believe that the problem was not with ALSA but with Pulseaudio. For me I found a pulse audio default.pa that restores the card values when I assume gdm/gnome start. My assumption was that was what was resetting the values. For me the mic boost level not being properly set is simply a symptom of my real problem. Pulseaudio doesn't *use* the mic boost channel when adjusting the input volume - requiring these odd work arounds (Set the volume in alsamixer and hope it never changes).

Now that I've adjusted the pulseaudio config to *use* the mic boost channel in its volume adjustments, I have two things fixed. 

#1 - The mic is useable since the mic boost level is used so my mic is sufficiently sensitive.

#2 - A nice side effect is that the mic boost level is being properly reset to its last value on reboot.

I'm 99% positive that at least on my hardware the boost level not being reset is a symptom of a different bug. Fixing that bug has resulted in this working for me properly.

Since you are reporting this against the exact same hardware, I suggest you apply the patch I've provided and reboot. Revert any other changes you may have made to any default.pa file. Once you do that pulseaudio will use that channel *and* restore its volume between reboots.
Comment 7 Nathanael Noblet 2013-09-12 01:12:27 EDT
*** Bug 1001321 has been marked as a duplicate of this bug. ***
Comment 8 Jaroslav Kysela 2013-09-12 03:05:05 EDT
Reassigning to the pulseaudio package. It seems, that alsa-lib is not the culprit of this behaviour.
Comment 9 Nathanael Noblet 2013-09-12 11:58:23 EDT
So I'm changing this back. In talking with David Henningsson diwic on IRC. He basically said that alsa needs to make some changes to fix the issue for pulse.

Here's what I wrote to alsa-devel after talking with him...

It seems that pulse doesn't expect a Mic Boost channel to be used with internal microphones. As such to fix this particular hardware, the driver would need to make the internal mic boost be labelled "Internal Mic Boost". Apparently the current label of Mic Boost is used for both external and internal mics and that is what is messing it up. He also said "but it seems possible to make the internal mic and the mic to take different routes so they will get one control each and then pulseaudio would be happy"

So this is a alsa issue still, though a temporary fix is to change what pulse expects...
Comment 10 Raymond 2013-09-13 11:34:33 EDT
Simple mixer control 'Input Source',0
  Capabilities: cenum
  Items: 'Mic' 'Internal Mic' 'Mic 1'
  Item0: 'Internal Mic'

if your notebook does not have two ext Mic jack, need to remove the non existing pin complex by hda-jack-retask since the codec only has two selectors 0x17 and node 0x18 have the boost volume control


Node 0x17 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
  Control: name="Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x04 0x04]
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0
  Connection: 4
     0x1a 0x1b 0x1d 0x1e*
Node 0x18 [Audio Selector] wcaps 0x30050d: Stereo Amp-Out
  Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0
  Amp-Out vals:  [0x00 0x00]
  Power states:  D0 D1 D2 D3 D3cold EPSS
  Power: setting=D0, actual=D0
  Connection: 4
     0x1a* 0x1b 0x1d 0x1e
Comment 11 Nathanael Noblet 2013-09-13 12:35:33 EDT
So I plugged a microphone into both audio jacks on this netbook. In the one marked with a microphone. Audio was only registered on the one marked by the microphone symbol.

Using hda-analyzer I tried to figure out which was which but nothing changed on it when I plugged anything in.
Comment 13 Josh Boyer 2013-09-18 16:25:18 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.11.1-200.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 14 Nathanael Noblet 2013-10-09 15:34:06 EDT
The bug is still present with kernel 3.11.3
Comment 15 Nathanael Noblet 2013-10-09 16:35:22 EDT
Created attachment 810165 [details]
Firmware patch file
Comment 16 Nathanael Noblet 2013-10-09 16:36:11 EDT
Created attachment 810166 [details]
Modprobe.d conf file
Comment 17 Justin M. Forbes 2014-01-03 17:05:55 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.12.6-200.fc19.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20.

If you experience different issues, please open a new bug report for those.
Comment 18 Justin M. Forbes 2014-03-10 10:42:39 EDT
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for more than 1 month and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 19, please feel free to reopen the bug and provide the additional information requested.

Note You need to log in before you can comment on or make changes to this bug.