Description of problem: Running kernel 3.11.9 and earlier, the most suitable pulseaudio volume to capture/record sound/audio from the line input of my on-board Intel HDA sound device was 38% (25000/65535). After upgrading to 3.12.5, that volume now strongly clips. The capture volume must be reduced by a factor of 3 to about 12% to produce an equivalent recorded waveform. This change occurs simply from booting into the different kernel. I don't know if this is a new bug, or the fixing of a long-standing bug. Version-Release number of selected component (if applicable): 3.12.5 How reproducible: Always. Steps to Reproduce: 1. Boot to F19 Kernel Version 3.11.9, run pavucontrol, switch to the Input Devices Tab, and find the volume at which the recording of a sound of a given volume just clips. 2. Boot to F19 Kernel Version 3.12.5 and do the same. 3. Note the different capture volumes required for the same input sound. Actual results: Much higher capture sensitivity under the 3.12 kernel. Expected results: A consistent capture sensitivity between kernels. Additional info: Another symptom was that the initial playback volume was 45% on 3.12.5 compared to the 100% at which it had long remained under earlier kernels. But once I increased this to 100% under 3.12.5 and rebooted, it again stayed at 100%. Here are the kernel module differences: lsmod | grep snd # 3.11.9 kernel snd_hda_codec_analog 94059 1 snd_hda_intel 44075 3 snd_hda_codec 179171 2 snd_hda_intel,snd_hda_codec_analog snd_hwdep 13554 1 snd_hda_codec snd_seq 60752 0 snd_seq_device 14136 1 snd_seq snd_pcm 98071 3 cx88_alsa,snd_hda_codec,snd_hda_intel snd_page_alloc 18268 2 snd_pcm,snd_hda_intel snd_timer 28698 2 snd_pcm,snd_seq snd 75313 19 cx88_alsa,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_hda_codec_analog soundcore 14491 1 snd lsmod | grep snd # 3.12.5 kernel snd_hda_codec_analog 14884 1 snd_hda_intel 48171 3 snd_hda_codec 183375 2 snd_hda_intel,snd_hda_codec_analog snd_hwdep 13554 1 snd_hda_codec snd_seq 60752 0 snd_seq_device 14136 1 snd_seq snd_pcm 98141 3 cx88_alsa,snd_hda_codec,snd_hda_intel snd_page_alloc 18268 2 snd_pcm,snd_hda_intel snd_timer 28698 2 snd_pcm,snd_seq snd 75313 17 cx88_alsa,snd_hwdep,snd_timer,snd_pcm,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_device,snd_hda_codec_analog soundcore 14491 1 snd
Not sure if this is by design or not. Between 3.11.9 and 3.12.5 we have: git lg v3.11.9..v3.12.5 sound/pci/hda/ |wc -l 92 Could be that one of these changed some default or activated some boost that missing before. I am not even sure this is a bug tbh. What's the 'lspci -vvvv' for this card?
The lspci -vvvv output under 3.12.5 is below. I'd be interested in seeing the 92 log lines, and the associated diffs. 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02) Subsystem: ASUSTeK Computer Inc. P5B Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 45 Region 0: Memory at febf8000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee0300c Data: 4122 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- Capabilities: [100 v1] Virtual Channel Caps: LPEVC=0 RefClk=100ns PATEntryBits=1 Arb: Fixed- WRR32- WRR64- WRR128- Ctrl: ArbSelect=Fixed Status: InProgress- VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01 Status: NegoPending- InProgress- VC1: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans- Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256- Ctrl: Enable- ID=0 ArbSelect=Fixed TC/VC=00 Status: NegoPending- InProgress- Capabilities: [130 v1] Root Complex Link Desc: PortNumber=0f ComponentID=00 EltType=Config Link0: Desc: TargetPort=00 TargetComponent=00 AssocRCRB- LinkType=MemMapped LinkValid+ Addr: 00000000fed1c000 Kernel driver in use: snd_hda_intel
Getting the changes list: git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git cd linux-stable git log --oneline v3.11.9..v3.12.5 sound/pci/hda/ or if the changes might be in the more generic sound layer: git log --oneline v3.11.9..v3.12.5 sound/
Thanks, I'll have a look at the changes. In the meantime, I've found two points of difference: 1. There is a "Line Boost" mixer control in the 3.12.5 kernel that isn't present in 3.11.9. However this is set to 0.00dB. 2. Setting the pulseaudio volume to maximum: pacmd 'set-source-volume alsa_input.pci-0000_00_1b.0.analog-stereo 65536' gives 100% capture volume on both kernels for both the amixer "default" device (pulseaudio?) and the "hw:0" device: > amixer get 'Capture',0 Simple mixer control 'Capture',0 Capabilities: cvolume cswitch cswitch-joined Capture channels: Front Left - Front Right Limits: Capture 0 - 65536 Front Left: Capture 65536 [100%] [on] Front Right: Capture 65536 [100%] [on] > amixer -c 0 get 'Capture',0 Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 54 [100%] [22.50dB] [on] Front Right: Capture 54 [100%] [22.50dB] [on] However when the volume is halved: pacmd 'set-source-volume alsa_input.pci-0000_00_1b.0.analog-stereo 32768' while the default mixer is the same 50% for both kernels > amixer get 'Capture',0 Simple mixer control 'Capture',0 Capabilities: cvolume cswitch cswitch-joined Capture channels: Front Left - Front Right Limits: Capture 0 - 65536 Front Left: Capture 32768 [50%] [on] Front Right: Capture 32768 [50%] [on] the 11.9 kernel has reduced the volume for the card mixer control to 76%, while it stays at 100% for 12.5: > amixer -c 0 get 'Capture',0 # kernel 3.11.9 Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 41 [76%] [3.00dB] [on] Front Right: Capture 41 [76%] [3.00dB] [on] > amixer -c 0 get 'Capture',0 # kernel 3.12.5 Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 54 Front Left: Capture 54 [100%] [22.50dB] [on] Front Right: Capture 54 [100%] [22.50dB] [on] To properly prevent clipping I'm not sure whether both are OK, or whether only 11.9 is correct because it alone changes the hw mix.
Likely one of these four commits brought in boost related controls to specific HW: 068fd3a ALSA: hda - Fix Internal Mic boost can't control with ALC283 cd5302c ALSA: hda - Limit internal mic boost for a few more Thinkpad machines a4a9e08 ALSA: hda - Fix internal mic boost on three Thinkpad machines 6fc16e5 ALSA: hda - Add a fixup for ASUS N76VZ
Additional information on the differences in pulseaudio to alsa volume mapping between the two kernel versions: The 3.12.5 kernel keeps the alsa volume at 100% for pulseaudio volumes from 65536 down to 20724. The 0-20724 pulseaudio range is then mapped to alsa volumes proportionally to the 0-65536 pulseaudio range under 3.11.9. e.g. A 76% alsa volume is set by a 32768 pulseaudio volume under 3.11.9, but a 10362 volume under 3.12.5. This explains the clipping I experienced in 3.12.5 at a 20000 pulseaudio capture volume.
I get the problem on a desktop machine using an AD1988 sound chip (ASUS P5B motherboard), so I don't think any of those patches apply. Rather than a boost problem, as described in Comment 6 there seems to be a problem with pulseaudio to alsa volume mapping under 3.12.5.
Given that my board is 6stack AD1988, the most suspicious patch is: commit 36ad45309be840d652394cfb032b592b6a20a3dd Author: Takashi Iwai <tiwai> Date: Thu Jul 4 16:34:20 2013 +0200 ALSA: hda - Remove static quirks for AD1988 codecs For removing static quirks for AD1988 variants, a new fixup defining the 6stack pinconfig has been added for the buggy BIOS. Other than that, we can cut off straightforwardly. Signed-off-by: Takashi Iwai <tiwai>
Have you reported this upstream at all? If not, could you please do so?
Reported as https://bugzilla.kernel.org/show_bug.cgi?id=68211
Likely now a Pulseaudio bug: https://bugs.freedesktop.org/show_bug.cgi?id=73336
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.