[alsa-devel] Fixing EAPD for STAC9202 on an embedded platform.
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
Here is the alsa-info output from both the crackling kernel 4.14 and the working-just-fine kernel 3.18.
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6
I don't have sufficient knowledge of ALSA drivers and patches and have been working purely from the configurations used by others over the years, so I would really appreciate somebody looking at the alsa-info output and the new patch to determine where I should go from here. I believe this is all to do with EAPD control, but what options I have for controlling that aren't known to me right now.
Ideally, I want to end up with the audio muting and switching correctly when the jack is inserted. A bonus would be to lose the unused (or at least inaccessible) audio input and output options in alsamixer and gain individual control of the internal speaker and line out levels (which appear to be paired together at the moment).
All the best,
A.
On Mon, 10 Sep 2018 11:51:52 +0200, Andy Davison wrote:
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
The patch looks changing too much than needed.
What exactly do you need to make things working at first? patch_stac925x() sets own_eapd_ctl, but only from some historical reason. You can unset this flag in the quirk as well.
Takashi
Here is the alsa-info output from both the crackling kernel 4.14 and the working-just-fine kernel 3.18.
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6
I don't have sufficient knowledge of ALSA drivers and patches and have been working purely from the configurations used by others over the years, so I would really appreciate somebody looking at the alsa-info output and the new patch to determine where I should go from here. I believe this is all to do with EAPD control, but what options I have for controlling that aren't known to me right now.
Ideally, I want to end up with the audio muting and switching correctly when the jack is inserted. A bonus would be to lose the unused (or at least inaccessible) audio input and output options in alsamixer and gain individual control of the internal speaker and line out levels (which appear to be paired together at the moment).
All the best,
A.-- Andrew Davison
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 10 Sep 2018, at 16:31, Takashi Iwai wrote:
On Mon, 10 Sep 2018 11:51:52 +0200, Andy Davison wrote:
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
The patch looks changing too much than needed.
What exactly do you need to make things working at first? patch_stac925x() sets own_eapd_ctl, but only from some historical reason. You can unset this flag in the quirk as well.
Thank you for getting back to me. I have recompiled 4.14.69 with no audio patches and the result is as follows:
- Switching: Presence or absence of line out / headphones is ignored.
- Auto-Mute Enabled (Default): Crackling is present on the right channel only of line out / headphones. No audio on line out / headphones. Speaker plays audio.
- Auto-Mute Disabled: Audio plays properly, but from both the speaker and line out / headphones simultaneously.
So it would seem the action of EAPD is reversed, muting the line out / headphones when they’re attached and not the internal speaker. The crackling remains, but strangely just in that right channel of line out / headphones.
The alsa-info output is:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
I then tried simply setting own_eapd_ctl = 0. It made no functional difference that I could tell, but alsa-info became this:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
As you can probably tell, I’m in the dark with what to do next. I would greatly appreciate suggestions.
Here is the alsa-info output from both the crackling kernel 4.14 and the working-just-fine kernel 3.18.
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6
I don't have sufficient knowledge of ALSA drivers and patches and have been working purely from the configurations used by others over the years, so I would really appreciate somebody looking at the alsa-info output and the new patch to determine where I should go from here. I believe this is all to do with EAPD control, but what options I have for controlling that aren't known to me right now.
Ideally, I want to end up with the audio muting and switching correctly when the jack is inserted. A bonus would be to lose the unused (or at least inaccessible) audio input and output options in alsamixer and gain individual control of the internal speaker and line out levels (which appear to be paired together at the moment).
On Mon, 10 Sep 2018 22:01:28 +0200, Andy Davison wrote:
On 10 Sep 2018, at 16:31, Takashi Iwai wrote:
On Mon, 10 Sep 2018 11:51:52 +0200, Andy Davison wrote:
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
The patch looks changing too much than needed.
What exactly do you need to make things working at first? patch_stac925x() sets own_eapd_ctl, but only from some historical reason. You can unset this flag in the quirk as well.
Thank you for getting back to me. I have recompiled 4.14.69 with no audio patches and the result is as follows:
Switching: Presence or absence of line out / headphones is ignored.
Auto-Mute Enabled (Default): Crackling is present on the right channel only of line out / headphones. No audio on line out / headphones. Speaker plays audio.
Auto-Mute Disabled: Audio plays properly, but from both the speaker and line out / headphones simultaneously.
So it would seem the action of EAPD is reversed, muting the line out / headphones when they’re attached and not the internal speaker. The crackling remains, but strangely just in that right channel of line out / headphones.
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin? Does the standard jack detection mechanism work for them individually?
Let's start from that.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Takashi
The alsa-info output is:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
I then tried simply setting own_eapd_ctl = 0. It made no functional difference that I could tell, but alsa-info became this:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
As you can probably tell, I’m in the dark with what to do next. I would greatly appreciate suggestions.
Here is the alsa-info output from both the crackling kernel 4.14 and the working-just-fine kernel 3.18.
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6
I don't have sufficient knowledge of ALSA drivers and patches and have been working purely from the configurations used by others over the years, so I would really appreciate somebody looking at the alsa-info output and the new patch to determine where I should go from here. I believe this is all to do with EAPD control, but what options I have for controlling that aren't known to me right now.
Ideally, I want to end up with the audio muting and switching correctly when the jack is inserted. A bonus would be to lose the unused (or at least inaccessible) audio input and output options in alsamixer and gain individual control of the internal speaker and line out levels (which appear to be paired together at the moment).
On 10 Sep 2018, at 21:29, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Sep 2018 22:01:28 +0200, Andy Davison wrote:
On 10 Sep 2018, at 16:31, Takashi Iwai wrote:
On Mon, 10 Sep 2018 11:51:52 +0200, Andy Davison wrote:
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
The patch looks changing too much than needed.
What exactly do you need to make things working at first? patch_stac925x() sets own_eapd_ctl, but only from some historical reason. You can unset this flag in the quirk as well.
Thank you for getting back to me. I have recompiled 4.14.69 with no audio patches and the result is as follows:
Switching: Presence or absence of line out / headphones is ignored.
Auto-Mute Enabled (Default): Crackling is present on the right channel only of line out / headphones. No audio on line out / headphones. Speaker plays audio.
Auto-Mute Disabled: Audio plays properly, but from both the speaker and line out / headphones simultaneously.
So it would seem the action of EAPD is reversed, muting the line out / headphones when they’re attached and not the internal speaker. The crackling remains, but strangely just in that right channel of line out / headphones.
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
That’s a good question.
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
Does the standard jack detection mechanism work for them individually?
Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
Please let me know if there’s any other information that would be useful to figuring this out.
The alsa-info output is:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
I then tried simply setting own_eapd_ctl = 0. It made no functional difference that I could tell, but alsa-info became this:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
As you can probably tell, I’m in the dark with what to do next. I would greatly appreciate suggestions.
Here is the alsa-info output from both the crackling kernel 4.14 and the working-just-fine kernel 3.18.
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6
I don't have sufficient knowledge of ALSA drivers and patches and have been working purely from the configurations used by others over the years, so I would really appreciate somebody looking at the alsa-info output and the new patch to determine where I should go from here. I believe this is all to do with EAPD control, but what options I have for controlling that aren't known to me right now.
Ideally, I want to end up with the audio muting and switching correctly when the jack is inserted. A bonus would be to lose the unused (or at least inaccessible) audio input and output options in alsamixer and gain individual control of the internal speaker and line out levels (which appear to be paired together at the moment).
On Tue, 11 Sep 2018 02:24:11 +0200, Andy Davison wrote:
On 10 Sep 2018, at 21:29, Takashi Iwai tiwai@suse.de wrote:
On Mon, 10 Sep 2018 22:01:28 +0200, Andy Davison wrote:
On 10 Sep 2018, at 16:31, Takashi Iwai wrote:
On Mon, 10 Sep 2018 11:51:52 +0200, Andy Davison wrote:
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
The patch looks changing too much than needed.
What exactly do you need to make things working at first? patch_stac925x() sets own_eapd_ctl, but only from some historical reason. You can unset this flag in the quirk as well.
Thank you for getting back to me. I have recompiled 4.14.69 with no audio patches and the result is as follows:
Switching: Presence or absence of line out / headphones is ignored.
Auto-Mute Enabled (Default): Crackling is present on the right channel only of line out / headphones. No audio on line out / headphones. Speaker plays audio.
Auto-Mute Disabled: Audio plays properly, but from both the speaker and line out / headphones simultaneously.
So it would seem the action of EAPD is reversed, muting the line out / headphones when they’re attached and not the internal speaker. The crackling remains, but strangely just in that right channel of line out / headphones.
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
That’s a good question.
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
I see no patch file. Did you figure out which pin NID is for the line out, which pin NID for headphone, and which for int and ext mics?
You can use hdajackretask program to identify and reprogram the pin configs. At least, the pins for I/O with the actual jacks can be identified with a jack detection (plugging / unplugging).
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
Does the standard jack detection mechanism work for them individually?
Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
The crackling is often because of some bad routing from analog loopback. See whether the loopback is enabled unnecessarily.
Takashi
Please let me know if there’s any other information that would be useful to figuring this out.
The alsa-info output is:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
I then tried simply setting own_eapd_ctl = 0. It made no functional difference that I could tell, but alsa-info became this:
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6#file-4-14-...
As you can probably tell, I’m in the dark with what to do next. I would greatly appreciate suggestions.
Here is the alsa-info output from both the crackling kernel 4.14 and the working-just-fine kernel 3.18.
https://gist.github.com/andydvsn/ccf55e6f7961dd405fc39d41a6ce9ef6
I don't have sufficient knowledge of ALSA drivers and patches and have been working purely from the configurations used by others over the years, so I would really appreciate somebody looking at the alsa-info output and the new patch to determine where I should go from here. I believe this is all to do with EAPD control, but what options I have for controlling that aren't known to me right now.
Ideally, I want to end up with the audio muting and switching correctly when the jack is inserted. A bonus would be to lose the unused (or at least inaccessible) audio input and output options in alsamixer and gain individual control of the internal speaker and line out levels (which appear to be paired together at the moment).
On 11 Sep 2018, at 06:53, Takashi Iwai wrote:
On Tue, 11 Sep 2018 02:24:11 +0200, Andy Davison wrote:
On 10 Sep 2018, at 21:29, Takashi Iwai wrote:
On Mon, 10 Sep 2018 22:01:28 +0200, Andy Davison wrote:
On 10 Sep 2018, at 16:31, Takashi Iwai wrote:
On Mon, 10 Sep 2018 11:51:52 +0200, Andy Davison wrote:
Hi everyone,
I’m hoping that somebody here might be able to spot where I’m going wrong; I'm working with a picture-frame-like device manufactured by the late OpenPeak Inc. known as the OpenFrame (or O2 Joggler in the UK). It has an internal speaker and a 3.5mm line out socket; none of the other connections to its STAC9202 codec chip are exposed to the end user. I've been porting Ubuntu Bionic to the device and everything is done, except for the audio driver.
Back in kernel 3.18 it was possible to use the following kernel patch and userland ALSA patch to have these two outputs work correctly, with the insertion of a plug into the line out properly muting the internal speaker.
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202... https://github.com/andydvsn/OpenFrame-Ubuntu/blob/master/overlay-trusty/lib/...
In kernel 4.14 the same trick no longer works, so I've rewritten the patch to more properly add support for this variant of STAC9202 to ALSA. It now looks like this:
https://gist.github.com/andydvsn/7bffa8de0ed691b14508485d75501ffc
This seems to line up the pin configurations appropriately, but when a plug is inserted to the line out, although the audio to the internal speaker is muted, the speaker emits a crackling sound whenever the device is processing. It seems that it is not being properly powered down and is amplifying general circuit noise. Disconnecting the plug returns sound to the internal speaker and the crackling ceases. This is reliable across multiple devices.
The patch looks changing too much than needed.
What exactly do you need to make things working at first? patch_stac925x() sets own_eapd_ctl, but only from some historical reason. You can unset this flag in the quirk as well.
Thank you for getting back to me. I have recompiled 4.14.69 with no audio patches and the result is as follows:
Switching: Presence or absence of line out / headphones is ignored.
Auto-Mute Enabled (Default): Crackling is present on the right channel only of line out / headphones. No audio on line out / headphones. Speaker plays audio.
Auto-Mute Disabled: Audio plays properly, but from both the speaker and line out / headphones simultaneously.
So it would seem the action of EAPD is reversed, muting the line out / headphones when they’re attached and not the internal speaker. The crackling remains, but strangely just in that right channel of line out / headphones.
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
That’s a good question.
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
I see no patch file. Did you figure out which pin NID is for the line out, which pin NID for headphone, and which for int and ext mics?
For output, from the board it looks as though 0x0a (PORTA_L & PORTA_R) and 0x0d (PORTD_L & PORTD_R) are the only output connections. NID 0x0d looks as though it feeds the internal amplifier; I can’t entirely ascertain the purpose of 0x0a. If I mark 0x0a as not connected in hdajackretask, internal speaker muting stops working, though it appears to lead to an unpopulated area of the board.
Here is the pinout as best I can make out: https://i.imgur.com/lO8hqc8.png
This is the main board (front): https://i.imgur.com/CvYkM7G.jpg
This is the main board (rear): https://i.imgur.com/fYJor9s.jpg
You can use hdajackretask program to identify and reprogram the pin configs. At least, the pins for I/O with the actual jacks can be identified with a jack detection (plugging / unplugging).
This patch makes sense from a labelling perspective, but I’m suspicious that separate HP/LO and internal speaker volumes may not be possible, as if 0x0d feeds the internal amplifier, I assume there is no individual level control.
https://gist.github.com/andydvsn/16bf774d236fdeaa5de22ab0378643c3
As described in the patch, this doesn’t fix the underlying issue of amplified circuit noise through the muted internal speakers. If that could be solved, everything would be working correctly. The kernel 3.18 patch appears to have relied upon 0x07 for this switching, but I’ve had no luck configuring this so far.
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
Does the standard jack detection mechanism work for them individually?
Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
The crackling is often because of some bad routing from analog loopback. See whether the loopback is enabled unnecessarily.
There doesn’t appear to be a loopback entry in alsamixer or amixer, so I’m uncertain on how to check for this.
Thank you for your help, I really want to get to the bottom of this!
All the best,
A.
Hi all,
On 20 Sep 2018, at 02:31, Andy Davison andy@dvsn.net wrote:
[snip]
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
That’s a good question.
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
I see no patch file. Did you figure out which pin NID is for the line out, which pin NID for headphone, and which for int and ext mics?
For output, from the board it looks as though 0x0a (PORTA_L & PORTA_R) and 0x0d (PORTD_L & PORTD_R) are the only output connections. NID 0x0d looks as though it feeds the internal amplifier; I can’t entirely ascertain the purpose of 0x0a. If I mark 0x0a as not connected in hdajackretask, internal speaker muting stops working, though it appears to lead to an unpopulated area of the board.
Here is the pinout as best I can make out: https://i.imgur.com/lO8hqc8.png
This is the main board (front): https://i.imgur.com/CvYkM7G.jpg
This is the main board (rear): https://i.imgur.com/fYJor9s.jpg
You can use hdajackretask program to identify and reprogram the pin configs. At least, the pins for I/O with the actual jacks can be identified with a jack detection (plugging / unplugging).
This patch makes sense from a labelling perspective, but I’m suspicious that separate HP/LO and internal speaker volumes may not be possible, as if 0x0d feeds the internal amplifier, I assume there is no individual level control.
https://gist.github.com/andydvsn/16bf774d236fdeaa5de22ab0378643c3
As described in the patch, this doesn’t fix the underlying issue of amplified circuit noise through the muted internal speakers. If that could be solved, everything would be working correctly. The kernel 3.18 patch appears to have relied upon 0x07 for this switching, but I’ve had no luck configuring this so far.
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
Does the standard jack detection mechanism work for them individually?
Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
The crackling is often because of some bad routing from analog loopback. See whether the loopback is enabled unnecessarily.
There doesn’t appear to be a loopback entry in alsamixer or amixer, so I’m uncertain on how to check for this.
Thank you for your help, I really want to get to the bottom of this!
Is there any more information I can be providing that might help out with resolving this issue? I’ve still had no luck in completely shutting down the output to the internal speakers on this device when a line out is connected, though pin detection for muting is working fine. The audio signal gets muted but the circuit noise crackle appears every time.
From the original patch 0x07 would seem to be involved in this switching, though how I get this working is beyond me.
Thanks again,
A.
On Mon, 01 Oct 2018 02:15:56 +0200, Andy Davison wrote:
Hi all,
On 20 Sep 2018, at 02:31, Andy Davison andy@dvsn.net wrote:
[snip]
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
That’s a good question.
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
I see no patch file. Did you figure out which pin NID is for the line out, which pin NID for headphone, and which for int and ext mics?
For output, from the board it looks as though 0x0a (PORTA_L & PORTA_R) and 0x0d (PORTD_L & PORTD_R) are the only output connections. NID 0x0d looks as though it feeds the internal amplifier; I can’t entirely ascertain the purpose of 0x0a. If I mark 0x0a as not connected in hdajackretask, internal speaker muting stops working, though it appears to lead to an unpopulated area of the board.
Here is the pinout as best I can make out: https://i.imgur.com/lO8hqc8.png
This is the main board (front): https://i.imgur.com/CvYkM7G.jpg
This is the main board (rear): https://i.imgur.com/fYJor9s.jpg
You can use hdajackretask program to identify and reprogram the pin configs. At least, the pins for I/O with the actual jacks can be identified with a jack detection (plugging / unplugging).
This patch makes sense from a labelling perspective, but I’m suspicious that separate HP/LO and internal speaker volumes may not be possible, as if 0x0d feeds the internal amplifier, I assume there is no individual level control.
https://gist.github.com/andydvsn/16bf774d236fdeaa5de22ab0378643c3
As described in the patch, this doesn’t fix the underlying issue of amplified circuit noise through the muted internal speakers. If that could be solved, everything would be working correctly. The kernel 3.18 patch appears to have relied upon 0x07 for this switching, but I’ve had no luck configuring this so far.
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
Does the standard jack detection mechanism work for them individually?
Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
The crackling is often because of some bad routing from analog loopback. See whether the loopback is enabled unnecessarily.
There doesn’t appear to be a loopback entry in alsamixer or amixer, so I’m uncertain on how to check for this.
Thank you for your help, I really want to get to the bottom of this!
Is there any more information I can be providing that might help out with resolving this issue? I’ve still had no luck in completely shutting down the output to the internal speakers on this device when a line out is connected, though pin detection for muting is working fine. The audio signal gets muted but the circuit noise crackle appears every time.
From the original patch 0x07 would seem to be involved in this switching, though how I get this working is beyond me.
Sorry, I've been off for conferences and vacation thereafter, so haven't checked it at all (and almost forgotten).
This might be a repeated text, but, what we need is the (more or less) complete routing of your actual I/Os. Then we can try to enable only the required paths and disable the unnecessary paths by issuing HD-audio verbs on the fly, and check whether this actually works as expected.
That said, we need a "good-working" example of the whole routings, then adjust knobs to achieve this with the auto-parser.
Takashi
On 4 Oct 2018, at 22:09, Takashi Iwai tiwai@suse.de wrote:
On Mon, 01 Oct 2018 02:15:56 +0200, Andy Davison wrote:
Hi all,
On 20 Sep 2018, at 02:31, Andy Davison andy@dvsn.net wrote:
[snip]
Is it really about EAPD, or is it about the jack detection logic or the incorrect pin config?
That’s a good question.
The first item, the missing LO / HP detection rather indicates the pin config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
I see no patch file. Did you figure out which pin NID is for the line out, which pin NID for headphone, and which for int and ext mics?
For output, from the board it looks as though 0x0a (PORTA_L & PORTA_R) and 0x0d (PORTD_L & PORTD_R) are the only output connections. NID 0x0d looks as though it feeds the internal amplifier; I can’t entirely ascertain the purpose of 0x0a. If I mark 0x0a as not connected in hdajackretask, internal speaker muting stops working, though it appears to lead to an unpopulated area of the board.
Here is the pinout as best I can make out: https://i.imgur.com/lO8hqc8.png
This is the main board (front): https://i.imgur.com/CvYkM7G.jpg
This is the main board (rear): https://i.imgur.com/fYJor9s.jpg
You can use hdajackretask program to identify and reprogram the pin configs. At least, the pins for I/O with the actual jacks can be identified with a jack detection (plugging / unplugging).
This patch makes sense from a labelling perspective, but I’m suspicious that separate HP/LO and internal speaker volumes may not be possible, as if 0x0d feeds the internal amplifier, I assume there is no individual level control.
https://gist.github.com/andydvsn/16bf774d236fdeaa5de22ab0378643c3
As described in the patch, this doesn’t fix the underlying issue of amplified circuit noise through the muted internal speakers. If that could be solved, everything would be working correctly. The kernel 3.18 patch appears to have relied upon 0x07 for this switching, but I’ve had no luck configuring this so far.
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
Does the standard jack detection mechanism work for them individually?
Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
The fact that the patch_stac925x() sets own_eapd_ctrl flag means that there is *no* dynamic EAPD bit flip as done in the generic driver. That is, it's just kept as set in the initialized state. If EAPD is a must for some outputs, it has to be set either statically or dynamically. But you can hear something if the auto-mute is off, and it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
The crackling is often because of some bad routing from analog loopback. See whether the loopback is enabled unnecessarily.
There doesn’t appear to be a loopback entry in alsamixer or amixer, so I’m uncertain on how to check for this.
Thank you for your help, I really want to get to the bottom of this!
Is there any more information I can be providing that might help out with resolving this issue? I’ve still had no luck in completely shutting down the output to the internal speakers on this device when a line out is connected, though pin detection for muting is working fine. The audio signal gets muted but the circuit noise crackle appears every time.
From the original patch 0x07 would seem to be involved in this switching, though how I get this working is beyond me.
Sorry, I've been off for conferences and vacation thereafter, so haven't checked it at all (and almost forgotten).
No problem! I’ve had no time to look at this recently either. :)
This might be a repeated text, but, what we need is the (more or less) complete routing of your actual I/Os. Then we can try to enable only the required paths and disable the unnecessary paths by issuing HD-audio verbs on the fly, and check whether this actually works as expected.
That said, we need a "good-working" example of the whole routings, then adjust knobs to achieve this with the auto-parser.
Do you mean the physical connections of the STAC9202 chip on the board?
So far as I can see, 0x0a is handling all of the audio output - HP/LO and the stereo internal speakers - into an amplifier circuit on the board. There’s a connection to what appears to be an unpopulated area from 0x0d which may well be for an DECT circuit that’s not present on this unit. Pin 0x07 has some involvement with the switching off of the internal speakers, as that is what was forced in the original patch for the 3.10 kernel (old patch below).
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202...
The jack detection is working just fine, so my guess is that some sort of trigger on 0x07 is what’s required to shut down the speakers and prevent the crackling.
Thanks again,
Andy.
On 5 Oct 2018, at 15:36, Andy Davison wrote:
On 4 Oct 2018, at 22:09, Takashi Iwai wrote:
On Mon, 01 Oct 2018 02:15:56 +0200, Andy Davison wrote:
Hi all,
On 20 Sep 2018, at 02:31, Andy Davison andy@dvsn.net wrote:
[snip]
> Is it really about EAPD, or is it about the jack detection logic or > the incorrect pin config?
That’s a good question.
> The first item, the missing LO / HP detection rather indicates the pin > config issue. What is the line out pin and what is the headphone pin?
I’ve managed to grab the codec information from the original, very cut-down, operating system:
https://gist.github.com/andydvsn/47640739d911abc23cc6fc838a59a404#file-codec...
I see no patch file. Did you figure out which pin NID is for the line out, which pin NID for headphone, and which for int and ext mics?
For output, from the board it looks as though 0x0a (PORTA_L & PORTA_R) and 0x0d (PORTD_L & PORTD_R) are the only output connections. NID 0x0d looks as though it feeds the internal amplifier; I can’t entirely ascertain the purpose of 0x0a. If I mark 0x0a as not connected in hdajackretask, internal speaker muting stops working, though it appears to lead to an unpopulated area of the board.
Here is the pinout as best I can make out: https://i.imgur.com/lO8hqc8.png
This is the main board (front): https://i.imgur.com/CvYkM7G.jpg
This is the main board (rear): https://i.imgur.com/fYJor9s.jpg
You can use hdajackretask program to identify and reprogram the pin configs. At least, the pins for I/O with the actual jacks can be identified with a jack detection (plugging / unplugging).
This patch makes sense from a labelling perspective, but I’m suspicious that separate HP/LO and internal speaker volumes may not be possible, as if 0x0d feeds the internal amplifier, I assume there is no individual level control.
https://gist.github.com/andydvsn/16bf774d236fdeaa5de22ab0378643c3
As described in the patch, this doesn’t fix the underlying issue of amplified circuit noise through the muted internal speakers. If that could be solved, everything would be working correctly. The kernel 3.18 patch appears to have relied upon 0x07 for this switching, but I’ve had no luck configuring this so far.
Hopefully that output makes sense as to what are the internal speakers and which is the LO / HP jack socket.
> Does the standard jack detection mechanism work for them individually? > > Let's start from that.
I’m not sure how I would go about testing that; with no patches, inserting anything into the 3.5mm jack socket doesn’t appear to affect the system at all.
> The fact that the patch_stac925x() sets own_eapd_ctrl flag means that > there is *no* dynamic EAPD bit flip as done in the generic driver. > That is, it's just kept as set in the initialized state. If EAPD is a > must for some outputs, it has to be set either statically or > dynamically. But you can hear something if the auto-mute is off, and > it implies that EAPD doesn't matter, actually.
Ah, okay. That’s interesting - yes, with auto-mute disabled the audio comes through the LO / HP socket just fine. It’s only when the auto-mute is active that there’s the issue with crackling.
The crackling is often because of some bad routing from analog loopback. See whether the loopback is enabled unnecessarily.
There doesn’t appear to be a loopback entry in alsamixer or amixer, so I’m uncertain on how to check for this.
Thank you for your help, I really want to get to the bottom of this!
Is there any more information I can be providing that might help out with resolving this issue? I’ve still had no luck in completely shutting down the output to the internal speakers on this device when a line out is connected, though pin detection for muting is working fine. The audio signal gets muted but the circuit noise crackle appears every time.
From the original patch 0x07 would seem to be involved in this switching, though how I get this working is beyond me.
Sorry, I've been off for conferences and vacation thereafter, so haven't checked it at all (and almost forgotten).
No problem! I’ve had no time to look at this recently either. :)
This might be a repeated text, but, what we need is the (more or less) complete routing of your actual I/Os. Then we can try to enable only the required paths and disable the unnecessary paths by issuing HD-audio verbs on the fly, and check whether this actually works as expected.
That said, we need a "good-working" example of the whole routings, then adjust knobs to achieve this with the auto-parser.
Do you mean the physical connections of the STAC9202 chip on the board?
So far as I can see, 0x0a is handling all of the audio output - HP/LO and the stereo internal speakers - into an amplifier circuit on the board. There’s a connection to what appears to be an unpopulated area from 0x0d which may well be for an DECT circuit that’s not present on this unit. Pin 0x07 has some involvement with the switching off of the internal speakers, as that is what was forced in the original patch for the 3.10 kernel (old patch below).
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202...
The jack detection is working just fine, so my guess is that some sort of trigger on 0x07 is what’s required to shut down the speakers and prevent the crackling.
I’ve now compiled the latest 3.16 kernel with the original patch and that still works perfectly. For comparison, here are the alsa-info outputs for the vanilla 4.14 and the patched 3.16.
This is kernel 4.14.74 with no ALSA patches applied. It ignores
http://www.alsa-project.org/db/?f=2f10f0f25c2e2b6ff9c4d0b312675e05f7e9e634
This is kernel 3.16.59 working perfectly with the old kernel patch from GitHub above and the pin settings applied in of1-stac9202.conf:
http://www.alsa-project.org/db/?f=fb7cf7400691d60f2d3c5c30ba825516d4d4cf6d
This is the content of that ALSA patch:
[codec] 0x83847632 0x100 0
[pincfg] 0x07 0x01110014 0x08 0x01410013 0x0a 0x02111011 0x0d 0x02214012 0x0c 0x01810022 0x0b 0x01a10021 0x10 0x01010031 0x11 0x01310023 0x15 0x01d10024
[verb] 0x06 0x701 0x0000 0x07 0x70c 0x0002 0x14 0x390 0x0000 0x14 0x3a0 0x0000 0x0f 0x707 0x0000
[hint]
So the bit I’m clueless about is how to get ALSA in 4.14 to behave as it did in 3.16. I’m better informed on the structure of patch_sigmatel.c now, but it’s getting the configuration right in the first place that’s got me stumped.
Cheers,
A.
On 10 Oct 2018, at 10:29, Andy Davison wrote:
That said, we need a "good-working" example of the whole routings, then adjust knobs to achieve this with the auto-parser.
Do you mean the physical connections of the STAC9202 chip on the board?
So far as I can see, 0x0a is handling all of the audio output - HP/LO and the stereo internal speakers - into an amplifier circuit on the board. There’s a connection to what appears to be an unpopulated area from 0x0d which may well be for an DECT circuit that’s not present on this unit. Pin 0x07 has some involvement with the switching off of the internal speakers, as that is what was forced in the original patch for the 3.10 kernel (old patch below).
https://github.com/andydvsn/OpenFrame-Kernel/blob/master/patches/03-stac9202...
The jack detection is working just fine, so my guess is that some sort of trigger on 0x07 is what’s required to shut down the speakers and prevent the crackling.
I’ve now compiled the latest 3.16 kernel with the original patch and that still works perfectly. For comparison, here are the alsa-info outputs for the vanilla 4.14 and the patched 3.16.
This is kernel 4.14.74 with no ALSA patches applied. It ignores
…it ignores the insertion of the HP/LO jack and continues to play through internal speakers.
http://www.alsa-project.org/db/?f=2f10f0f25c2e2b6ff9c4d0b312675e05f7e9e634
This is kernel 3.16.59 working perfectly with the old kernel patch from GitHub above and the pin settings applied in of1-stac9202.conf:
http://www.alsa-project.org/db/?f=fb7cf7400691d60f2d3c5c30ba825516d4d4cf6d
In case it is of use, I’ve also gone back to the earliest supported kernel where the crackling issue first appeared - kernel 4.4.
Following loading of the pin patch file, jack detection started working, though with the crackling present on the internal speakers.
http://www.alsa-project.org/db/?f=f1522128d5383be42130ca2492e94959a75c553e
This alsa-info output is very similar to 3.16, but showing stream=0 on 0x05 instead of stream=4 in the working 3.16 config. Also, EAPD 0x0 on 0x07 in the working 3.16 config has become EAPD 0x2: EAPD for 4.4. I’ve searched, but can’t see how to adjust these in userland - can it be done?
Thanks,
Andy.
participants (2)
-
Andy Davison -
Takashi Iwai