Issues and/or possible bugs in alsa

Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Hello.

I seem to have run into a few issues with alsa.

First, when I plug my headphones into my laptop, sound continues to play
out of the speakers and doesn't switch over to (or unmute) the headphones.
Auto-Mute Mode is enabled in alsamixer. The same thing happens when I
unplug the headphones, it doesn't switch over to the speakers. I have to do
the same thing I described above, (no unmuting, I just have to turn up the
volume for the speakers in alsamixer.)

Second. When I plug in these headphones, I can't use the internal
microphone on this laptop, it mutes. (AFAICT)
These headphones do not have a microphone built in, they're just an
ordinary pair of headphones. However, I was given a workaround in #alsa on
freenode. In order to use the laptop's internal microphone with my
headphones plugged in, I have to do : sudo hda-verb /dev/snd/hwC1D0 0x22
SET_CONNECT_SEL 6 — it works, but it isn't really ideal.

alsa-info is here : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811

The first file in that gist is alsa-info with headphones and the second is
without headphones.

Third. This is just a question. Is this :
https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
bug, or is it an issue with alsa?
I'm only asking since Raymond linked something that seemed to belong to the
alsa project.

Thank you.

-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Takashi Iwai]

At Tue, 24 Feb 2015 17:46:09 -0500,
Yomi Ogunwumi wrote:
> 
> Hello.
> 
> I seem to have run into a few issues with alsa.
> 
> First, when I plug my headphones into my laptop, sound continues to play
> out of the speakers and doesn't switch over to (or unmute) the headphones.
> Auto-Mute Mode is enabled in alsamixer. The same thing happens when I
> unplug the headphones, it doesn't switch over to the speakers. I have to do
> the same thing I described above, (no unmuting, I just have to turn up the
> volume for the speakers in alsamixer.)
> 
> Second. When I plug in these headphones, I can't use the internal
> microphone on this laptop, it mutes. (AFAICT)
> These headphones do not have a microphone built in, they're just an
> ordinary pair of headphones. However, I was given a workaround in #alsa on
> freenode. In order to use the laptop's internal microphone with my
> headphones plugged in, I have to do : sudo hda-verb /dev/snd/hwC1D0 0x22
> SET_CONNECT_SEL 6 — it works, but it isn't really ideal.
> 
> alsa-info is here : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811
> 
> The first file in that gist is alsa-info with headphones and the second is
> without headphones.
> 
> Third. This is just a question. Is this :
> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
> bug, or is it an issue with alsa?
> I'm only asking since Raymond linked something that seemed to belong to the
> alsa project.

The alsa-info.sh output above shows the reads from the codec failed.
Could you try once to disable power-saving?  Set power_save=0 option
to snd-hda-intel module.

Note that power_save option might be changed dynamically by the system
(accessible via /sys/module/snd_hda_intel/parameters/power_save).  If
the problem is still seen, check the value there whether you still
really have 0 or it was changed by the system.

Restricting the power-save isn't a solution but helps understanding
the cause, at least.


Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Sorry, I think this :
*https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsa-info-without-headphones
<https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsa-info-without-headphones>
*is
what you wanted.
Headphones are plugged in.

On Wed, Feb 25, 2015 at 2:58 AM, Takashi Iwai <tiwai@suse.de> wrote:

> At Tue, 24 Feb 2015 17:46:09 -0500,
> Yomi Ogunwumi wrote:
> >
> > Hello.
> >
> > I seem to have run into a few issues with alsa.
> >
> > First, when I plug my headphones into my laptop, sound continues to play
> > out of the speakers and doesn't switch over to (or unmute) the
> headphones.
> > Auto-Mute Mode is enabled in alsamixer. The same thing happens when I
> > unplug the headphones, it doesn't switch over to the speakers. I have to
> do
> > the same thing I described above, (no unmuting, I just have to turn up
> the
> > volume for the speakers in alsamixer.)
> >
> > Second. When I plug in these headphones, I can't use the internal
> > microphone on this laptop, it mutes. (AFAICT)
> > These headphones do not have a microphone built in, they're just an
> > ordinary pair of headphones. However, I was given a workaround in #alsa
> on
> > freenode. In order to use the laptop's internal microphone with my
> > headphones plugged in, I have to do : sudo hda-verb /dev/snd/hwC1D0 0x22
> > SET_CONNECT_SEL 6 — it works, but it isn't really ideal.
> >
> > alsa-info is here : https://gist.github.com/Yomi0/9bfc3e72588cf8a35811
> >
> > The first file in that gist is alsa-info with headphones and the second
> is
> > without headphones.
> >
> > Third. This is just a question. Is this :
> > https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
> > bug, or is it an issue with alsa?
> > I'm only asking since Raymond linked something that seemed to belong to
> the
> > alsa project.
>
> The alsa-info.sh output above shows the reads from the codec failed.
> Could you try once to disable power-saving?  Set power_save=0 option
> to snd-hda-intel module.
>
> Note that power_save option might be changed dynamically by the system
> (accessible via /sys/module/snd_hda_intel/parameters/power_save).  If
> the problem is still seen, check the value there whether you still
> really have 0 or it was changed by the system.
>
> Restricting the power-save isn't a solution but helps understanding
> the cause, at least.
>
>
> Takashi
>



-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

This is what happens when I don't double check links and reread mail before
hit send. That link in the last message does not contain the information
you are looking for.

This does :
https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsainfo-headphones-in

• Yomi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Alexander E. Patrakov]

25.02.2015 03:46, Yomi Ogunwumi wrote:
> Third. This is just a question. Is this :
> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
> bug, or is it an issue with alsa?
> I'm only asking since Raymond linked something that seemed to belong to the
> alsa project.
>

This is a bug both in ALSA and in PulseAudio.

The ALSA part (from the user viewpoint) is that the softvol plugin does 
not reprocess the already-submitted but buffered samples when the volume 
changes. But it can't, because that would require an additional thread 
for monitoring the software volume changes, and such thread does not exist.

The PulseAudio part of the bug is that it does not deactivate softvols, 
even though it can apply volume in software itself. In October 2014, in 
Dusseldorf, a general agreement has been reached on the following arguments:

  * ALSA has no API to definitely distinguish softvols from other controls.
  * ALSA has the snd_ctl_elem_info_is_user() API function that tells 
whether this is a userspace control.
  * All softvols are userspace controls.
  * There are other kinds of userspace controls, but they are rare.
  * If a control is named PCM Playback Volume and is a userspace 
