Hardware not showed in Gnome-Control-Center. - [M31EI Series, Realtek ALC861, Green Headphone Out, Rear]

We have done a few fixes since you filed this bug, that might have caused it to disappear. Is this still a problem for you?

Hmm, looking at this in more depth, it looks like the only output you have, is headphone output. No speakers, no line-outs. And since your headphone is not connected, there is currently no output available. Therefore, gnome does not show any output.

Does this make sense to you?

If I start "gnome-control-center sound" in unity - the tab "Hardware" is not shown and I'm not able to switch between
integrated speaker output and HDMI-Output.

IF I start the same command in gnome-shell I get it correct like in 11.10 (oneiric)
But since upgrading to precise

I have to use "sudo gnome-control-center sound" to change the output hardware to HDMI instead of integrated speaker

---

sudo gnome-control-center sound see screenshot

bug reproduced in Ubuntu 12.04

if I start "gnome-control-center sound" from my user - I get this message:

sound-cc-panel-WARNING **: The tree is empty => we have no devices so cannot set the active input

and Input tab is empty (see screenshot).

if I start "sudo gnome-control-center sound" - all fine (see screenshot)

Problem Persists.

David Henningsson (diwic), no buddy, it does not make anysense, this is a notebook, and I have the native sound speakers, the phone out, the mic in, and all of them work fine.

I have noticed you made the following change to /etc/modprobe.d/alsa-base.conf

options snd-hda-intel position_fix=1 model=3stack

Please remove this line and reboot. If the problem persists, please attach an alsa-info according to https://wiki.ubuntu.com/Audio/AlsaInfo

Thanks.

Post the pulse audio log

You have some application using the hda modem device 6, the module-udev-detect find out device 6 is used and the whole card is regarded as unavailable

I need help to do that...

https://wiki.ubuntu.com/PulseAudio/Log

1 - Thanks for helping me out.
2 - after runs the commands cited in the page, I was unable to 'locate' my sound device in user mode, and root, in gnome-control-center.

the diver create headphone jack kcontrol even when it does not have jack detect circuit

so it is always unavailable when pulseaudio server load module-switch-on-port-available

Node 0x0b [Pin Complex] wcaps 0x400581: Stereo
  Control: name="Headphone Jack", index=0, device=0
  Pincap 0x0000001f: OUT HP Detect Trigger ImpSense
  Pin Default 0x0121411f: [Jack] HP Out at Ext Rear
    Conn = 1/8, Color = Green
    DefAssociation = 0x1, Sequence = 0xf
    Misc = NO_PRESENCE
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=01, enabled=1
  Power states: D0 D1 D2 D3
  Power: setting=D0, actual=D0
  Connection: 1
     0x16

So yu have an idea, what can cause it or a fix? =)

I'm used to sugo gnome-control-center. lol

But my problem right now, might a solution to future problems =)

the speaker pin complex is missing and this codec does not has playback volume control

pcm playback volume is a soft volume plugin

your customised asound.rc have an unexpected char ( syntax) error too

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d2b31fc740ed9d5a5ec116964fb43c4358

take a look at alc861 datasheet , it does not has any hardware playback volume control

can you post the pulseaudio log after fixup the speaker pin ?

>>> 1 sink(s) available.
  * index: 0
 name: <alsa_output.pci-0000_00_1b.0.analog-stereo>
 driver: <module-alsa-card.c>
 flags: HARDWARE HW_MUTE_CTRL HW_VOLUME_CTRL DECIBEL_VOLUME LATENCY DYNAMIC_LATENCY
 state: SUSPENDED
 suspend cause: IDLE
 priority: 9959
 volume: 0: 100% 1: 100%
         0: 0.00 dB 1: 0.00 dB
         balance 0.00
 base volume: 100%
              0.00 dB
 volume steps: 65537
 muted: no
 current latency: 0.00 ms
 max request: 0 KiB
 max rewind: 0 KiB
 monitor source: 0
 sample spec: s16le 2ch 48000Hz
 channel map: front-left,front-right
              Stereo
 used by: 0
 linked by: 0
 configured latency: 0.00 ms; range is 0.50 .. 341.33 ms
 card: 0 <alsa_card.pci-0000_00_1b.0>
 module: 4
 properties:
  alsa.resolution_bits = "16"
  device.api = "alsa"
  device.class = "sound"
  alsa.class = "generic"
  alsa.subclass = "generic-mix"
  alsa.name = "ALC861 Analog"
  alsa.id = "ALC861 Analog"
  alsa.subdevice = "0"
  alsa.subdevice_name = "subdevice #0"
  alsa.device = "0"
  alsa.card = "0"
  alsa.card_name = "HDA Intel"
  alsa.long_card_name = "HDA Intel at 0xfe0fc000 irq 43"
  alsa.driver_name = "snd_hda_intel"
  device.bus_path = "pci-0000:00:1b.0"
  sysfs.path = "/devices/pci0000:00/0000:00:1b.0/sound/card0"
  device.bus = "pci"
  device.vendor.id = "8086"
  device.vendor.name = "Intel Corporation"
  device.product.name = "N10/ICH 7 Family High Definition Audio Controller"
  device.form_factor = "internal"
  device.string = "front:0"
  device.buffering.buffer_size = "65536"
  device.buffering.fragment_size = "32768"
  device.access_mode = "mmap+timer"
  device.profile.name = "analog-stereo"
  device.profile.description = "Analog Stereo"
  device.description = "Built-in Audio Analog Stereo"
  alsa.mixer_name = "Realtek ALC861"
  alsa.components = "HDA:10ec0861,15840000,00100300 HDA:10573055,10573055,00100700"
  module-udev-detect.discovered = "1"
  device.icon_name = "audio-card-pci"
 ports:
  analog-output-headphones: Headphones (priority 9000, available: no)
   properties:

 active port: <analog-output-headphones>

