Bug 43238

There is a same issue as mine, it is Ticket #677 (closed defect: elsewhere)
ALC889a 'Analog headphone' mute both line out and headphone
http://www.pulseaudio.org/ticket/677

I presume that when (In reply to comment #0)
> Created attachment 53843 [details]
> alsa info log
> 
> 1. boot to X-windows.
> 2. set the output connector to "Analog Headphones" in sound preference.
>    It mute output, there is no sound.

I know this might sound like a silly question, but I presume you *do* actually have headphones plugged in?

Assuming that you do have headphones plugged in, from your amixer output it looks like "Master" and "Headphones" elements are setup correctly:

Simple mixer control 'Master',0
  Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum
  Playback channels: Mono
  Limits: Playback 0 - 87
  Mono: Playback 79 [91%] [-6.00dB] [on]
Simple mixer control 'Headphone',0
  Capabilities: pswitch penum
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [on]
  Front Right: Playback [on]



However the "Front" element is turned off (as is intended):

Simple mixer control 'Front',0
  Capabilities: pvolume pswitch penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 87
  Mono:
  Front Left: Playback 0 [0%] [-65.25dB] [off]
  Front Right: Playback 0 [0%] [-65.25dB] [off]


I wonder if the underlying hardware is incorrectly plumbed in such a way as this element affects Headphones?



A simple test is to call:

amixer -c0 set Front 50% unmute

(verify this has worked via "amixer -c0 get Front" and compare to the above quoted text)



This should turn on the Front element. Do you suddenly hear sound through your headphones?

If so, then I'd suggest that this is a problem with the setup of the HDA driver for this particular hw/codec.

Hi Sir,
Yes, I can hear sound play through Headphone after I set the front in alsamixer unmute with the command: amixer -c0 set Front 50% unmute

You mean I should submit it to alsa to check it further. Is it? Thanks.

I can post to alsa-devel mailing list on your behalf if you like.

Please attach or post the official link to the file generated by the following script: http://www.alsa-project.org/alsa-info.sh

Many thanks.

(In reply to comment #4)
> Please attach or post the official link to the file generated by the following
> script: http://www.alsa-project.org/alsa-info.sh

Gah, sorry, I'm on autopilot! You've already supplied that. D'oh!

Hi Colin,
Would you please let me know if you need other info to check this issue?
Do you get update of this issue? Thanks.

(In reply to comment #6)
> Hi Colin,
> Would you please let me know if you need other info to check this issue?
> Do you get update of this issue? Thanks.

This is an alsa bug. "Front" element should not be used in the "Headphones" path, but it *is* affecting the sound.

We have kinda worked around this now in PulseAudio (sorry I didn't make the connection to this bug at the time):

commit 96369919e5100865e2469e42fb8f4b8e38e41aef
Author: David Henningsson <david.henningsson@canonical.com>
Date:   Mon Jul 4 10:12:17 2011 +0200

    alsa-mixer: Set "Front" control to 0 dB on headphone path
    
    I've seen more than one system where the volume control named
    "Front" is a part of audio path for headphones. This is somewhat
    of a compromise: While we don't merge it into the path, as that
    would be regressing machines where "Front" isn't a part of the
    audio path, it would still enable sound on these machines.
    
    BugLink: http://bugs.launchpad.net/bugs/804178
    Signed-off-by: David Henningsson <david.henningsson@canonical.com>


The "correct" fix is to ensure that Front does not affect Headphones at the alsa level.

Anyway, as this is not a kmix or KDE issue but rather a general audio issue, I think we should close this bug.

To the reporter, please try a recent PA version (i.e. 1.1) and feel free to open a bug on freedesktop.org against pulseaudio if you still have problems.

Oops I thought I was on a different bug tracker there, hence my earlier comment was a bit out of context. I still think this should be closed for now tho'. Due to the afore mentioned fix which is in PA 1.0 and 1.1.

Hi Colin,
I tested this issue with Pulseaudio 1.1, this issue occurs. Would you please help to check it again? Thanks.