Bug 1002826

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.

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.

Created attachment 796557 [details]
Alsa Info for my hardware

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.

I thought this bugzilla was about alsa. Is it about pulseaudio? What is the relationship WRT (re)setting the values?

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.

*** Bug 1001321 has been marked as a duplicate of this bug. ***

Reassigning to the pulseaudio package. It seems, that alsa-lib is not the culprit of this behaviour.

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...

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

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.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1074615/comments/17

*********** 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.

The bug is still present with kernel 3.11.3

Created attachment 810165 [details]
Firmware patch file

Created attachment 810166 [details]
Modprobe.d conf file

*********** 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.

*********** 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.