The purpose of this flag is unclear. If the problem is that some machines
have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.

In addition, this causes jack detection functionality to be flawed on
the M31EI, where there are two jacks without jack detection (which is
properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
jacks are instead being reported as being present but always unplugged.

BugLink: https://bugs.launchpad.net/bugs/939161
Signed-off-by: David Henningsson <email address hidden>
---
 sound/pci/hda/hda_auto_parser.c | 4 ----
 sound/pci/hda/hda_codec.h | 1 -
 sound/pci/hda/hda_jack.c | 5 ++---
 3 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c
index 4f7d2df..9acd5a9 100644
--- a/sound/pci/hda/hda_auto_parser.c
+++ b/sound/pci/hda/hda_auto_parser.c
@@ -141,7 +141,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec,
  memset(sequences_hp, 0, sizeof(sequences_hp));
  assoc_line_out = 0;

- codec->ignore_misc_bit = true;
  end_nid = codec->start_nid + codec->num_nodes;
  for (nid = codec->start_nid; nid < end_nid; nid++) {
   unsigned int wid_caps = get_wcaps(codec, nid);
@@ -157,9 +156,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec,
    continue;

   def_conf = snd_hda_codec_get_pincfg(codec, nid);
- if (!(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &
- AC_DEFCFG_MISC_NO_PRESENCE))
- codec->ignore_misc_bit = false;
   conn = get_defcfg_connect(def_conf);
   if (conn == AC_JACK_PORT_NONE)
    continue;
diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
index 8fd9f63..ee4ae8e 100644
--- a/sound/pci/hda/hda_codec.h
+++ b/sound/pci/hda/hda_codec.h
@@ -861,7 +861,6 @@ struct hda_codec {
  unsigned int no_sticky_stream:1; /* no sticky-PCM stream assignment */
  unsigned int pins_shutup:1; /* pins are shut up */
  unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
- unsigned int ignore_misc_bit:1; /* ignore MISC_NO_PRESENCE bit */
  unsigned int no_jack_detect:1; /* Machine has no jack-detection */
  unsigned int pcm_format_first:1; /* PCM format must be set first */
  unsigned int epss:1; /* supporting EPSS? */
diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c
index aaccc02..c9333c9 100644
--- a/sound/pci/hda/hda_jack.c
+++ b/sound/pci/hda/hda_jack.c
@@ -26,9 +26,8 @@ bool is_jack_detectable(struct hda_codec *codec, hda_nid_t nid)
   return false;
  if (!(snd_hda_query_pin_caps(codec, nid) & AC_PINCAP_PRES_DETECT))
   return false;
- if (!codec->ignore_misc_bit &&
- (get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &
- AC_DEFCFG_MISC_NO_PRESENCE))
+ if (get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &
+ AC_DEFCFG_MISC_NO_PRESENCE)
   return false;
  if (!(get_wcaps(codec, nid) & AC_WCAP_UNSOL_CAP))
   return false;
--
1.7.9.5

> the diver create headphone jack kcontrol even when it does not have jack detect circuit
> so it is always unavailable when pulseaudio server load module-switch-on-port-available

This is probably the root cause of the headphones not showing up. I'm sending a patch to Takashi for discussion.

At Fri, 7 Sep 2012 07:25:44 +0200,
David Henningsson wrote:
>
> The purpose of this flag is unclear. If the problem is that some machines
> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
>
> In addition, this causes jack detection functionality to be flawed on
> the M31EI, where there are two jacks without jack detection (which is
> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> jacks are instead being reported as being present but always unplugged.
>
> BugLink: https://bugs.launchpad.net/bugs/939161
> Signed-off-by: David Henningsson <email address hidden>

So this will fix this one case but will break some others certainly.
It's a difficult to judge, but more removal is better, so I'll take
this.

But I still wonder why PulseAudio cares the headphone jack state even
though this has only one output at all?

Takashi

> ---
> sound/pci/hda/hda_auto_parser.c | 4 ----
> sound/pci/hda/hda_codec.h | 1 -
> sound/pci/hda/hda_jack.c | 5 ++---
> 3 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/sound/pci/hda/hda_auto_parser.c b/sound/pci/hda/hda_auto_parser.c
> index 4f7d2df..9acd5a9 100644
> --- a/sound/pci/hda/hda_auto_parser.c
> +++ b/sound/pci/hda/hda_auto_parser.c
> @@ -141,7 +141,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec,
> memset(sequences_hp, 0, sizeof(sequences_hp));
> assoc_line_out = 0;
>
> - codec->ignore_misc_bit = true;
> end_nid = codec->start_nid + codec->num_nodes;
> for (nid = codec->start_nid; nid < end_nid; nid++) {
> unsigned int wid_caps = get_wcaps(codec, nid);
> @@ -157,9 +156,6 @@ int snd_hda_parse_pin_defcfg(struct hda_codec *codec,
> continue;
>
> def_conf = snd_hda_codec_get_pincfg(codec, nid);
> - if (!(get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &
> - AC_DEFCFG_MISC_NO_PRESENCE))
> - codec->ignore_misc_bit = false;
> conn = get_defcfg_connect(def_conf);
> if (conn == AC_JACK_PORT_NONE)
> continue;
> diff --git a/sound/pci/hda/hda_codec.h b/sound/pci/hda/hda_codec.h
> index 8fd9f63..ee4ae8e 100644
> --- a/sound/pci/hda/hda_codec.h
> +++ b/sound/pci/hda/hda_codec.h
> @@ -861,7 +861,6 @@ struct hda_codec {
> unsigned int no_sticky_stream:1; /* no sticky-PCM stream assignment */
> unsigned int pins_shutup:1; /* pins are shut up */
> unsigned int no_trigger_sense:1; /* don't trigger at pin-sensing */
> - unsigned int ignore_misc_bit:1; /* ignore MISC_NO_PRESENCE bit */
> unsigned int no_jack_detect:1; /* Machine has no jack-detection */
> unsigned int pcm_format_first:1; /* PCM format must be set first */
> unsigned int epss:1; /* supporting EPSS? */
> diff --git a/sound/pci/hda/hda_jack.c b/sound/pci/hda/hda_jack.c
> index aaccc02..c9333c9 100644
> --- a/sound/pci/hda/hda_jack.c
> +++ b/sound/pci/hda/hda_jack.c
> @@ -26,9 +26,8 @@ bool is_jack_detectable(struct hda_codec *codec, hda_nid_t nid)
> return false;
> if (!(snd_hda_query_pin_caps(codec, nid) & AC_PINCAP_PRES_DETECT))
> return false;
> - if (!codec->ignore_misc_bit &&
> - (get_defcfg_misc(snd_hda_codec_get_pincfg(codec, nid)) &
> - AC_DEFCFG_MISC_NO_PRESENCE))
> + if ...

On 09/07/2012 12:01 PM, Takashi Iwai wrote:
> At Fri, 7 Sep 2012 07:25:44 +0200,
> David Henningsson wrote:
>>
>> The purpose of this flag is unclear. If the problem is that some machines
>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
>>
>> In addition, this causes jack detection functionality to be flawed on
>> the M31EI, where there are two jacks without jack detection (which is
>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
>> jacks are instead being reported as being present but always unplugged.
>>
>> BugLink: https://bugs.launchpad.net/bugs/939161
>> Signed-off-by: David Henningsson <email address hidden>
>
> So this will fix this one case but will break some others certainly.
> It's a difficult to judge, but more removal is better, so I'll take
> this.

Ok. Do you have a sense for how many machines that will regress due to
this patch? If it is common to set all pins to the wrong value, maybe
its the M31EI that is the exception.

> But I still wonder why PulseAudio cares the headphone jack state even
> though this has only one output at all?

When seeing the system as a whole, there can be other outputs on other
cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
simpler for the user if PulseAudio does not also show the unplugged 3.5
mm jack.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

At Fri, 07 Sep 2012 13:26:35 +0200,
David Henningsson wrote:
>
> On 09/07/2012 12:01 PM, Takashi Iwai wrote:
> > At Fri, 7 Sep 2012 07:25:44 +0200,
> > David Henningsson wrote:
> >>
> >> The purpose of this flag is unclear. If the problem is that some machines
> >> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
> >>
> >> In addition, this causes jack detection functionality to be flawed on
> >> the M31EI, where there are two jacks without jack detection (which is
> >> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> >> jacks are instead being reported as being present but always unplugged.
> >>
> >> BugLink: https://bugs.launchpad.net/bugs/939161
> >> Signed-off-by: David Henningsson <email address hidden>
> >
> > So this will fix this one case but will break some others certainly.
> > It's a difficult to judge, but more removal is better, so I'll take
> > this.
>
> Ok. Do you have a sense for how many machines that will regress due to
> this patch? If it is common to set all pins to the wrong value, maybe
> its the M31EI that is the exception.

Maybe a few Acer and ASUS ones with old codecs.
Possibly some desktops with unknown mobos might hit, but that's not
what I do care so much for now.

> > But I still wonder why PulseAudio cares the headphone jack state even
> > though this has only one output at all?
>
> When seeing the system as a whole, there can be other outputs on other
> cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
> simpler for the user if PulseAudio does not also show the unplugged 3.5
> mm jack.

OK, but masking it out unconditionally isn't always nice. There are
always corner cases...

Takashi

On 09/07/2012 01:59 PM, Takashi Iwai wrote:
> At Fri, 07 Sep 2012 13:26:35 +0200,
> David Henningsson wrote:
>>
>> On 09/07/2012 12:01 PM, Takashi Iwai wrote:
>>> At Fri, 7 Sep 2012 07:25:44 +0200,
>>> David Henningsson wrote:
>>>>
>>>> The purpose of this flag is unclear. If the problem is that some machines
>>>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
>>>>
>>>> In addition, this causes jack detection functionality to be flawed on
>>>> the M31EI, where there are two jacks without jack detection (which is
>>>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
>>>> jacks are instead being reported as being present but always unplugged.
>>>>
>>>> BugLink: https://bugs.launchpad.net/bugs/939161
>>>> Signed-off-by: David Henningsson <email address hidden>
>>>
>>> So this will fix this one case but will break some others certainly.
>>> It's a difficult to judge, but more removal is better, so I'll take
>>> this.
>>
>> Ok. Do you have a sense for how many machines that will regress due to
>> this patch? If it is common to set all pins to the wrong value, maybe
>> its the M31EI that is the exception.
>
> Maybe a few Acer and ASUS ones with old codecs.
> Possibly some desktops with unknown mobos might hit, but that's not
> what I do care so much for now.

Hrm, ok. I still don't like the idea of regressing machines...maybe this
patch needs further research.

>>> But I still wonder why PulseAudio cares the headphone jack state even
>>> though this has only one output at all?
>>
>> When seeing the system as a whole, there can be other outputs on other
>> cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
>> simpler for the user if PulseAudio does not also show the unplugged 3.5
>> mm jack.
>
> OK, but masking it out unconditionally isn't always nice. There are
> always corner cases...

Not sure what corner case you mean here, but if you like, you can
configure this behaviour in
/usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf,
causing the jack detection to be ignored if you prefer. And you can
quirk a specific machine to use another .conf file based on udev rules.

Or is the corner case that ALSA don't give the correct jack detection
value? If so I prefer it to be fixed in ALSA ;-)

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

Seriously... Sorry for write this out...
But I don't need jack detection... I don't need nothing else than a piece of code that fix this bug, I can even backup it and be the official redistrbutor of this. =)
In my Ubuntu 11.10 all worked perfectly, 12.04 no... I'm already thinking about upgrade to 12.10 (as I always do, testing the alphas and betas) but i'm affraid that no workaround will be available...

I am not so sure if this problem is really intricates, as I told ya, this thing works fine with sudo, but not with the random users. Maybe a 'local solution' a workaround for type X and Y of some motherboards? An answer on askubuntu? lol

At Fri, 07 Sep 2012 14:17:58 +0200,
David Henningsson wrote:
>
> On 09/07/2012 01:59 PM, Takashi Iwai wrote:
> > At Fri, 07 Sep 2012 13:26:35 +0200,
> > David Henningsson wrote:
> >>
> >> On 09/07/2012 12:01 PM, Takashi Iwai wrote:
> >>> At Fri, 7 Sep 2012 07:25:44 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> The purpose of this flag is unclear. If the problem is that some machines
> >>>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
> >>>>
> >>>> In addition, this causes jack detection functionality to be flawed on
> >>>> the M31EI, where there are two jacks without jack detection (which is
> >>>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> >>>> jacks are instead being reported as being present but always unplugged.
> >>>>
> >>>> BugLink: https://bugs.launchpad.net/bugs/939161
> >>>> Signed-off-by: David Henningsson <email address hidden>
> >>>
> >>> So this will fix this one case but will break some others certainly.
> >>> It's a difficult to judge, but more removal is better, so I'll take
> >>> this.
> >>
> >> Ok. Do you have a sense for how many machines that will regress due to
> >> this patch? If it is common to set all pins to the wrong value, maybe
> >> its the M31EI that is the exception.
> >
> > Maybe a few Acer and ASUS ones with old codecs.
> > Possibly some desktops with unknown mobos might hit, but that's not
> > what I do care so much for now.
>
> Hrm, ok. I still don't like the idea of regressing machines...maybe this
> patch needs further research.

Well, let's see. I guess a problem will pop up anyway a few kernel
release later. People with such machines rarely follow the kernel
development soonish.

> >>> But I still wonder why PulseAudio cares the headphone jack state even
> >>> though this has only one output at all?
> >>
> >> When seeing the system as a whole, there can be other outputs on other
> >> cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
> >> simpler for the user if PulseAudio does not also show the unplugged 3.5
> >> mm jack.
> >
> > OK, but masking it out unconditionally isn't always nice. There are
> > always corner cases...
>
> Not sure what corner case you mean here, but if you like, you can
> configure this behaviour in
> /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf,
> causing the jack detection to be ignored if you prefer. And you can
> quirk a specific machine to use another .conf file based on udev rules.
>
> Or is the corner case that ALSA don't give the correct jack detection
> value? If so I prefer it to be fixed in ALSA ;-)

Well, I can think of different cases: BIOS is broken, my hardware is
broken and the driver is broken. In such a case, an easier test would
be to disable this jack auto-things in PA, rather than fiddling with
the pin config and reconfigure the driver, so I hoped there might be
an intuitive and easy way to do that.

Takashi

On 09/07/2012 02:36 PM, Takashi Iwai wrote:
> At Fri, 07 Sep 2012 14:17:58 +0200,
> David Henningsson wrote:
>>
>> On 09/07/2012 01:59 PM, Takashi Iwai wrote:
>>> At Fri, 07 Sep 2012 13:26:35 +0200,
>>> David Henningsson wrote:
>>>>
>>>> On 09/07/2012 12:01 PM, Takashi Iwai wrote:
>>>>> At Fri, 7 Sep 2012 07:25:44 +0200,
>>>>> David Henningsson wrote:
>>>>>>
>>>>>> The purpose of this flag is unclear. If the problem is that some machines
>>>>>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
>>>>>>
>>>>>> In addition, this causes jack detection functionality to be flawed on
>>>>>> the M31EI, where there are two jacks without jack detection (which is
>>>>>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
>>>>>> jacks are instead being reported as being present but always unplugged.
>>>>>>
>>>>>> BugLink: https://bugs.launchpad.net/bugs/939161
>>>>>> Signed-off-by: David Henningsson <email address hidden>
>>>>>
>>>>> So this will fix this one case but will break some others certainly.
>>>>> It's a difficult to judge, but more removal is better, so I'll take
>>>>> this.
>>>>
>>>> Ok. Do you have a sense for how many machines that will regress due to
>>>> this patch? If it is common to set all pins to the wrong value, maybe
>>>> its the M31EI that is the exception.
>>>
>>> Maybe a few Acer and ASUS ones with old codecs.
>>> Possibly some desktops with unknown mobos might hit, but that's not
>>> what I do care so much for now.
>>
>> Hrm, ok. I still don't like the idea of regressing machines...maybe this
>> patch needs further research.
>
> Well, let's see. I guess a problem will pop up anyway a few kernel
> release later. People with such machines rarely follow the kernel
> development soonish.

No, they complain on Launchpad, three months after the release or so,
about how we could be stupid enough to break their systems ;-)

>>>>> But I still wonder why PulseAudio cares the headphone jack state even
>>>>> though this has only one output at all?
>>>>
>>>> When seeing the system as a whole, there can be other outputs on other
>>>> cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
>>>> simpler for the user if PulseAudio does not also show the unplugged 3.5
>>>> mm jack.
>>>
>>> OK, but masking it out unconditionally isn't always nice. There are
>>> always corner cases...
>>
>> Not sure what corner case you mean here, but if you like, you can
>> configure this behaviour in
>> /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf,
>> causing the jack detection to be ignored if you prefer. And you can
>> quirk a specific machine to use another .conf file based on udev rules.
>>
>> Or is the corner case that ALSA don't give the correct jack detection
>> value? If so I prefer it to be fixed in ALSA ;-)
>
> Well, I can think of different cases: BIOS is broken, my hardware is
> broken and the driver is broken. In such a case, an easier test would
> be to disable this jack auto-things in PA, rather than fiddling with
> the pin config and reconfigure the driver, so I hoped there might be
> an intuitive and easy way to do that.

Naah, in all those cases it is AL...

> I don't need nothing else than a piece of code that fix this bug

Edit /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf and comment out the Jack detect session, so it looks like this:

; [Jack Headphone]
; required-any = any

That turns off jack detection for your machine.
Restart pulseaudio afterwards (pulseaudio -k ).

At Fri, 07 Sep 2012 14:47:16 +0200,
David Henningsson wrote:
>
> On 09/07/2012 02:36 PM, Takashi Iwai wrote:
> > At Fri, 07 Sep 2012 14:17:58 +0200,
> > David Henningsson wrote:
> >>
> >> On 09/07/2012 01:59 PM, Takashi Iwai wrote:
> >>> At Fri, 07 Sep 2012 13:26:35 +0200,
> >>> David Henningsson wrote:
> >>>>
> >>>> On 09/07/2012 12:01 PM, Takashi Iwai wrote:
> >>>>> At Fri, 7 Sep 2012 07:25:44 +0200,
> >>>>> David Henningsson wrote:
> >>>>>>
> >>>>>> The purpose of this flag is unclear. If the problem is that some machines
> >>>>>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
> >>>>>>
> >>>>>> In addition, this causes jack detection functionality to be flawed on
> >>>>>> the M31EI, where there are two jacks without jack detection (which is
> >>>>>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> >>>>>> jacks are instead being reported as being present but always unplugged.
> >>>>>>
> >>>>>> BugLink: https://bugs.launchpad.net/bugs/939161
> >>>>>> Signed-off-by: David Henningsson <email address hidden>
> >>>>>
> >>>>> So this will fix this one case but will break some others certainly.
> >>>>> It's a difficult to judge, but more removal is better, so I'll take
> >>>>> this.
> >>>>
> >>>> Ok. Do you have a sense for how many machines that will regress due to
> >>>> this patch? If it is common to set all pins to the wrong value, maybe
> >>>> its the M31EI that is the exception.
> >>>
> >>> Maybe a few Acer and ASUS ones with old codecs.
> >>> Possibly some desktops with unknown mobos might hit, but that's not
> >>> what I do care so much for now.
> >>
> >> Hrm, ok. I still don't like the idea of regressing machines...maybe this
> >> patch needs further research.
> >
> > Well, let's see. I guess a problem will pop up anyway a few kernel
> > release later. People with such machines rarely follow the kernel
> > development soonish.
>
> No, they complain on Launchpad, three months after the release or so,
> about how we could be stupid enough to break their systems ;-)
>
> >>>>> But I still wonder why PulseAudio cares the headphone jack state even
> >>>>> though this has only one output at all?
> >>>>
> >>>> When seeing the system as a whole, there can be other outputs on other
> >>>> cards - HDMI, USB etc. If somebody e g plugs a USB headset in it will be
> >>>> simpler for the user if PulseAudio does not also show the unplugged 3.5
> >>>> mm jack.
> >>>
> >>> OK, but masking it out unconditionally isn't always nice. There are
> >>> always corner cases...
> >>
> >> Not sure what corner case you mean here, but if you like, you can
> >> configure this behaviour in
> >> /usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf,
> >> causing the jack detection to be ignored if you prefer. And you can
> >> quirk a specific machine to use another .conf file based on udev rules.
> >>
> >> Or is the corner case that ALSA don't give the correct jack detection
> >> value? If so I prefer it to be fixed in ALSA ;-)
> >
> > Well, I can think of different cases: BIOS is broken, my hardware is
> > broken and the driver is broken. In such a case, an easier test would
> > be to disable ...

On 09/07/2012 03:09 PM, Takashi Iwai wrote:
> At Fri, 07 Sep 2012 14:47:16 +0200,
> David Henningsson wrote:
>>
>> On 09/07/2012 02:36 PM, Takashi Iwai wrote:
>>> At Fri, 07 Sep 2012 14:17:58 +0200,
>>> David Henningsson wrote:
>>>> Or is the corner case that ALSA don't give the correct jack detection
>>>> value? If so I prefer it to be fixed in ALSA ;-)
>>>
>>> Well, I can think of different cases: BIOS is broken, my hardware is
>>> broken and the driver is broken. In such a case, an easier test would
>>> be to disable this jack auto-things in PA, rather than fiddling with
>>> the pin config and reconfigure the driver, so I hoped there might be
>>> an intuitive and easy way to do that.
>>
>> Naah, in all those cases it is ALSA's responsibility to give a correct
>> answer up to PA - and as such, also to provide an "intuitive and easy
>> way" to disable jack detection if you feel there is a need. IMO.
>
> Adjusting a user-space things is much safer than adjusting something
> in kernel. The former doesn't need a root privilege (if it's done
> right). Thus for debugging purpose, fiddling with PA at first would
> be more comfortable than digging with the driver code and BIOS
> setups.
>
> Of course, a permanent fix is a different story. I'm talking about
> the debuggability.
>
>> That said, it's not super difficult to comment out a few lines in
>> /usr/share/pulseaudio/alsa-mixer/paths/*.conf, and also, most mixer UIs
>> (e g pavucontrol) still allows you to route audio to an unavailable port.
>
> Yes, but some guidelines would be nice to have somewhere explicitly...
> Also this can be done without being root somehow, right?

Hmm, I'm afraid it's not so easy to turn off PulseAudio's jack detection
without being root. Maybe it's possible using some .asoundrc magic?

Btw - I've never seen this as a practical problem myself. For debugging
jack sense problems, I typically triage with
  1) "amixer contents" (PulseAudio or kernel space?)
  2) "sudo hda-jack-sense-test" (hardware or driver?)

Asking people to run a sudo command has never been a problem. (but maybe
that's a problem in itself - i e that people are not security aware...)

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

At Fri, 07 Sep 2012 16:28:19 +0200,
David Henningsson wrote:
>
> On 09/07/2012 03:09 PM, Takashi Iwai wrote:
> > At Fri, 07 Sep 2012 14:47:16 +0200,
> > David Henningsson wrote:
> >>
> >> On 09/07/2012 02:36 PM, Takashi Iwai wrote:
> >>> At Fri, 07 Sep 2012 14:17:58 +0200,
> >>> David Henningsson wrote:
> >>>> Or is the corner case that ALSA don't give the correct jack detection
> >>>> value? If so I prefer it to be fixed in ALSA ;-)
> >>>
> >>> Well, I can think of different cases: BIOS is broken, my hardware is
> >>> broken and the driver is broken. In such a case, an easier test would
> >>> be to disable this jack auto-things in PA, rather than fiddling with
> >>> the pin config and reconfigure the driver, so I hoped there might be
> >>> an intuitive and easy way to do that.
> >>
> >> Naah, in all those cases it is ALSA's responsibility to give a correct
> >> answer up to PA - and as such, also to provide an "intuitive and easy
> >> way" to disable jack detection if you feel there is a need. IMO.
> >
> > Adjusting a user-space things is much safer than adjusting something
> > in kernel. The former doesn't need a root privilege (if it's done
> > right). Thus for debugging purpose, fiddling with PA at first would
> > be more comfortable than digging with the driver code and BIOS
> > setups.
> >
> > Of course, a permanent fix is a different story. I'm talking about
> > the debuggability.
> >
> >> That said, it's not super difficult to comment out a few lines in
> >> /usr/share/pulseaudio/alsa-mixer/paths/*.conf, and also, most mixer UIs
> >> (e g pavucontrol) still allows you to route audio to an unavailable port.
> >
> > Yes, but some guidelines would be nice to have somewhere explicitly...
> > Also this can be done without being root somehow, right?
>
> Hmm, I'm afraid it's not so easy to turn off PulseAudio's jack detection
> without being root. Maybe it's possible using some .asoundrc magic?

That's bad. asoundrc is equally cryptic like udev rules :)

Honestly, can't the whole /usr/share/pulseaudio/* files be specified
via an environment variable, or automatically looking at
~/.pulse/alsa-mixer/paths/* or such?

> Btw - I've never seen this as a practical problem myself. For debugging
> jack sense problems, I typically triage with
> 1) "amixer contents" (PulseAudio or kernel space?)
> 2) "sudo hda-jack-sense-test" (hardware or driver?)
>
> Asking people to run a sudo command has never been a problem. (but maybe
> that's a problem in itself - i e that people are not security aware...)

Indeed.

Anyway, it's way offtopic now :)

Takashi

Dears Sirs...

$filepath = "/usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf"

Mine $filepath file, already is like described:

; [Jack Headphone]
; required-any = any

And problem persists. =)

I know that I am being a pain in the 'leg' for ya... But I'd like to make things work... And it sounds huge above my average knowloedge, otherway I would be happy to help.

Sorry... I've made a mistake... The hardware is present now... The "Analog Output", but no Input present.

Easy... Sorry again...

just change the line in the other file... lol

Sorry about that...

/usr/share/pulseaudio/alsa-mixer/paths/analog-input-mic.conf

If I could I would buy for ya something to drink together and celebrate the rebirth of my Analog sound device in the commoners profiles. =)

On Fri, 2012-09-07 at 16:32 +0200, Takashi Iwai wrote:
> > Hmm, I'm afraid it's not so easy to turn off PulseAudio's jack detection
> > without being root. Maybe it's possible using some .asoundrc magic?
>
> That's bad. asoundrc is equally cryptic like udev rules :)
>
> Honestly, can't the whole /usr/share/pulseaudio/* files be specified
> via an environment variable, or automatically looking at
> ~/.pulse/alsa-mixer/paths/* or such?

FWIW, I'm in favor of looking at the home directory...

--
Tanu

2012-9-7 下午1:26 於 "David Henningsson" <email address hidden> 寫道：
>
> The purpose of this flag is unclear. If the problem is that some machines
> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
>
> In addition, this causes jack detection functionality to be flawed on
> the M31EI, where there are two jacks without jack detection (which is
> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> jacks are instead being reported as being present but always unplugged.
>
> BugLink: https://bugs.launchpad.net/bugs/939161

do you mean the commit does not fix the bug?

ALSA: hda - add support for Uniwill ECS M31EI notebook

This hardware requires same fixup for the node 0x0f like Asus A6Rp.
More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d2b31fc740ed9d5a5ec116964fb43c4358

the real cases are those desktop which does not use hda front audio panel ,
they just loss the auto mute since there is no jack detect circuit but they
can still hear sound from the headphone at anytime

do pulseaudio need a phantom port for the front panel headphone and mic
without jack detection ?

At Sat, 8 Sep 2012 09:10:14 +0800,
Raymond Yau wrote:
>
> 2012-9-7 下午1:26 於 "David Henningsson" <email address hidden> 寫道：
> >
> > The purpose of this flag is unclear. If the problem is that some machines
> > have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
> >
> > In addition, this causes jack detection functionality to be flawed on
> > the M31EI, where there are two jacks without jack detection (which is
> > properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
> > jacks are instead being reported as being present but always unplugged.
> >
> > BugLink: https://bugs.launchpad.net/bugs/939161
>
> do you mean the commit does not fix the bug?
>
> ALSA: hda - add support for Uniwill ECS M31EI notebook
>
> This hardware requires same fixup for the node 0x0f like Asus A6Rp.
> More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
>
> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d2b31fc740ed9d5a5ec116964fb43c4358
>
> the real cases are those desktop which does not use hda front audio panel ,
> they just loss the auto mute since there is no jack detect circuit but they
> can still hear sound from the headphone at anytime
>
> do pulseaudio need a phantom port for the front panel headphone and mic
> without jack detection ?

Actually this is one good point.
The jack detection isn't always reliably on such old machines, and
BIOS cannot know, too. That is, it has to be adjusted by user
manually, whether the jack detection is enabled or not.

So far, we solved this by providing "Auto-Mute Mode" mixer switch.
But the jack detection controls don't follow this yet. Maybe we can
set such a jack control as inactive state when the jack detection is
disabled.

(And this reminds me that we can cut off "Phantom" name hack by
 following the same rule -- just set the control inactive when it has
 no real detection. But it still appears in control list.)

Takashi

> >
> > the real cases are those desktop which does not use hda front audio
panel ,
> > they just loss the auto mute since there is no jack detect circuit but
they
> > can still hear sound from the headphone at anytime
> >
> > do pulseaudio need a phantom port for the front panel headphone and mic
> > without jack detection ?
>
> Actually this is one good point.
> The jack detection isn't always reliably on such old machines, and
> BIOS cannot know, too. That is, it has to be adjusted by user
> manually, whether the jack detection is enabled or not.
>
> So far, we solved this by providing "Auto-Mute Mode" mixer switch.
> But the jack detection controls don't follow this yet. Maybe we can
> set such a jack control as inactive state when the jack detection is
> disabled.
>
> (And this reminds me that we can cut off "Phantom" name hack by
> following the same rule -- just set the control inactive when it has
> no real detection. But it still appears in control list.)
>
>

The other case is the bios of some computers with alc880 codec have pin
defaults 0x00000000
for some pin complexes

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1015232

hda jack detect need pin fixup

Pin Default 0x00000000: [Jack] Line Out at Ext N/A
    Conn = Unknown, Color = Unknown
    DefAssociation = 0x0, Sequence = 0x0

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=67b6ec3196da235317ff1b9474f17379b78f3294

On 09/09/2012 09:50 AM, Takashi Iwai wrote:
> At Sat, 8 Sep 2012 09:10:14 +0800,
> Raymond Yau wrote:
>>
>> 2012-9-7 下午1:26 於 "David Henningsson" <email address hidden> 寫道：
>>>
>>> The purpose of this flag is unclear. If the problem is that some machines
>>> have broken misc/NO_PRESENCE bits, they should be fixed by pin fixups.
>>>
>>> In addition, this causes jack detection functionality to be flawed on
>>> the M31EI, where there are two jacks without jack detection (which is
>>> properly marked as NO_PRESENCE), but due to ignore_misc_bit, these
>>> jacks are instead being reported as being present but always unplugged.
>>>
>>> BugLink:
>>
>> do you mean the commit does not fix the bug?
>>
>> ALSA: hda - add support for Uniwill ECS M31EI notebook
>>
>> This hardware requires same fixup for the node 0x0f like Asus A6Rp.
>> More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
>>
>> http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d2b31fc740ed9d5a5ec116964fb43c4358

The PCI SSIDs are different, so I don't think that commit will affect
the bug I was trying to fix.

>> the real cases are those desktop which does not use hda front audio panel ,
>> they just loss the auto mute since there is no jack detect circuit but they
>> can still hear sound from the headphone at anytime

If there is no HDA front panel connected to the motherboard physically,
the codec should report front headphone and mic as unconnected.

If there is an AC'97 front panel connected, the BIOS should set
NO_PRESENCE in the misc bit.

If BIOS/HW does not support these simple rules, we need to quirk them.

>> do pulseaudio need a phantom port for the front panel headphone and mic
>> without jack detection ?
>
> Actually this is one good point.
> The jack detection isn't always reliably on such old machines, and
> BIOS cannot know, too.

Can you be a bit more specific about this claim? What machines? How many
machines? In what way is it unreliable?

 > That is, it has to be adjusted by user
 > manually, whether the jack detection is enabled or not.
>
> So far, we solved this by providing "Auto-Mute Mode" mixer switch.

This is not a proper way to "solve" it - "Auto-Mute mode" as the control
name says is more closely related to the muting of outputs, than it is
to the actual jack detection.

Also, "Auto-Mute mode" is 1) only related to outputs and 2) not
available generically but only for specific codecs.

> But the jack detection controls don't follow this yet. Maybe we can
> set such a jack control as inactive state when the jack detection is
> disabled.
>
> (And this reminds me that we can cut off "Phantom" name hack by
> following the same rule -- just set the control inactive when it has
> no real detection. But it still appears in control list.)

Looking at the alsa-lib API, this seems doable. It seems possible to
figure out using snd_hctl_elem_info and then
snd_ctl_elem_info_is_inactive. If it is also runtime changeable (i e
depending on some other mixer control), we need a callback to fire on
the hctl.

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

At Mon, 17 Sep 2012 09:39:01 +0200,
David Henningsson wrote:
>
> > But the jack detection controls don't follow this yet. Maybe we can
> > set such a jack control as inactive state when the jack detection is
> > disabled.
> >
> > (And this reminds me that we can cut off "Phantom" name hack by
> > following the same rule -- just set the control inactive when it has
> > no real detection. But it still appears in control list.)
>
> Looking at the alsa-lib API, this seems doable. It seems possible to
> figure out using snd_hctl_elem_info and then
> snd_ctl_elem_info_is_inactive. If it is also runtime changeable (i e
> depending on some other mixer control), we need a callback to fire on
> the hctl.

Why are you using snd_hctl? For looking over jack controls, using
snd_ctl_* is more straightforward.

Also, which callback are you thinking of? The phantom jack is
basically just a placeholder, so there should be no activity from
itself.

Takashi

>>> do you mean the commit does not fix the bug?
>>>
>>> ALSA: hda - add support for Uniwill ECS M31EI notebook
>>>
>>> This hardware requires same fixup for the node 0x0f like Asus A6Rp.
>>> More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
>>>
>>>
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d2b31fc740ed9d5a5ec116964fb43c4o358
>
>
> The PCI SSIDs are different, so I don't think that commit will affect the
bug I was trying to fix.
>

How many audio jacks do this m31ei have as
JrZabott specified model=3stack(3 jacks) which use cd pin , no auto Mic
since this input source also does not support jack detect.

Node 0x11 [Pin Complex] wcaps 0x400001: Stereo
  Pincap 0x00000063: IN Balanced Trigger ImpSense
  Pin Default 0x99331121: [Fixed] CD at Int ATAPI
    Conn = ATAPI, Color = Black
    DefAssociation = 0x2, Sequence = 0x1
    Misc = NO_PRESENCE
  Pin-ctls: 0x00:

The master playback switch is at audio mixer node 0x16

Simple mixer control 'Master',0
  Capabilities: pswitch penum
  Playback channels: Front Left - Front Right
  Mono:
  Front Left: Playback [on]
  Front Right: Playback [on]
Simple mixer control 'PCM',0
  Capabilities: pvolume penum
  Playback channels: Front Left - Front Right
  Limits: Playback 0 - 255
  Mono:
  Front Left: Playback 255 [100%] [0.00dB]
  Front Right: Playback 255 [100%] [0.00dB]

There is no headphone playback volume/switch so why do pulseaudio remove
the analog output path ?

ports:
analog-output-headphones: Headphones (priority 9000, available: no)
properties:

active port: <analog-output-headphones>

There are mini itx chassis which does not have front audio panel, will
pulseaudio remove the analog output path ?

Default PCM:
    rates [0x140]: 48000 96000
    bits [0xe]: 16 20 24
    formats [0x1]: PCM
Default Amp-In caps: N/A
Default Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1

Refer to the block diagram of alc861 datasheet, it seem every audio output
and pin complex has a mute switch

And you already mentioned there is no speaker pin

>
>>> the real cases are those desktop which does not use hda front audio
panel ,
>>> they just loss the auto mute since there is no jack detect circuit but
they
>>> can still hear sound from the headphone at anytime
>
>
> If there is an AC'97 front panel connected, the BIOS should set
NO_PRESENCE in the misc bit.

Do you mean the driver should a read/write kcontrol so that user can change
the state by qashctl ?

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/939161

00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High
Definition Audio Controller [8086:27d8] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9072]
>
>
> The PCI SSIDs are different, so I don't think that commit will affect the
bug I was trying to fix.

There was a model uniwill-m31

what you need is just provide a pin fixup from the patch which remove the
model

- [ALC861_UNIWILL_M31] = "uniwill-m31",

- SND_PCI_QUIRK(0x1584, 0x9072, "Uniwill m31", ALC861_UNIWILL_M31),

http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commitdiff;h=9fbbc94fe0f0a85d048b74fced3cfca404d78a3c;hp=6ebb80530b0ed6b2e93f2e6497890b4437807055

https://lists.ubuntu.com/archives/kernel-team/2006-August/000994.html

the model uniwill-m31 seem can retask mic as output for surround40

2012-9-19 上午8:35 於 "Raymond Yau" <email address hidden> 寫道：
>
> >>> do you mean the commit does not fix the bug?
> >>>
> >>> ALSA: hda - add support for Uniwill ECS M31EI notebook
> >>>
> >>> This hardware requires same fixup for the node 0x0f like Asus A6Rp.
> >>> More information: https://bugzilla.redhat.com/show_bug.cgi?id=785417
> >>>
> >>>
http://git.kernel.org/?p=linux/kernel/git/tiwai/sound.git;a=commit;h=416846d2b31fc740ed9d5a5ec116964fb43c4o358
>
> >
> >
> > The PCI SSIDs are different, so I don't think that commit will affect
the bug I was trying to fix.

https://launchpadlibrarian.net/93810068/PciMultimedia.txt

00:1b.0 Audio device [0403]: Intel Corporation N10/ICH 7 Family High
Definition Audio Controller [8086:27d8] (rev 02)
Subsystem: Uniwill Computer Corp Device [1584:9072]

https://launchpadlibrarian.net/93810064/Card0.Codecs.codec.0.txt

Codec: Realtek ALC861
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x10ec0861
Subsystem Id: 0x15840000
Revision Id: 0x100300

https://bugzilla.redhat.com/attachment.cgi?id=559582

Advanced information - PCI Vendor/Device/Subsystem ID's
!!--------------------------------------------------------

00:1b.0 0403: 8086:27d8 (rev 02)
Subsystem: 1584:9072

Codec: Realtek ALC861
Address: 0
AFG Function Id: 0x1 (unsol 0)
Vendor Id: 0x10ec0861
Subsystem Id: 0x15840000
Revision Id: 0x100300