Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1047204 - Significantly higher audio capture sensitivity in the 3.12.5 kernel compared to the 3.11.9 kernel
Summary: Significantly higher audio capture sensitivity in the 3.12.5 kernel compared ...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: pulseaudio
Version: 19
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-29 22:42 UTC by mrj
Modified: 2015-02-17 19:48 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-17 19:48:15 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
FreeDesktop.org 73336 0 None None None Never
Linux Kernel 68211 0 None None None Never

Description mrj 2013-12-29 22:42:40 UTC
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

Comment 1 Michele Baldessari 2014-01-01 17:53:57 UTC
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?

Comment 2 mrj 2014-01-01 18:45:35 UTC
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

Comment 3 Michele Baldessari 2014-01-01 19:49:11 UTC
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/

Comment 4 mrj 2014-01-01 20:35:29 UTC
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.

Comment 5 Michele Baldessari 2014-01-01 20:52:05 UTC
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

Comment 6 mrj 2014-01-01 21:05:28 UTC
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.

Comment 7 mrj 2014-01-01 21:12:50 UTC
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.

Comment 8 mrj 2014-01-01 22:08:58 UTC
Given that my board is 6stack AD1988, the most suspicious patch is:

commit 36ad45309be840d652394cfb032b592b6a20a3dd
Author: Takashi Iwai <tiwai@suse.de>
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@suse.de>

Comment 9 Josh Boyer 2014-01-06 14:28:27 UTC
Have you reported this upstream at all?  If not, could you please do so?

Comment 10 mrj 2014-01-06 14:33:08 UTC
Reported as https://bugzilla.kernel.org/show_bug.cgi?id=68211

Comment 11 mrj 2014-01-06 23:01:38 UTC
Likely now a Pulseaudio bug:

https://bugs.freedesktop.org/show_bug.cgi?id=73336

Comment 12 Fedora End Of Life 2015-01-09 20:58:26 UTC
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.

Comment 13 Fedora End Of Life 2015-02-17 19:48:15 UTC
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.


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