control, then it's likely a softvol. Not bulletproof, but a good-enough 
heuristic.
  * On finding a softvol, PulseAudio should set it to 100% (so that it 
doesn't eat CPU) and don't touch from that point on.

But nobody has implemented this so far.

The relevant code can be placed in the src/modules/alsa/alsa-mixer.c 
file in PulseAudio source tree. I guess that element_probe() is a good 
place. If you know C programming, a contribution would be welcome.||

-- 
Alexander E. Patrakov

Re: Issues and/or possible bugs in alsa

[Jaroslav Kysela]

Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
> 25.02.2015 03:46, Yomi Ogunwumi wrote:
>> Third. This is just a question. Is this :
>> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
>> bug, or is it an issue with alsa?
>> I'm only asking since Raymond linked something that seemed to belong to the
>> alsa project.
>>
> 
> This is a bug both in ALSA and in PulseAudio.
> 
> The ALSA part (from the user viewpoint) is that the softvol plugin does 
> not reprocess the already-submitted but buffered samples when the volume 
> changes. But it can't, because that would require an additional thread 
> for monitoring the software volume changes, and such thread does not exist.
> 
> The PulseAudio part of the bug is that it does not deactivate softvols, 
> even though it can apply volume in software itself. In October 2014, in 
> Dusseldorf, a general agreement has been reached on the following arguments:
> 
>   * ALSA has no API to definitely distinguish softvols from other controls.
>   * ALSA has the snd_ctl_elem_info_is_user() API function that tells 
> whether this is a userspace control.
>   * All softvols are userspace controls.
>   * There are other kinds of userspace controls, but they are rare.
>   * If a control is named PCM Playback Volume and is a userspace 
> control, then it's likely a softvol. Not bulletproof, but a good-enough 
> heuristic.
>   * On finding a softvol, PulseAudio should set it to 100% (so that it 
> doesn't eat CPU) and don't touch from that point on.
> 
> But nobody has implemented this so far.

PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this
case, the PCM device does not add the softvol plugin to the internal
plugin chain. These mode flags was introduced a long time ago (discussed
with Lennart) and I thought that PA uses it.

					Jaroslav

-- 
Jaroslav Kysela <perex@perex.cz>
Linux Kernel Sound Maintainer
ALSA Project; Red Hat, Inc.

Re: Issues and/or possible bugs in alsa

[Alexander E. Patrakov]

25.02.2015 13:30, Jaroslav Kysela wrote:
> Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
>> 25.02.2015 03:46, Yomi Ogunwumi wrote:
>>> Third. This is just a question. Is this :
>>> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
>>> bug, or is it an issue with alsa?
>>> I'm only asking since Raymond linked something that seemed to belong to the
>>> alsa project.
>>>
>> This is a bug both in ALSA and in PulseAudio.
>>
>> The ALSA part (from the user viewpoint) is that the softvol plugin does
>> not reprocess the already-submitted but buffered samples when the volume
>> changes. But it can't, because that would require an additional thread
>> for monitoring the software volume changes, and such thread does not exist.
>>
>> The PulseAudio part of the bug is that it does not deactivate softvols,
>> even though it can apply volume in software itself. In October 2014, in
>> Dusseldorf, a general agreement has been reached on the following arguments:
>>
>>    * ALSA has no API to definitely distinguish softvols from other controls.
>>    * ALSA has the snd_ctl_elem_info_is_user() API function that tells
>> whether this is a userspace control.
>>    * All softvols are userspace controls.
>>    * There are other kinds of userspace controls, but they are rare.
>>    * If a control is named PCM Playback Volume and is a userspace
>> control, then it's likely a softvol. Not bulletproof, but a good-enough
>> heuristic.
>>    * On finding a softvol, PulseAudio should set it to 100% (so that it
>> doesn't eat CPU) and don't touch from that point on.
>>
>> But nobody has implemented this so far.
> PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this
> case, the PCM device does not add the softvol plugin to the internal
> plugin chain. These mode flags was introduced a long time ago (discussed
> with Lennart) and I thought that PA uses it.
>
> 					Jaroslav
>

Well, that can be done, but the "don't attempt to control the softvol" 
part of the bug needs to be solved first. SND_PCM_NO_SOFTVOL by itself 
is not sufficient.

-- 
Alexander E. Patrakov

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Iwai, I checked the value
of /sys/module/snd_hda_intel/parameters/power_save with less, it is set to
0 already.

On Wed, Feb 25, 2015 at 3:36 AM, Alexander E. Patrakov <patrakov@gmail.com>
wrote:

> 25.02.2015 13:30, Jaroslav Kysela wrote:
>
>> Dne 25.2.2015 v 09:14 Alexander E. Patrakov napsal(a):
>>
>>> 25.02.2015 03:46, Yomi Ogunwumi wrote:
>>>
>>>> Third. This is just a question. Is this :
>>>> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a
>>>> pulseaudio
>>>> bug, or is it an issue with alsa?
>>>> I'm only asking since Raymond linked something that seemed to belong to
>>>> the
>>>> alsa project.
>>>>
>>>>  This is a bug both in ALSA and in PulseAudio.
>>>
>>> The ALSA part (from the user viewpoint) is that the softvol plugin does
>>> not reprocess the already-submitted but buffered samples when the volume
>>> changes. But it can't, because that would require an additional thread
>>> for monitoring the software volume changes, and such thread does not
>>> exist.
>>>
>>> The PulseAudio part of the bug is that it does not deactivate softvols,
>>> even though it can apply volume in software itself. In October 2014, in
>>> Dusseldorf, a general agreement has been reached on the following
>>> arguments:
>>>
>>>    * ALSA has no API to definitely distinguish softvols from other
>>> controls.
>>>    * ALSA has the snd_ctl_elem_info_is_user() API function that tells
>>> whether this is a userspace control.
>>>    * All softvols are userspace controls.
>>>    * There are other kinds of userspace controls, but they are rare.
>>>    * If a control is named PCM Playback Volume and is a userspace
>>> control, then it's likely a softvol. Not bulletproof, but a good-enough
>>> heuristic.
>>>    * On finding a softvol, PulseAudio should set it to 100% (so that it
>>> doesn't eat CPU) and don't touch from that point on.
>>>
>>> But nobody has implemented this so far.
>>>
>> PulseAudio should open PCM with the SND_PCM_NO_SOFTVOL mode. In this
>> case, the PCM device does not add the softvol plugin to the internal
>> plugin chain. These mode flags was introduced a long time ago (discussed
>> with Lennart) and I thought that PA uses it.
>>
>>                                         Jaroslav
>
> Well, good to know, at least.

>
>>
> Well, that can be done, but the "don't attempt to control the softvol"
> part of the bug needs to be solved first. SND_PCM_NO_SOFTVOL by itself is
> not sufficient.
>
> --
> Alexander E. Patrakov
>
>


-- 
*Yomi*

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

[-- Attachment #1: Type: text/plain, Size: 4332 bytes --]

>> Third. This is just a question. Is this :
>> https://bugs.freedesktop.org/show_bug.cgi?id=86676 actually a pulseaudio
>> bug, or is it an issue with alsa?
>> I'm only asking since Raymond linked something that seemed to belong to
the
>> alsa project.
>>
>
> This is a bug both in ALSA and in PulseAudio.
>
> The ALSA part (from the user viewpoint) is that the softvol plugin does
not reprocess the already-submitted but buffered samples when the volume
changes. But it can't, because that would require an additional thread for
monitoring the software volume changes, and such thread does not exist.
>
> The PulseAudio part of the bug is that it does not deactivate softvols,
even though it can apply volume in software itself. In October 2014, in
Dusseldorf, a general agreement has been reached on the following arguments:
>
>  * ALSA has no API to definitely distinguish softvols from other controls.
>  * ALSA has the snd_ctl_elem_info_is_user() API function that tells
whether this is a userspace control.
>  * All softvols are userspace controls.
>  * There are other kinds of userspace controls, but they are rare.
>  * If a control is named PCM Playback Volume and is a userspace control,
then it's likely a softvol. Not bulletproof, but a good-enough heuristic.

You can use snd_ctl_elem_info_is_use() to find out the name of those user
space controls of the card and ignore those softvol "PCM playback volume"
and "Digital Capture Volume" controls

>  * On finding a softvol, PulseAudio should set it to 100% (so that it
doesn't eat CPU) and don't touch from that point on.
>
> But nobody has implemented this so far.
>
> The relevant code can be placed in the src/modules/alsa/alsa-mixer.c file
in PulseAudio source tree. I guess that element_probe() is a good place. If
you know C programming, a contribution would be welcome.||
>

state.Generic {
control.1 {
iface CARD
name 'HDMI/DP,pcm=3 Jack'
value false
comment {
access read
type BOOLEAN
count 1
}
}
control.2 {
iface MIXER
name 'IEC958 Playback Con Mask'
value
'0fff000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
comment {
access read
type IEC958
count 1
}
}
control.3 {
iface MIXER
name 'IEC958 Playback Pro Mask'
value
'0f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
comment {
access read
type IEC958
count 1
}
}
control.4 {
iface MIXER
name 'IEC958 Playback Default'
value
'0400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'
comment {
access 'read write'
type IEC958
count 1
}
}
control.5 {
iface MIXER
name 'IEC958 Playback Switch'
value true
comment {
access 'read write'
type BOOLEAN
count 1
}
}
control.6 {
iface PCM
device 3
name ELD
value ''
comment {
access 'read volatile'
type BYTES
count 0
}
}
control.7 {
iface PCM
device 3
name 'Playback Channel Map'
value.0 0
value.1 0
value.2 0
value.3 0
value.4 0
value.5 0
value.6 0
value.7 0
comment {
access 'read write'
type INTEGER
count 8
range '0 - 36'
}
}
control.8 {
iface MIXER
name 'PCM Playback Volume'
value.0 184
value.1 184
comment {
access 'read write user'
type INTEGER
count 2
range '0 - 255'
tlv '0000000100000008ffffec1400000014'
dbmin -5100
dbmax 0
dbvalue.0 -1420
dbvalue.1 -1420
}
}
}

It is strange that your hdmi card have a softvol control ,

Was  the softvol control created when you swap the card number by index=1,0
?

[-- Attachment #2: user_ctl.c --]
[-- Type: text/x-csrc, Size: 3141 bytes --]

#include <stdio.h>
#include <alsa/asoundlib.h>


static char *id_str(snd_ctl_elem_id_t *id)
{
	static char str[128];
	assert(id);
	sprintf(str, "%i,%i,%i,%s,%i", 
		snd_ctl_elem_id_get_interface(id),
		snd_ctl_elem_id_get_device(id),
		snd_ctl_elem_id_get_subdevice(id),
		snd_ctl_elem_id_get_name(id),
		snd_ctl_elem_id_get_index(id));
	return str;
}


static int get_control(snd_ctl_t *handle, snd_ctl_elem_id_t *id, snd_config_t *top)
{
	snd_ctl_elem_value_t *ctl;
	snd_ctl_elem_info_t *info;
	snd_config_t *control, *comment, *item, *value;
	const char *s;
	char buf[256];
	unsigned int idx;
	int err;
	unsigned int device, subdevice, index;
	const char *name;
	snd_ctl_elem_type_t type;
	unsigned int count;
	snd_ctl_elem_value_alloca(&ctl);
	snd_ctl_elem_info_alloca(&info);
	snd_ctl_elem_info_set_id(info, id);
	err = snd_ctl_elem_info(handle, info);
	if (err < 0) {
		error("Cannot read control info '%s': %s", id_str(id), snd_strerror(err));
		return err;
	}

	if (!snd_ctl_elem_info_is_readable(info))
		return 0;
	snd_ctl_elem_value_set_id(ctl, id);
	err = snd_ctl_elem_read(handle, ctl);
	if (err < 0) {
		error("Cannot read control '%s': %s", id_str(id), snd_strerror(err));
		return err;
	}


	type = snd_ctl_elem_info_get_type(info);
	device = snd_ctl_elem_info_get_device(info);
	subdevice = snd_ctl_elem_info_get_subdevice(info);
	index = snd_ctl_elem_info_get_index(info);
	name = snd_ctl_elem_info_get_name(info);
	count = snd_ctl_elem_info_get_count(info);
	s = snd_ctl_elem_type_name(type);

	if (snd_ctl_elem_info_is_user(info))
		printf(" user control : %s - %s\n", name, id_str(id));


	return 0;
}


int main(int argc, char* argv[])
{
	snd_ctl_t *handle;
	snd_ctl_card_info_t *info;
	snd_config_t *state, *card, *control;
	snd_ctl_elem_list_t *list;
	snd_ctl_elem_id_t *elem_id;
	unsigned int idx;
	int err;
	char name[32];
	unsigned int count;
	const char *id;
	int cardno;

	cardno = 0;
	snd_ctl_card_info_alloca(&info);
	snd_ctl_elem_list_alloca(&list);
	snd_ctl_elem_id_alloca(&elem_id);

	sprintf(name, "hw:%d", cardno);
	err = snd_ctl_open(&handle, name, SND_CTL_READONLY);
	if (err < 0) {
		error("snd_ctl_open error: %s", snd_strerror(err));
		return err;
	}
	err = snd_ctl_card_info(handle, info);
	if (err < 0) {
		error("snd_ctl_card_info error: %s", snd_strerror(err));
		goto _close;
	}
	id = snd_ctl_card_info_get_id(info);

	err = snd_ctl_elem_list(handle, list);
	if (err < 0) {
		error("Cannot determine controls: %s", snd_strerror(err));
		goto _close;
	}
	count = snd_ctl_elem_list_get_count(list);
	if (count == 0) {
		err = 0;
		goto _close;
	}
	snd_ctl_elem_list_set_offset(list, 0);
	if (snd_ctl_elem_list_alloc_space(list, count) < 0) {
		error("No enough memory...");
		goto _close;
	}
	if ((err = snd_ctl_elem_list(handle, list)) < 0) {
		error("Cannot determine controls (2): %s", snd_strerror(err));
		goto _free;
	}
	for (idx = 0; idx < count; ++idx) {
		snd_ctl_elem_list_get_id(list, idx, elem_id);
		err = get_control(handle, elem_id, control);
		if (err < 0)
			goto _free;
	}		
		
	err = 0;
 _free:
	snd_ctl_elem_list_free_space(list);
 _close:
	snd_ctl_close(handle);
	return 0;
}

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: Issues and/or possible bugs in alsa

[Alexander E. Patrakov]

28.02.2015 15:00, Raymond Yau wrote:
>
> It is strange that your hdmi card have a softvol control ,
>
> Was  the softvol control created when you swap the card number by 
> index=1,0 ?
>

The control was created when I used a custom asoundrc in order to test 
dmix on top of hdmi. Since then, I removed the customization, but there 
is no easy way to remove the control, as it is always saved on shutdown 
and restored on boot even if there is nothing in the current .asoundrc 
that uses it. I will remove it from the state file using a livecd, just 
to avoid such questions in the future.

-- 
Alexander E. Patrakov

Re: Issues and/or possible bugs in alsa

[Takashi Iwai]

At Sat, 28 Feb 2015 18:22:19 +0500,
Alexander E. Patrakov wrote:
> 
> 28.02.2015 15:00, Raymond Yau wrote:
> >
> > It is strange that your hdmi card have a softvol control ,
> >
> > Was  the softvol control created when you swap the card number by 
> > index=1,0 ?
> >
> 
> The control was created when I used a custom asoundrc in order to test 
> dmix on top of hdmi. Since then, I removed the customization, but there 
> is no easy way to remove the control, as it is always saved on shutdown 
> and restored on boot even if there is nothing in the current .asoundrc 
> that uses it. I will remove it from the state file using a livecd, just 
> to avoid such questions in the future.

Right, there is no command so far for removing a user ctl element.
It's relatively trivial to implement, though, e.g. in amixer or
alsactl, I guess.  Any taker?


Takashi

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Is there anything else I need to do?

On Sat, Feb 28, 2015 at 10:13 AM, Takashi Iwai <tiwai@suse.de> wrote:

> At Sat, 28 Feb 2015 18:22:19 +0500,
> Alexander E. Patrakov wrote:
> >
> > 28.02.2015 15:00, Raymond Yau wrote:
> > >
> > > It is strange that your hdmi card have a softvol control ,
> > >
> > > Was  the softvol control created when you swap the card number by
> > > index=1,0 ?
> > >
> >
> > The control was created when I used a custom asoundrc in order to test
> > dmix on top of hdmi. Since then, I removed the customization, but there
> > is no easy way to remove the control, as it is always saved on shutdown
> > and restored on boot even if there is nothing in the current .asoundrc
> > that uses it. I will remove it from the state file using a livecd, just
> > to avoid such questions in the future.
>
> Right, there is no command so far for removing a user ctl element.
> It's relatively trivial to implement, though, e.g. in amixer or
> alsactl, I guess.  Any taker?
>
>
> Takashi
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>



-- 
*Yomi*

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Is there anything else I need to do?

Codec: Realtek ALC269VB
Address: 0
AFG Function Id: 0x1 (unsol 1)
Vendor Id: 0x10ec0269
Subsystem Id: 0x1179fa22
Revision Id: 0x100100
No Modem Function Group found
Default PCM:
N/A
Default Amp-In caps: N/A
Default Amp-Out caps: N/A
State of AFG node 0x01:
  Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK,
Setting-reset
Invalid AFG subtree

Your problem seem related to power

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Whoops, I didn't realize I sent that to you and you alone, Raymond.

I'm going to take a guess and conclude that there must be bugs in the
interface patch written for the realtek codecs. I happened to test two
other laptops and they worked just fine. (Intel...)

...I guess in should report a bug related to that realtek patch...

• Yomi
On Mar 22, 2015 11:11 AM, "Yomi Ogunwumi" <abyomi0@gmail.com> wrote:

> Is there anything I can do to resolve it?
>
> On Sun, Mar 22, 2015 at 11:09 AM, Yomi Ogunwumi <abyomi0@gmail.com> wrote:
>
>> There is one log where that snippet looks correct.
>>
>> https://gist.github.com/Yomi0/9bfc3e72588cf8a35811#file-alsainfo-headphones-in
>>
>>
>> https://gist.githubusercontent.com/Yomi0/9bfc3e72588cf8a35811/raw/77ff724d23c93517dd21790181fce30cfc4050d8/alsainfo%20(headphones%20in)
>>
>> Codec: Realtek ALC269VB
>> Address: 0
>> AFG Function Id: 0x1 (unsol 1)
>> Vendor Id: 0x10ec0269
>> Subsystem Id: 0x1179fa22
>> Revision Id: 0x100100
>> No Modem Function Group found
>> Default PCM:
>>     rates [0x560]: 44100 48000 96000 192000
>>     bits [0xe]: 16 20 24
>>     formats [0x1]: PCM
>> Default Amp-In caps: N/A
>> Default Amp-Out caps: N/A
>> State of AFG node 0x01:
>>   Power states:  D0 D1 D2 D3 CLKSTOP EPSS
>>   Power: setting=D0, actual=D0
>>
>>
>> On Sun, Mar 15, 2015 at 11:58 AM, Raymond Yau <
>> superquad.vortex2@gmail.com> wrote:
>>
>>> >
>>> > Is there anything else I need to do?
>>>
>>> Codec: Realtek ALC269VB
>>> Address: 0
>>> AFG Function Id: 0x1 (unsol 1)
>>> Vendor Id: 0x10ec0269
>>> Subsystem Id: 0x1179fa22
>>> Revision Id: 0x100100
>>> No Modem Function Group found
>>> Default PCM:
>>> N/A
>>> Default Amp-In caps: N/A
>>> Default Amp-Out caps: N/A
>>> State of AFG node 0x01:
>>>   Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK,
>>> Setting-reset
>>> Invalid AFG subtree
>>>
>>> Your problem seem related to power
>>>
>> --
>> *Yomi*
>>
>
>
>
> --
> *Yomi*
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> I'm going to take a guess and conclude that there must be bugs in the
interface patch written for the realtek codecs. I happened to test two
other laptops and they worked just fine. (Intel...)
>
> ...I guess in should report a bug related to that realtek patch...
>
> •
>>>> >
>>>> > Is there anything else I need to do?
>>>>
>>>> Codec: Realtek ALC269VB
>>>> Address: 0
>>>> AFG Function Id: 0x1 (unsol 1)
>>>> Vendor Id: 0x10ec0269
>>>> Subsystem Id: 0x1179fa22
>>>> Revision Id: 0x100100
>>>> No Modem Function Group found
>>>> Default PCM:
>>>> N/A
>>>> Default Amp-In caps: N/A
>>>> Default Amp-Out caps: N/A
>>>> State of AFG node 0x01:
>>>>   Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK,
Setting-reset
>>>> Invalid AFG subtree

You need to find out what value return snd_hda_param_read()  in
snd_hda_get_sub_nodes ()

and value of pwr return by snd_hda_codec_read(codec, nid, 0,
     AC_VERB_GET_POWER_STATE, 0);

int snd_hda_get_sub_nodes(struct hda_codec *codec, hda_nid_t nid,
                        hda_nid_t *start_id)
{
         unsigned int parm;

        parm = snd_hda_param_read(codec, nid, AC_PAR_NODE_COUNT);
       if (parm == -1) {
              *start_id = 0
                 return 0;
      }
       *start_id = (parm >> 16) & 0x7fff;
      return (int)(parm & 0x7fff);
}
nodes = snd_hda_get_sub_nodes(codec, fg, &nid);
if (! nid || nodes < 0) {
snd_iprintf(buffer, "Invalid AFG subtree\n");
snd_hda_power_down(codec);
return;
}


Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK, Setting-reset

static const char *get_pwr_state(u32 state)
{
static const char * const buf[] = {
"D0", "D1", "D2", "D3", "D3cold"
};
if (state < ARRAY_SIZE(buf))
return buf[state];
return "UNKNOWN";
}


int sup = snd_hda_param_read(codec, nid, AC_PAR_POWER_STATE);
int pwr = snd_hda_codec_read(codec, nid, 0,
     AC_VERB_GET_POWER_STATE, 0);
if (sup != -1)
snd_iprintf(buffer, "  Power states: %s\n",
    bits_names(sup, names, ARRAY_SIZE(names)));

snd_iprintf(buffer, "  Power: setting=%s, actual=%s",
    get_pwr_state(pwr & AC_PWRST_SETTING),
    get_pwr_state((pwr & AC_PWRST_ACTUAL) >>
  AC_PWRST_ACTUAL_SHIFT));
if (pwr & AC_PWRST_ERROR)
snd_iprintf(buffer, ", Error");
if (pwr & AC_PWRST_CLK_STOP_OK)
snd_iprintf(buffer, ", Clock-stop-OK");
if (pwr & AC_PWRST_SETTING_RESET)
snd_iprintf(buffer, ", Setting-reset");
snd_iprintf(buffer, "\n");
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Can you send me a modified sound/pci/hda/hda_proc.c, with the changes you
included in last email?

• Yomi
On Apr 3, 2015 11:10 AM, "Raymond Yau" <superquad.vortex2@gmail.com> wrote:

> >
> > I'm going to take a guess and conclude that there must be bugs in the
> interface patch written for the realtek codecs. I happened to test two
> other laptops and they worked just fine. (Intel...)
> >
> > ...I guess in should report a bug related to that realtek patch...
> >
> > •
> >>>> >
> >>>> > Is there anything else I need to do?
> >>>>
> >>>> Codec: Realtek ALC269VB
> >>>> Address: 0
> >>>> AFG Function Id: 0x1 (unsol 1)
> >>>> Vendor Id: 0x10ec0269
> >>>> Subsystem Id: 0x1179fa22
> >>>> Revision Id: 0x100100
> >>>> No Modem Function Group found
> >>>> Default PCM:
> >>>> N/A
> >>>> Default Amp-In caps: N/A
> >>>> Default Amp-Out caps: N/A
> >>>> State of AFG node 0x01:
> >>>>   Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK,
> Setting-reset
> >>>> Invalid AFG subtree
>
> You need to find out what value return snd_hda_param_read()  in
> snd_hda_get_sub_nodes ()
>
> and value of pwr return by snd_hda_codec_read(codec, nid, 0,
>      AC_VERB_GET_POWER_STATE, 0);
>
> int snd_hda_get_sub_nodes(struct hda_codec *codec, hda_nid_t nid,
>                         hda_nid_t *start_id)
> {
>          unsigned int parm;
>
>         parm = snd_hda_param_read(codec, nid, AC_PAR_NODE_COUNT);
>        if (parm == -1) {
>               *start_id = 0
>                  return 0;
>       }
>        *start_id = (parm >> 16) & 0x7fff;
>       return (int)(parm & 0x7fff);
> }
> nodes = snd_hda_get_sub_nodes(codec, fg, &nid);
> if (! nid || nodes < 0) {
> snd_iprintf(buffer, "Invalid AFG subtree\n");
> snd_hda_power_down(codec);
> return;
> }
>
>
> Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK, Setting-reset
>
> static const char *get_pwr_state(u32 state)
> {
> static const char * const buf[] = {
> "D0", "D1", "D2", "D3", "D3cold"
> };
> if (state < ARRAY_SIZE(buf))
> return buf[state];
> return "UNKNOWN";
> }
>
>
> int sup = snd_hda_param_read(codec, nid, AC_PAR_POWER_STATE);
> int pwr = snd_hda_codec_read(codec, nid, 0,
>      AC_VERB_GET_POWER_STATE, 0);
> if (sup != -1)
> snd_iprintf(buffer, "  Power states: %s\n",
>     bits_names(sup, names, ARRAY_SIZE(names)));
>
> snd_iprintf(buffer, "  Power: setting=%s, actual=%s",
>     get_pwr_state(pwr & AC_PWRST_SETTING),
>     get_pwr_state((pwr & AC_PWRST_ACTUAL) >>
>   AC_PWRST_ACTUAL_SHIFT));
> if (pwr & AC_PWRST_ERROR)
> snd_iprintf(buffer, ", Error");
> if (pwr & AC_PWRST_CLK_STOP_OK)
> snd_iprintf(buffer, ", Clock-stop-OK");
> if (pwr & AC_PWRST_SETTING_RESET)
> snd_iprintf(buffer, ", Setting-reset");
> snd_iprintf(buffer, "\n");
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Can you send me a modified sound/pci/hda/hda_proc.c, with the changes you
included in last email?

Just change two lines to dump nid, nodes and pwr

snd_iprintf(buffer, "Invalid AFG subtree nid=%x nodes=%x\n", nid, nodes);

snd_iprintf(buffer, "  Power: %x setting=%s, actual=%s", pwr,
    get_pwr_state(pwr & AC_PWRST_SETTING),
    get_pwr_state((pwr & AC_PWRST_ACTUAL) >>
  AC_PWRST_ACTUAL_SHIFT));

>> >
>> > I'm going to take a guess and conclude that there must be bugs in the
interface patch written for the realtek codecs. I happened to test two
other laptops and they worked just fine. (Intel...)
>> >
>> > ...I guess in should report a bug related to that realtek patch...
>> >
>> > •
>> >>>> >
>> >>>> > Is there anything else I need to do?
>> >>>>
>> >>>> Codec: Realtek ALC269VB
>> >>>> Address: 0
>> >>>> AFG Function Id: 0x1 (unsol 1)
>> >>>> Vendor Id: 0x10ec0269
>> >>>> Subsystem Id: 0x1179fa22
>> >>>> Revision Id: 0x100100
>> >>>> No Modem Function Group found
>> >>>> Default PCM:
>> >>>> N/A
>> >>>> Default Amp-In caps: N/A
>> >>>> Default Amp-Out caps: N/A
>> >>>> State of AFG node 0x01:
>> >>>>   Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK,
Setting-reset
>> >>>> Invalid AFG subtree
>>
>>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Okay, I added those lines to a clone of tiwai's repo.
Output of alsa-info.sh :
https://gist.github.com/Yomi0/f4059fe45d960f141b33#file-rpatch



On Thu, Apr 9, 2015 at 9:20 PM, Raymond Yau <superquad.vortex2@gmail.com>
wrote:

> >
> > Can you send me a modified sound/pci/hda/hda_proc.c, with the changes
> you included in last email?
>
> Just change two lines to dump nid, nodes and pwr
>
> snd_iprintf(buffer, "Invalid AFG subtree nid=%x nodes=%x\n", nid, nodes);
>
> snd_iprintf(buffer, "  Power: %x setting=%s, actual=%s", pwr,
>     get_pwr_state(pwr & AC_PWRST_SETTING),
>     get_pwr_state((pwr & AC_PWRST_ACTUAL) >>
>   AC_PWRST_ACTUAL_SHIFT));
>
> >> >
> >> > I'm going to take a guess and conclude that there must be bugs in the
> interface patch written for the realtek codecs. I happened to test two
> other laptops and they worked just fine. (Intel...)
> >> >
> >> > ...I guess in should report a bug related to that realtek patch...
> >> >
> >> > •
> >> >>>> >
> >> >>>> > Is there anything else I need to do?
> >> >>>>
> >> >>>> Codec: Realtek ALC269VB
> >> >>>> Address: 0
> >> >>>> AFG Function Id: 0x1 (unsol 1)
> >> >>>> Vendor Id: 0x10ec0269
> >> >>>> Subsystem Id: 0x1179fa22
> >> >>>> Revision Id: 0x100100
> >> >>>> No Modem Function Group found
> >> >>>> Default PCM:
> >> >>>> N/A
> >> >>>> Default Amp-In caps: N/A
> >> >>>> Default Amp-Out caps: N/A
> >> >>>> State of AFG node 0x01:
> >> >>>>   Power: setting=UNKNOWN, actual=UNKNOWN, Error, Clock-stop-OK,
> Setting-reset
> >> >>>> Invalid AFG subtree
> >>
> >>
>



-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Okay, I added those lines to a clone of tiwai's repo.
> Output of alsa-info.sh :
https://gist.github.com/Yomi0/f4059fe45d960f141b33#file-rpatch
>

Try hdajacksensetest -a when you plugged and unplugged HP and mic

Did headphone playback volume change to minimum when you plug and unplug ?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/pci/hda/patch_realtek.c?qt=grep&q=toshiba

Seem no specifc hack used by other toshiba

Simple mixer control 'Headphone',0
  Capabilities: pvolume pswitch
  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]

control.14 {
iface CARD
name 'Mic Jack'
value true
comment {
access read
type BOOLEAN
count 1
}
}

control.16 {
iface CARD
name 'Headphone Jack'
value false
comment {
access read
type BOOLEAN
count 1
}
}

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Nothing changes when I plug in or unplug my headphones. The output of
hdajacksensetest stays the same.
However, in alsamixer, the level of Internal Mic Boost goes from 20 to
zero, and Mic Boost goes to 20.

Output of hdajacksensetest:

Pin 0x03 ( Digital Out, HDMI): present = No
Pin 0x05 (Not connected): present = No
Pin 0x07 (Not connected): present = No


On Fri, Apr 10, 2015 at 9:18 AM, Raymond Yau <superquad.vortex2@gmail.com>
wrote:

> >
> > Okay, I added those lines to a clone of tiwai's repo.
> > Output of alsa-info.sh :
> https://gist.github.com/Yomi0/f4059fe45d960f141b33#file-rpatch
> >
>
> Try hdajacksensetest -a when you plugged and unplugged HP and mic
>
> Did headphone playback volume change to minimum when you plug and unplug ?
>
>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/pci/hda/patch_realtek.c?qt=grep&q=toshiba
>
> Seem no specifc hack used by other toshiba
>
> Simple mixer control 'Headphone',0
>   Capabilities: pvolume pswitch
>   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]
>
> control.14 {
> iface CARD
> name 'Mic Jack'
> value true
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
>
> control.16 {
> iface CARD
> name 'Headphone Jack'
> value false
> comment {
> access read
> type BOOLEAN
> count 1
> }
> }
>



-- 
*Yomi*

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Nothing changes when I plug in or unplug my headphones. The output of
hdajacksensetest stays the same.
> However, in alsamixer, the level of Internal Mic Boost goes from 20 to
zero, and Mic Boost goes to 20.
>
> Output of hdajacksensetest:
>
> Pin 0x03 ( Digital Out, HDMI): present = No
> Pin 0x05 (Not connected): present = No
> Pin 0x07 (Not connected): present = No

This seem to be your HDMI codec

You need to specify card 1 when you run hdajacksensetest since option "-a"
just mean all pin complex instead of all cards

hdaudioC1D0: autoconfig for ALC269VB: line_outs=1 (0x14/0x0/0x0/0x0/0x0)
type:speaker
hdaudioC1D0:    speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
hdaudioC1D0:    hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
hdaudioC1D0:    mono: mono_out=0x0
hdaudioC1D0:    inputs:
hdaudioC1D0:      Mic=0x18
hdaudioC1D0:      Internal Mic=0x12

You have to post three outputs: no jacks plugged, headphone plugged and mic
jack plugged

>
>
> On Fri, Apr 10, 2015 at 9:18 AM, Raymond Yau <superquad.vortex2@gmail.com>
wrote:
>>
>> >
>> > Okay, I added those lines to a clone of tiwai's repo.
>> > Output of alsa-info.sh :
https://gist.github.com/Yomi0/f4059fe45d960f141b33#file-rpatch
>> >
>>
>> Try hdajacksensetest -a when you plugged and unplugged HP and mic
>>
>> Did headphone playback volume change to minimum when you plug and unplug
?
>>
>>
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/log/sound/pci/hda/patch_realtek.c?qt=grep&q=toshiba
>>
>> Seem no specifc hack used by other toshiba
>>
>> Simple mixer control 'Headphone',0
>>   Capabilities: pvolume pswitch
>>   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]
>>
>> control.14 {
>> iface CARD
>> name 'Mic Jack'
>> value true
>> comment {
>> access read
>> type BOOLEAN
>> count 1
>> }
>> }
>>
>> control.16 {
>> iface CARD
>> name 'Headphone Jack'
>> value false
>> comment {
>> access read
>> type BOOLEAN
>> count 1
>> }
>> }
>
>
>

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Nothing changes when I plug in or unplug my headphones. The output of
hdajacksensetest stays the same.
> However, in alsamixer, the level of Internal Mic Boost goes from 20 to
zero, and Mic Boost goes to 20.

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=531d8791accf1464bc6854ff69d08dd866189d17

May be HP  need to connect to DAC at node 0x03 for alc269vb

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Okay, I added those lines to a clone of tiwai's repo.
> Output of alsa-info.sh :
https://gist.github.com/Yomi0/f4059fe45d960f141b33#file-rpatch
>
>

If the problem still exist but the jack state are correct after you run
hdajacksensetest

You need to specify spec->primary_hp=0 for those alc269vb which force the
driver to assign dac 0x02 to speaker first and dac 0x03 to headphone since
it was hardcoded in this patch

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=531d8791accf1464bc6854ff69d08dd866189d17

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

Headphones unplugged.
[11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
[sudo] password for yomi:
Pin 0x18 (Black Mic, Right side): present = No
Pin 0x21 (Black Headphone, Right side): present = No

Headphones plugged in.
[11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
Pin 0x18 (Black Mic, Right side): present = Yes
Pin 0x21 (Black Headphone, Right side): present = No

That's odd. It seems to detect my headphones as being plugged into the Mic
jack. It isn't. It is plugged into the headphone jack. I checked.
Haha. If I plug my headphones into the Mic Jack...alsamixer correctly mutes
the speakers and raises the volume of the headphones output.

Headphones plugged into Mic Jack.
[11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
[sudo] password for yomi:
Pin 0x18 (Black Mic, Right side): present = Yes
Pin 0x21 (Black Headphone, Right side): present = Yes

On Sat, Apr 11, 2015 at 3:07 AM, Raymond Yau <superquad.vortex2@gmail.com>
wrote:

> >
> > Okay, I added those lines to a clone of tiwai's repo.
> > Output of alsa-info.sh :
> https://gist.github.com/Yomi0/f4059fe45d960f141b33#file-rpatch
> >
> >
>
> If the problem still exist but the jack state are correct after you run
> hdajacksensetest
>
> You need to specify spec->primary_hp=0 for those alc269vb which force the
> driver to assign dac 0x02 to speaker first and dac 0x03 to headphone since
> it was hardcoded in this patch
>
>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda?id=531d8791accf1464bc6854ff69d08dd866189d17
>
>



-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Headphones unplugged.
> [11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
> [sudo] password for yomi:
> Pin 0x18 (Black Mic, Right side): present = No
> Pin 0x21 (Black Headphone, Right side): present = No
>
> Headphones plugged in.
> [11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
> Pin 0x18 (Black Mic, Right side): present = Yes
> Pin 0x21 (Black Headphone, Right side): present = No
>
> That's odd. It seems to detect my headphones as being plugged into the
Mic jack. It isn't. It is plugged into the headphone jack. I checked.
> Haha. If I plug my headphones into the Mic Jack...alsamixer correctly
mutes the speakers and raises the volume of the headphones output.
>
> Headphones plugged into Mic Jack.
> [11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
> [sudo] password for yomi:
> Pin 0x18 (Black Mic, Right side): present = Yes
> Pin 0x21 (Black Headphone, Right side): present = Yes

It is quite strange that jack state are exchanged since pincap of 0x18 does
not support HP and node 0x21 does not support IN , you cannot exchange the
usage of these two jacks by retasking

Did your laptop sound  work with previous version or other os ?

How about disable jack detect using hint jack_detect=0 ?

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio.txt

you have to select mic jack using capture source and manually mute the
speaket
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

I don't think I've disabled anything.

• Yomi
On Apr 12, 2015 12:31 PM, "Raymond Yau" <superquad.vortex2@gmail.com> wrote:

> >
> > I'm not sure if it worked with pervious kernel versions. There was a
> time I rolled back earlier kernel versions — The result was the same, it
> didn't work.
> >
> > It might have worked with Windows 8, but I had installed Arch soon after
> obtaining the laptop.
>
> >Second. When I plug in these headphones, I can't use the internal
> microphone on this laptop, it mutes. (AFAICT) These headphones do not have
> a microphone built in, they're just an ordinary pair of headphones.
> However, I was given a workaround in #alsa on freenode. In order to use the
> laptop's internal microphone with my headphones plugged in, I have to do :
> sudo hda-verb /dev/snd/hwC1D0 0x22 SET_CONNECT_SEL 6 — it works, but it
> isn't really ideal.
>
> 0x22 [Audio Selector] wcaps 0x30010b: Stereo Amp-In
>   Amp-In caps: N/A
>   Amp-In vals:  [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00 0x00] [0x00
> 0x00] [0x00 0x00] [0x00 0x00]
>   Connection: 7
>      0x18 0x19 0x1a 0x1b 0x1d 0x0b 0x12*
>
> Do you mean disable jack detection cannot work around this jack detection
> fault ?
>
> Using hda-emu,  the driver seem select internal mic when jack detection is
> disabled on startup
>
> >>
> >> How about disable jack detect using hint jack_detect=0 ?
> >>
> >>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/Documentation/sound/alsa/HD-Audio.txt
> >>
> >> you have to select mic jack using capture source and manually mute the
> speaket
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Raymond Yau]

>
> Headphones unplugged.
> [11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
> [sudo] password for yomi:
> Pin 0x18 (Black Mic, Right side): present = No
> Pin 0x21 (Black Headphone, Right side): present = No
>
> Headphones plugged in.
> [11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
> Pin 0x18 (Black Mic, Right side): present = Yes
> Pin 0x21 (Black Headphone, Right side): present = No
>
> That's odd. It seems to detect my headphones as being plugged into the
Mic jack. It isn't. It is plugged into the headphone jack. I checked.
> Haha. If I plug my headphones into the Mic Jack...alsamixer correctly
mutes the speakers and raises the volume of the headphones output.
>
> Headphones plugged into Mic Jack.
> [11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
./hdajacksensetest -c 1
> [sudo] password for yomi:
> Pin 0x18 (Black Mic, Right side): present = Yes
> Pin 0x21 (Black Headphone, Right side): present = Yes

Do you mean headphone and mic work as expected only when both are plugged
and always fail when headphone or mic is plugged ?

Look  like jack sense circuit of hp and mic are swapped

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_jack.c

The current implementation assume kctl return jack state of  the
corresponding pin complex

Can two pins use the other pin as the gated jack at same time ?
snd_hda_jack_set_gating_jack()

ALSA: hda - Allow jack state to depend on another jack

https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_jack.c?id=0619ba8c17b121ef0273be181198659b17d84247

your case seem not just need to  swap the result return by read_pin_sense()

     switch(nid){
     case 0x18:
             val = snd_hda_codec_read(codec, 0x21, 0,
  AC_VERB_GET_PIN_SENSE, 0);
             break;
     case 0x21
             val = snd_hda_codec_read(codec, 0x18, 0,
  AC_VERB_GET_PIN_SENSE, 0);
             break;
     default:
           val = snd_hda_codec_read(codec, nid, 0,
  AC_VERB_GET_PIN_SENSE, 0);
              break;
     }

but also swap the unsolicited event tag on those two pin complex since the
driver use jack->tag to determine pin complex

snd_hda_codec_write_cache(codec, nid, 0,
AC_VERB_SET_UNSOLICITED_ENABLE,
AC_USRSP_EN | jack->tag);

Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
  Control: name="Mic Boost Volume", index=0, device=0
    ControlAmp: chs=3, dir=In, idx=0, ofs=0
  Control: name="Mic Jack", index=0, device=0
  Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
  Amp-In vals:  [0x01 0x01]
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x00001734: IN OUT Detect
    Vref caps: HIZ 50 GRD 80
  Pin Default 0x04a11030: [Jack] Mic at Ext Right
    Conn = 1/8, Color = Black
    DefAssociation = 0x3, Sequence = 0x0
  Pin-ctls: 0x24: IN VREF_80
  Unsolicited: tag=02, enabled=1
  Connection: 1
     0x0d

Node 0x21 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
  Control: name="Headphone Playback Switch", index=0, device=0
    ControlAmp: chs=3, dir=Out, idx=0, ofs=0
  Control: name="Headphone Jack", index=0, device=0
  Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
  Amp-Out vals:  [0x80 0x80]
  Pincap 0x0000001c: OUT HP Detect
  Pin Default 0x04211020: [Jack] HP Out at Ext Right
    Conn = 1/8, Color = Black
    DefAssociation = 0x2, Sequence = 0x0
  Pin-ctls: 0xc0: OUT HP
  Unsolicited: tag=01, enabled=1
  Connection: 2
     0x0c* 0x0dp
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

I should have elaborated a bit more on the result of the last case.

No, when I plug in the headphones into the Microphone jack, the headphones
do not work at all. (which makes sense, because it's a mic jack...it would
be expecting a mic, right?)

While alsamixer will correctly raise the headphone output and mute the
speakers (when I plugged the headphones into the mic jack) — no sound comes
through the headphones.

Just to avoid any possible confusion...

Are those more changes I should make to the code?

Headphones unplugged.
Pin 0x18 (Black Mic, Right side): present = No
Pin 0x21 (Black Headphone, Right side): present = No

Headphones plugged into Headphone port.
Pin 0x18 (Black Mic, Right side): present = Yes
Pin 0x21 (Black Headphone, Right side): present = No

Headphones plugged into Mic port.
Pin 0x18 (Black Mic, Right side): present = Yes
Pin 0x21 (Black Headphone, Right side): present = Yes

On Mon, Apr 13, 2015 at 9:20 PM, Raymond Yau <superquad.vortex2@gmail.com>
wrote:

> >
> > Headphones unplugged.
> > [11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
> ./hdajacksensetest -c 1
> > [sudo] password for yomi:
> > Pin 0x18 (Black Mic, Right side): present = No
> > Pin 0x21 (Black Headphone, Right side): present = No
> >
> > Headphones plugged in.
> > [11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
> ./hdajacksensetest -c 1
> > Pin 0x18 (Black Mic, Right side): present = Yes
> > Pin 0x21 (Black Headphone, Right side): present = No
> >
> > That's odd. It seems to detect my headphones as being plugged into the
> Mic jack. It isn't. It is plugged into the headphone jack. I checked.
> > Haha. If I plug my headphones into the Mic Jack...alsamixer correctly
> mutes the speakers and raises the volume of the headphones output.
> >
> > Headphones plugged into Mic Jack.
> > [11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
> ./hdajacksensetest -c 1
> > [sudo] password for yomi:
> > Pin 0x18 (Black Mic, Right side): present = Yes
> > Pin 0x21 (Black Headphone, Right side): present = Yes
>
> Do you mean headphone and mic work as expected only when both are plugged
> and always fail when headphone or mic is plugged ?
>
> Look  like jack sense circuit of hp and mic are swapped
>
>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_jack.c
>
> The current implementation assume kctl return jack state of  the
> corresponding pin complex
>
> Can two pins use the other pin as the gated jack at same time ?
> snd_hda_jack_set_gating_jack()
>
> ALSA: hda - Allow jack state to depend on another jack
>
>
> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_jack.c?id=0619ba8c17b121ef0273be181198659b17d84247
>
> your case seem not just need to  swap the result return by read_pin_sense()
>
>      switch(nid){
>      case 0x18:
>              val = snd_hda_codec_read(codec, 0x21, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>              break;
>      case 0x21
>              val = snd_hda_codec_read(codec, 0x18, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>              break;
>      default:
>            val = snd_hda_codec_read(codec, nid, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>               break;
>      }
>
> but also swap the unsolicited event tag on those two pin complex since the
> driver use jack->tag to determine pin complex
>
> snd_hda_codec_write_cache(codec, nid, 0,
> AC_VERB_SET_UNSOLICITED_ENABLE,
> AC_USRSP_EN | jack->tag);
>
> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>   Control: name="Mic Boost Volume", index=0, device=0
>     ControlAmp: chs=3, dir=In, idx=0, ofs=0
>   Control: name="Mic Jack", index=0, device=0
>   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
>   Amp-In vals:  [0x01 0x01]
>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>   Amp-Out vals:  [0x80 0x80]
>   Pincap 0x00001734: IN OUT Detect
>     Vref caps: HIZ 50 GRD 80
>   Pin Default 0x04a11030: [Jack] Mic at Ext Right
>     Conn = 1/8, Color = Black
>     DefAssociation = 0x3, Sequence = 0x0
>   Pin-ctls: 0x24: IN VREF_80
>   Unsolicited: tag=02, enabled=1
>   Connection: 1
>      0x0d
>
> Node 0x21 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
>   Control: name="Headphone Playback Switch", index=0, device=0
>     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
>   Control: name="Headphone Jack", index=0, device=0
>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>   Amp-Out vals:  [0x80 0x80]
>   Pincap 0x0000001c: OUT HP Detect
>   Pin Default 0x04211020: [Jack] HP Out at Ext Right
>     Conn = 1/8, Color = Black
>     DefAssociation = 0x2, Sequence = 0x0
>   Pin-ctls: 0xc0: OUT HP
>   Unsolicited: tag=01, enabled=1
>   Connection: 2
>      0x0c* 0x0dp
>



-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

What exactly am I changing here?

switch(nid){
     case 0x18:
             val = snd_hda_codec_read(codec, 0x21, 0,
  AC_VERB_GET_PIN_SENSE, 0);
             break;
     case 0x21
             val = snd_hda_codec_read(codec, 0x18, 0,
  AC_VERB_GET_PIN_SENSE, 0);
             break;
     default:
           val = snd_hda_codec_read(codec, nid, 0,
  AC_VERB_GET_PIN_SENSE, 0);
              break;
     }
On Apr 13, 2015 9:36 PM, "Yomi Ogunwumi" <abyomi0@gmail.com> wrote:

> I should have elaborated a bit more on the result of the last case.
>
> No, when I plug in the headphones into the Microphone jack, the headphones
> do not work at all. (which makes sense, because it's a mic jack...it would
> be expecting a mic, right?)
>
> While alsamixer will correctly raise the headphone output and mute the
> speakers (when I plugged the headphones into the mic jack) — no sound comes
> through the headphones.
>
> Just to avoid any possible confusion...
>
> Are those more changes I should make to the code?
>
> Headphones unplugged.
> Pin 0x18 (Black Mic, Right side): present = No
> Pin 0x21 (Black Headphone, Right side): present = No
>
> Headphones plugged into Headphone port.
> Pin 0x18 (Black Mic, Right side): present = Yes
> Pin 0x21 (Black Headphone, Right side): present = No
>
> Headphones plugged into Mic port.
> Pin 0x18 (Black Mic, Right side): present = Yes
> Pin 0x21 (Black Headphone, Right side): present = Yes
>
> On Mon, Apr 13, 2015 at 9:20 PM, Raymond Yau <superquad.vortex2@gmail.com>
> wrote:
>
>> >
>> > Headphones unplugged.
>> > [11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>> ./hdajacksensetest -c 1
>> > [sudo] password for yomi:
>> > Pin 0x18 (Black Mic, Right side): present = No
>> > Pin 0x21 (Black Headphone, Right side): present = No
>> >
>> > Headphones plugged in.
>> > [11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>> ./hdajacksensetest -c 1
>> > Pin 0x18 (Black Mic, Right side): present = Yes
>> > Pin 0x21 (Black Headphone, Right side): present = No
>> >
>> > That's odd. It seems to detect my headphones as being plugged into the
>> Mic jack. It isn't. It is plugged into the headphone jack. I checked.
>> > Haha. If I plug my headphones into the Mic Jack...alsamixer correctly
>> mutes the speakers and raises the volume of the headphones output.
>> >
>> > Headphones plugged into Mic Jack.
>> > [11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>> ./hdajacksensetest -c 1
>> > [sudo] password for yomi:
>> > Pin 0x18 (Black Mic, Right side): present = Yes
>> > Pin 0x21 (Black Headphone, Right side): present = Yes
>>
>> Do you mean headphone and mic work as expected only when both are plugged
>> and always fail when headphone or mic is plugged ?
>>
>> Look  like jack sense circuit of hp and mic are swapped
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_jack.c
>>
>> The current implementation assume kctl return jack state of  the
>> corresponding pin complex
>>
>> Can two pins use the other pin as the gated jack at same time ?
>> snd_hda_jack_set_gating_jack()
>>
>> ALSA: hda - Allow jack state to depend on another jack
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_jack.c?id=0619ba8c17b121ef0273be181198659b17d84247
>>
>> your case seem not just need to  swap the result return by
>> read_pin_sense()
>>
>>      switch(nid){
>>      case 0x18:
>>              val = snd_hda_codec_read(codec, 0x21, 0,
>>   AC_VERB_GET_PIN_SENSE, 0);
>>              break;
>>      case 0x21
>>              val = snd_hda_codec_read(codec, 0x18, 0,
>>   AC_VERB_GET_PIN_SENSE, 0);
>>              break;
>>      default:
>>            val = snd_hda_codec_read(codec, nid, 0,
>>   AC_VERB_GET_PIN_SENSE, 0);
>>               break;
>>      }
>>
>> but also swap the unsolicited event tag on those two pin complex since
>> the driver use jack->tag to determine pin complex
>>
>> snd_hda_codec_write_cache(codec, nid, 0,
>> AC_VERB_SET_UNSOLICITED_ENABLE,
>> AC_USRSP_EN | jack->tag);
>>
>> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>>   Control: name="Mic Boost Volume", index=0, device=0
>>     ControlAmp: chs=3, dir=In, idx=0, ofs=0
>>   Control: name="Mic Jack", index=0, device=0
>>   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
>>   Amp-In vals:  [0x01 0x01]
>>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>>   Amp-Out vals:  [0x80 0x80]
>>   Pincap 0x00001734: IN OUT Detect
>>     Vref caps: HIZ 50 GRD 80
>>   Pin Default 0x04a11030: [Jack] Mic at Ext Right
>>     Conn = 1/8, Color = Black
>>     DefAssociation = 0x3, Sequence = 0x0
>>   Pin-ctls: 0x24: IN VREF_80
>>   Unsolicited: tag=02, enabled=1
>>   Connection: 1
>>      0x0d
>>
>> Node 0x21 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
>>   Control: name="Headphone Playback Switch", index=0, device=0
>>     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
>>   Control: name="Headphone Jack", index=0, device=0
>>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>>   Amp-Out vals:  [0x80 0x80]
>>   Pincap 0x0000001c: OUT HP Detect
>>   Pin Default 0x04211020: [Jack] HP Out at Ext Right
>>     Conn = 1/8, Color = Black
>>     DefAssociation = 0x2, Sequence = 0x0
>>   Pin-ctls: 0xc0: OUT HP
>>   Unsolicited: tag=01, enabled=1
>>   Connection: 2
>>      0x0c* 0x0dp
>>
>
>
>
> --
> *Yomi*
>
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

What exactly am I changing in hda_jack.c ?

    switch(nid){
     case 0x18:
             val = snd_hda_codec_read(codec, 0x21, 0,
  AC_VERB_GET_PIN_SENSE, 0);
             break;
     case 0x21
             val = snd_hda_codec_read(codec, 0x18, 0,
  AC_VERB_GET_PIN_SENSE, 0);
             break;
     default:
           val = snd_hda_codec_read(codec, nid, 0,
  AC_VERB_GET_PIN_SENSE, 0);
              break;
     }

snd_hda_codec_write_cache(codec, nid, 0,

AC_VERB_SET_UNSOLICITED_ENABLE,
AC_USRSP_EN | jack->tag);


On Mon, May 11, 2015 at 10:22 AM, Yomi Ogunwumi <abyomi0@gmail.com> wrote:

> What exactly am I changing here?
>
> switch(nid){
>      case 0x18:
>              val = snd_hda_codec_read(codec, 0x21, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>              break;
>      case 0x21
>              val = snd_hda_codec_read(codec, 0x18, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>              break;
>      default:
>            val = snd_hda_codec_read(codec, nid, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>               break;
>      }
> On Apr 13, 2015 9:36 PM, "Yomi Ogunwumi" <abyomi0@gmail.com> wrote:
>
>> I should have elaborated a bit more on the result of the last case.
>>
>> No, when I plug in the headphones into the Microphone jack, the
>> headphones do not work at all. (which makes sense, because it's a mic
>> jack...it would be expecting a mic, right?)
>>
>> While alsamixer will correctly raise the headphone output and mute the
>> speakers (when I plugged the headphones into the mic jack) — no sound comes
>> through the headphones.
>>
>> Just to avoid any possible confusion...
>>
>> Are those more changes I should make to the code?
>>
>> Headphones unplugged.
>> Pin 0x18 (Black Mic, Right side): present = No
>> Pin 0x21 (Black Headphone, Right side): present = No
>>
>> Headphones plugged into Headphone port.
>> Pin 0x18 (Black Mic, Right side): present = Yes
>> Pin 0x21 (Black Headphone, Right side): present = No
>>
>> Headphones plugged into Mic port.
>> Pin 0x18 (Black Mic, Right side): present = Yes
>> Pin 0x21 (Black Headphone, Right side): present = Yes
>>
>> On Mon, Apr 13, 2015 at 9:20 PM, Raymond Yau <superquad.vortex2@gmail.com
>> > wrote:
>>
>>> >
>>> > Headphones unplugged.
>>> > [11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>>> ./hdajacksensetest -c 1
>>> > [sudo] password for yomi:
>>> > Pin 0x18 (Black Mic, Right side): present = No
>>> > Pin 0x21 (Black Headphone, Right side): present = No
>>> >
>>> > Headphones plugged in.
>>> > [11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>>> ./hdajacksensetest -c 1
>>> > Pin 0x18 (Black Mic, Right side): present = Yes
>>> > Pin 0x21 (Black Headphone, Right side): present = No
>>> >
>>> > That's odd. It seems to detect my headphones as being plugged into the
>>> Mic jack. It isn't. It is plugged into the headphone jack. I checked.
>>> > Haha. If I plug my headphones into the Mic Jack...alsamixer correctly
>>> mutes the speakers and raises the volume of the headphones output.
>>> >
>>> > Headphones plugged into Mic Jack.
>>> > [11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>>> ./hdajacksensetest -c 1
>>> > [sudo] password for yomi:
>>> > Pin 0x18 (Black Mic, Right side): present = Yes
>>> > Pin 0x21 (Black Headphone, Right side): present = Yes
>>>
>>> Do you mean headphone and mic work as expected only when both are
>>> plugged and always fail when headphone or mic is plugged ?
>>>
>>> Look  like jack sense circuit of hp and mic are swapped
>>>
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_jack.c
>>>
>>> The current implementation assume kctl return jack state of  the
>>> corresponding pin complex
>>>
>>> Can two pins use the other pin as the gated jack at same time ?
>>> snd_hda_jack_set_gating_jack()
>>>
>>> ALSA: hda - Allow jack state to depend on another jack
>>>
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_jack.c?id=0619ba8c17b121ef0273be181198659b17d84247
>>>
>>> your case seem not just need to  swap the result return by
>>> read_pin_sense()
>>>
>>>      switch(nid){
>>>      case 0x18:
>>>              val = snd_hda_codec_read(codec, 0x21, 0,
>>>   AC_VERB_GET_PIN_SENSE, 0);
>>>              break;
>>>      case 0x21
>>>              val = snd_hda_codec_read(codec, 0x18, 0,
>>>   AC_VERB_GET_PIN_SENSE, 0);
>>>              break;
>>>      default:
>>>            val = snd_hda_codec_read(codec, nid, 0,
>>>   AC_VERB_GET_PIN_SENSE, 0);
>>>               break;
>>>      }
>>>
>>> but also swap the unsolicited event tag on those two pin complex since
>>> the driver use jack->tag to determine pin complex
>>>
>>> snd_hda_codec_write_cache(codec, nid, 0,
>>> AC_VERB_SET_UNSOLICITED_ENABLE,
>>> AC_USRSP_EN | jack->tag);
>>>
>>> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>>>   Control: name="Mic Boost Volume", index=0, device=0
>>>     ControlAmp: chs=3, dir=In, idx=0, ofs=0
>>>   Control: name="Mic Jack", index=0, device=0
>>>   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
>>>   Amp-In vals:  [0x01 0x01]
>>>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>>>   Amp-Out vals:  [0x80 0x80]
>>>   Pincap 0x00001734: IN OUT Detect
>>>     Vref caps: HIZ 50 GRD 80
>>>   Pin Default 0x04a11030: [Jack] Mic at Ext Right
>>>     Conn = 1/8, Color = Black
>>>     DefAssociation = 0x3, Sequence = 0x0
>>>   Pin-ctls: 0x24: IN VREF_80
>>>   Unsolicited: tag=02, enabled=1
>>>   Connection: 1
>>>      0x0d
>>>
>>> Node 0x21 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
>>>   Control: name="Headphone Playback Switch", index=0, device=0
>>>     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
>>>   Control: name="Headphone Jack", index=0, device=0
>>>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>>>   Amp-Out vals:  [0x80 0x80]
>>>   Pincap 0x0000001c: OUT HP Detect
>>>   Pin Default 0x04211020: [Jack] HP Out at Ext Right
>>>     Conn = 1/8, Color = Black
>>>     DefAssociation = 0x2, Sequence = 0x0
>>>   Pin-ctls: 0xc0: OUT HP
>>>   Unsolicited: tag=01, enabled=1
>>>   Connection: 2
>>>      0x0c* 0x0dp
>>>
>>
>>
>>
>> --
>> *Yomi*
>>
>


-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Re: Issues and/or possible bugs in alsa

[Yomi Ogunwumi]

I know I've been silent for awhile, finals came around the same time I was
also attempting to get help resolving this.
It wasn't that I lost interest, I just had other things to focus on. I
understand that it probably wasn't in my best interest to go silent if I
wanted to fix this.
I'm still interested in fixing this. Is anyone still willing to help?

On Tue, May 19, 2015 at 8:57 PM, Yomi Ogunwumi <abyomi0@gmail.com> wrote:

> What exactly am I changing in hda_jack.c ?
>
>     switch(nid){
>      case 0x18:
>              val = snd_hda_codec_read(codec, 0x21, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>              break;
>      case 0x21
>              val = snd_hda_codec_read(codec, 0x18, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>              break;
>      default:
>            val = snd_hda_codec_read(codec, nid, 0,
>   AC_VERB_GET_PIN_SENSE, 0);
>               break;
>      }
>
> snd_hda_codec_write_cache(codec, nid, 0,
>
> AC_VERB_SET_UNSOLICITED_ENABLE,
> AC_USRSP_EN | jack->tag);
>
>
> On Mon, May 11, 2015 at 10:22 AM, Yomi Ogunwumi <abyomi0@gmail.com> wrote:
>
>> What exactly am I changing here?
>>
>> switch(nid){
>>      case 0x18:
>>              val = snd_hda_codec_read(codec, 0x21, 0,
>>   AC_VERB_GET_PIN_SENSE, 0);
>>              break;
>>      case 0x21
>>              val = snd_hda_codec_read(codec, 0x18, 0,
>>   AC_VERB_GET_PIN_SENSE, 0);
>>              break;
>>      default:
>>            val = snd_hda_codec_read(codec, nid, 0,
>>   AC_VERB_GET_PIN_SENSE, 0);
>>               break;
>>      }
>> On Apr 13, 2015 9:36 PM, "Yomi Ogunwumi" <abyomi0@gmail.com> wrote:
>>
>>> I should have elaborated a bit more on the result of the last case.
>>>
>>> No, when I plug in the headphones into the Microphone jack, the
>>> headphones do not work at all. (which makes sense, because it's a mic
>>> jack...it would be expecting a mic, right?)
>>>
>>> While alsamixer will correctly raise the headphone output and mute the
>>> speakers (when I plugged the headphones into the mic jack) — no sound comes
>>> through the headphones.
>>>
>>> Just to avoid any possible confusion...
>>>
>>> Are those more changes I should make to the code?
>>>
>>> Headphones unplugged.
>>> Pin 0x18 (Black Mic, Right side): present = No
>>> Pin 0x21 (Black Headphone, Right side): present = No
>>>
>>> Headphones plugged into Headphone port.
>>> Pin 0x18 (Black Mic, Right side): present = Yes
>>> Pin 0x21 (Black Headphone, Right side): present = No
>>>
>>> Headphones plugged into Mic port.
>>> Pin 0x18 (Black Mic, Right side): present = Yes
>>> Pin 0x21 (Black Headphone, Right side): present = Yes
>>>
>>> On Mon, Apr 13, 2015 at 9:20 PM, Raymond Yau <
>>> superquad.vortex2@gmail.com> wrote:
>>>
>>>> >
>>>> > Headphones unplugged.
>>>> > [11:10:44 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>>>> ./hdajacksensetest -c 1
>>>> > [sudo] password for yomi:
>>>> > Pin 0x18 (Black Mic, Right side): present = No
>>>> > Pin 0x21 (Black Headphone, Right side): present = No
>>>> >
>>>> > Headphones plugged in.
>>>> > [11:10:50 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>>>> ./hdajacksensetest -c 1
>>>> > Pin 0x18 (Black Mic, Right side): present = Yes
>>>> > Pin 0x21 (Black Headphone, Right side): present = No
>>>> >
>>>> > That's odd. It seems to detect my headphones as being plugged into
>>>> the Mic jack. It isn't. It is plugged into the headphone jack. I checked.
>>>> > Haha. If I plug my headphones into the Mic Jack...alsamixer correctly
>>>> mutes the speakers and raises the volume of the headphones output.
>>>> >
>>>> > Headphones plugged into Mic Jack.
>>>> > [11:11:08 | yomi@xana ~/software/alsa-tools/hdajacksensetest] » sudo
>>>> ./hdajacksensetest -c 1
>>>> > [sudo] password for yomi:
>>>> > Pin 0x18 (Black Mic, Right side): present = Yes
>>>> > Pin 0x21 (Black Headphone, Right side): present = Yes
>>>>
>>>> Do you mean headphone and mic work as expected only when both are
>>>> plugged and always fail when headphone or mic is plugged ?
>>>>
>>>> Look  like jack sense circuit of hp and mic are swapped
>>>>
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/tree/sound/pci/hda/hda_jack.c
>>>>
>>>> The current implementation assume kctl return jack state of  the
>>>> corresponding pin complex
>>>>
>>>> Can two pins use the other pin as the gated jack at same time ?
>>>> snd_hda_jack_set_gating_jack()
>>>>
>>>> ALSA: hda - Allow jack state to depend on another jack
>>>>
>>>>
>>>> https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pci/hda/hda_jack.c?id=0619ba8c17b121ef0273be181198659b17d84247
>>>>
>>>> your case seem not just need to  swap the result return by
>>>> read_pin_sense()
>>>>
>>>>      switch(nid){
>>>>      case 0x18:
>>>>              val = snd_hda_codec_read(codec, 0x21, 0,
>>>>   AC_VERB_GET_PIN_SENSE, 0);
>>>>              break;
>>>>      case 0x21
>>>>              val = snd_hda_codec_read(codec, 0x18, 0,
>>>>   AC_VERB_GET_PIN_SENSE, 0);
>>>>              break;
>>>>      default:
>>>>            val = snd_hda_codec_read(codec, nid, 0,
>>>>   AC_VERB_GET_PIN_SENSE, 0);
>>>>               break;
>>>>      }
>>>>
>>>> but also swap the unsolicited event tag on those two pin complex since
>>>> the driver use jack->tag to determine pin complex
>>>>
>>>> snd_hda_codec_write_cache(codec, nid, 0,
>>>> AC_VERB_SET_UNSOLICITED_ENABLE,
>>>> AC_USRSP_EN | jack->tag);
>>>>
>>>> Node 0x18 [Pin Complex] wcaps 0x40018f: Stereo Amp-In Amp-Out
>>>>   Control: name="Mic Boost Volume", index=0, device=0
>>>>     ControlAmp: chs=3, dir=In, idx=0, ofs=0
>>>>   Control: name="Mic Jack", index=0, device=0
>>>>   Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x2f, mute=0
>>>>   Amp-In vals:  [0x01 0x01]
>>>>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>>>>   Amp-Out vals:  [0x80 0x80]
>>>>   Pincap 0x00001734: IN OUT Detect
>>>>     Vref caps: HIZ 50 GRD 80
>>>>   Pin Default 0x04a11030: [Jack] Mic at Ext Right
>>>>     Conn = 1/8, Color = Black
>>>>     DefAssociation = 0x3, Sequence = 0x0
>>>>   Pin-ctls: 0x24: IN VREF_80
>>>>   Unsolicited: tag=02, enabled=1
>>>>   Connection: 1
>>>>      0x0d
>>>>
>>>> Node 0x21 [Pin Complex] wcaps 0x40018d: Stereo Amp-Out
>>>>   Control: name="Headphone Playback Switch", index=0, device=0
>>>>     ControlAmp: chs=3, dir=Out, idx=0, ofs=0
>>>>   Control: name="Headphone Jack", index=0, device=0
>>>>   Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1
>>>>   Amp-Out vals:  [0x80 0x80]
>>>>   Pincap 0x0000001c: OUT HP Detect
>>>>   Pin Default 0x04211020: [Jack] HP Out at Ext Right
>>>>     Conn = 1/8, Color = Black
>>>>     DefAssociation = 0x2, Sequence = 0x0
>>>>   Pin-ctls: 0xc0: OUT HP
>>>>   Unsolicited: tag=01, enabled=1
>>>>   Connection: 2
>>>>      0x0c* 0x0dp
>>>>
>>>
>>>
>>>
>>> --
>>> *Yomi*
>>>
>>
>
>
> --
> *Yomi*
>



-- 
*Yomi*
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel