Bug 556334

Summary: HDA/STAC9227: "Master" control's dB information incorrect for lowest volume setting. (i.e. -48dB actually cuts off audio completely, hence should be more like -inf dB)
Product: [Fedora] Fedora Reporter: D. Wagner <daw-redhatbugzilla>
Component: kernelAssignee: Jaroslav Kysela <jkysela>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 14CC: anton, dougsland, gansalmon, itamar, jonathan, kernel-maint, lkundrak, lpoetter, superquad.vortex2, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-16 18:28:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output from alsa-info.sh --no-upload
none
Output from amixer -c 0, at lowest audible volume setting (16%, -47.95db, according to g-v-c)
none
Output from amixer -c 0, at highest inaudible volume setting (15%, -49.65db, according to g-v-c) none

Description D. Wagner 2010-01-18 00:00:21 UTC
Description of problem:

The GNOME audio volume slider has non-linear effects on volume.  At 16% (-48.04 dB) or lower, there is absolutely no sound.  Bump it up to 17% (-46.45 dB), and I have sound at a middling loudish volume.  There is no way to get anything in between.  I can only stand to increase the volume a bit over 25% or so; beyond that, it gets too loud for me.  I normally keep the volume at about 20% or so. So the useful range of the audio volume slider is very narrow.  (And if I accidentally bump the slider to 100%, it *hurts* for the split second before I can yank my headphones of.)

I _think_ this is new to Fedora 12.  I _think_ that, before upgrading Fedora 11 to Fedora 12, I didn't have this effect: there was still a non-linearity and a threshold below which no sound at all could be heard, but I don't believe the useful range of the volume slider was so narrow.  But I wouldn't swear to that.

I'm not sure which component to associate this with.  Let me know if there's anything I should do to troubleshoot this.

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

pulseaudio-0.9.21-2.fc12.x86_64
kernel-2.6.31.9-174.fc12.x86_64
gnome-media-2.28.1-3.fc12.x86_64

How reproducible:

100%.

Additional info:

Smolt profile:

http://www.smolts.org/client/show/pub_1c2b468f-8810-4f87-9675-16433383ae79

Excerpt from lspci -vv showing my sound card:

00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
        Subsystem: Dell Device 01dd
        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: 64 bytes
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at dffdc000 (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: 0000000000000000  Data: 0000
        Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
                DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us
                        ExtTag- RBE- FLReset-
                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-
                LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency L0 <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
        Capabilities: [100] Virtual Channel <?>
        Capabilities: [130] Root Complex Link <?>
        Kernel driver in use: HDA Intel
        Kernel modules: snd-hda-intel

Comment 1 Lennart Poettering 2010-01-18 16:12:20 UTC
Sounds as if the dB information provided by your driver is not correct, at least for the lowest volume step.

PA extends the hw's volume granularity and range in sw. That only works if we know the actual attenuation factors of the hw for the volume steps. In your case the driver seems to provide incorrect information for the lowest volume step. i.e. it claims there is still signal while the signal is actually cut off.

Please attach the output "alsa-info.sh --no-upload" generates. Then, please use g-v-c to set the highest volume where you cannot hear anything and then the lowest volume where can hear something. Run "amixer -c 0" both times and attach the output here.

This should provide us with enough information to fix the drivers to report the correct information.

Comment 2 D. Wagner 2010-02-12 05:50:06 UTC
Created attachment 390440 [details]
Output from alsa-info.sh --no-upload

Comment 3 D. Wagner 2010-02-12 05:52:15 UTC
Created attachment 390441 [details]
Output from amixer -c  0, at lowest audible volume setting (16%, -47.95db, according to g-v-c)

Comment 4 D. Wagner 2010-02-12 05:52:51 UTC
Created attachment 390442 [details]
Output from amixer -c 0, at highest inaudible volume setting (15%, -49.65db, according to g-v-c)

Comment 5 D. Wagner 2010-02-12 05:53:30 UTC
Cool, thanks for your help!  I've attached the information requested.

Comment 6 Lennart Poettering 2010-02-12 15:17:25 UTC
Ok, seems the lowest position of the "Master" control which claims to be -48dB actually completely cuts off audio. The dB information in the driver needs to be fixed.

Reassigning to alsa.

Comment 7 D. Wagner 2010-02-12 18:47:59 UTC
Thanks for your help!  That sounds like it would account for the low end (i.e., why 0-15% completely cuts off the audio).

Is there anything that can be done on the high end?  (i.e., volume settings in the range 35-100% or so are unbearably loud, and 100% is actually pain-inducing, and occasionally there's an app that resets the volume to 100%)  Is that an alsa problem, too?  Should I file a separate bug/request-for-enhancement for that one?

Comment 8 Lennart Poettering 2010-02-16 14:49:34 UTC
I forwarded this to the kernel folks, not because parts of the volume range "feel" too loud or too faint to be useful, but simply because apparently some dB data exposed by the driver is incorrect. i.e. when audio is cut off, the mixer element should report something more near -inf dB instead of -48dB.

i.e. what matters is that the driver reports correct data. Whether the volume range is useful is a different question, and I guess what might be useful/useless to you might be different for other people, so I don't think we should do anything about that.

Comment 9 Raymond 2010-03-29 22:40:26 UTC
(In reply to comment #6)
> Ok, seems the lowest position of the "Master" control which claims to be -48dB
> actually completely cuts off audio. The dB information in the driver needs to
> be fixed.
> 
> Reassigning to alsa.    

PA software mixing 16 bits audio ,  perform software/atten and write 16 bits audio data to the sound card

-48dB is just shift the 16 bit audio right by 16 bits , all the digital data are already zero , those are noise if you can still hear any sound

Comment 10 Raymond 2010-03-30 02:15:42 UTC
(In reply to comment #1)
> Sounds as if the dB information provided by your driver is not correct, at
> least for the lowest volume step.
> 
> PA extends the hw's volume granularity and range in sw. That only works if we
> know the actual attenuation factors of the hw for the volume steps. In your
> case the driver seems to provide incorrect information for the lowest volume
> step. i.e. it claims there is still signal while the signal is actually cut
> off.
> 
>

+48dB is just shift the 16-bits audio left by 16 bits 
-48dB is just shift the 16-bits audio right by 16 bits

if PA write S16_LE to the sound card , the range of the software gain/atten can only be -48dB to +48dB


if PA write S32_LE to the sound card , the range of the software gain/atten can only be -96dB to +96dB

Comment 11 Raymond 2010-04-09 13:33:20 UTC
Sorry 

the DR range of 16 bits audio is 96dB

http://en.wikipedia.org/wiki/Dynamic_range

This mean that PA did not sum up all the amplifiers of the hda codec 

if you look at the stac9227 datasheet , 


High performance ΣΔ technology
• 105dB DAC SNR
• 90dB ADC SNR

Comment 12 Raymond 2010-05-21 07:49:16 UTC
may be related to this patch but no idea about what is too large scale in percentage represntation

http://git.alsa-project.org/?p=alsa-kernel.git;a=commitdiff;h=7c7767ebe2fa847c91a0dd5551ca422aba359473;hp=29fdbec2dcb1ce364812778271056aa9516ff3ed

STAC/IDT codecs have often too large volume scales such as -96dB,

and exposing this as is results in too large scale in percentage

representation.



This patch adds the check of the volume scale and halves the

volume range if it's too large automatically.

Comment 13 Bug Zapper 2010-11-04 00:42:05 UTC
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

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 prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 14 Bug Zapper 2011-06-02 16:50:37 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

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 prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 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 please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 15 D. Wagner 2011-06-21 06:36:44 UTC
This bug remains in Fedora 14, with the following RPMs:

kernel-2.6.35.13-92.fc14.x86_64
alsa-lib-1.0.24-1.fc14.x86_64
alsa-plugins-pulseaudio-1.0.22-1.fc13.x86_64
alsa-utils-1.0.23-3.fc14.x86_64
pulseaudio-0.9.21-7.fc14.x86_64
gnome-media-2.32.0-2.fc14.x86_64

Comment 16 Fedora End Of Life 2012-08-16 18:28:33 UTC
This message is a notice that Fedora 14 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 14. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained.  At this time, all open bugs with a Fedora 'version'
of '14' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this 
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen 
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we were unable to fix it before Fedora 14 reached 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 to click on 
"Clone This Bug" (top right of this page) and open it against that 
version of Fedora.

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.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping