Re: [alsa-devel] My Codec: IDT 92HD75B3X5 issues
On Yau al-Thulatha 09 Shawwal 1430 5:37:04 pm you wrote:
At Tue, 29 Sep 2009 16:24:29 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yau al-Thulatha 09 Shawwal 1430 9:24:19 am Takashi Iwai wrote:
At Tue, 29 Sep 2009 07:40:56 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Ithnain 08 Shawwal 1430 11:41:52 am Takashi Iwai wrote:
At Mon, 28 Sep 2009 06:58:46 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
Hi sirs, These are the issues I have with my Laptop HP Pavilion dv6 1225ee regarding audio support.
- No sense for headphone jack (jack_present?), when headphone is
plugged (present_int_hp?)
- There headphone mic jack is not working. The one next to the
webcam is always recording even when I change the "Mic Jack" control from "Mic In" to "Line In"
Make sure that you use alsa-driver-snapshot tarball instead of 1.0.21 released version. There are many fixes since 1.0.21 release.
ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-dr iver -sn apshot.tar.gz
Thanks a lot Takashi, things are better now. However, when I tested the internal mic it's very noisy. I played a bit with the capture and digital controls but still compared with Windows, it's lame.
OK, could you give alsa-info.sh output at this state? Please run with --no-upload option, and attach the generated file.
Attached.
Try to run:
% amixer -c0 set Capture cap 12dB % amixer -c0 set "Digital Mic" 10dB % amixer -c0 set Digital 0dB
Any difference?
No, still there is a clear shshshshshsh sound in the background. Please check the attachment for a short arecord -f cd without me speaking on the mic and still you can hear this noise very clear. Also attached is the alsa-info report at the time of recording
At Wed, 30 Sep 2009 08:18:31 +0300, Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?= =?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yau al-Thulatha 09 Shawwal 1430 5:37:04 pm you wrote:
At Tue, 29 Sep 2009 16:24:29 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yau al-Thulatha 09 Shawwal 1430 9:24:19 am Takashi Iwai wrote:
At Tue, 29 Sep 2009 07:40:56 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Ithnain 08 Shawwal 1430 11:41:52 am Takashi Iwai wrote:
At Mon, 28 Sep 2009 06:58:46 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
> Hi sirs, > These are the issues I have with my Laptop HP Pavilion dv6 1225ee > regarding audio support. > > 1. No sense for headphone jack (jack_present?), when headphone is > plugged (present_int_hp?) > > 2. There headphone mic jack is not working. The one next to the > webcam is always recording even when I change the "Mic Jack" > control from "Mic In" to "Line In"
Make sure that you use alsa-driver-snapshot tarball instead of 1.0.21 released version. There are many fixes since 1.0.21 release.
ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-dr iver -sn apshot.tar.gz
Thanks a lot Takashi, things are better now. However, when I tested the internal mic it's very noisy. I played a bit with the capture and digital controls but still compared with Windows, it's lame.
OK, could you give alsa-info.sh output at this state? Please run with --no-upload option, and attach the generated file.
Attached.
Try to run:
% amixer -c0 set Capture cap 12dB % amixer -c0 set "Digital Mic" 10dB % amixer -c0 set Digital 0dB
Any difference?
No, still there is a clear shshshshshsh sound in the background. Please check the attachment for a short arecord -f cd without me speaking on the mic and still you can hear this noise very clear. Also attached is the alsa-info report at the time of recording
Hm, are you using pulseaudio? Just to be sure, try like below: % arecord -Dplughw -fdat -vv foo.wav
Also, does the patch below have any influence?
Basically the signal path from the built-in mic is very simple, so there is no much room to change...
Takashi
--- diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 826137e..3c5f495 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -5338,7 +5338,7 @@ again: spec->aloopback_mask = 0x50; spec->aloopback_shift = 0;
- spec->powerdown_adcs = 1; + /*spec->powerdown_adcs = 1;*/ spec->digbeep_nid = 0x26; spec->mux_nids = stac92hd71bxx_mux_nids; spec->adc_nids = stac92hd71bxx_adc_nids;
On Yaum al-Arbi'a 10 Shawwal 1430 9:36:10 am Takashi Iwai wrote:
At Wed, 30 Sep 2009 08:18:31 +0300,
Hm, are you using pulseaudio? Just to be sure, try like below: % arecord -Dplughw -fdat -vv foo.wav
Yes, pulseaudio is running according to ps -e output. I ran arecord command as you said and no difference.
Also, does the patch below have any influence?
I applied that patch (commented the line) but no influence.
Basically the signal path from the built-in mic is very simple, so there is no much room to change...
I really don't know but it's a very bad SNR in Linux. Now, could it be that in Vista they are implementing a Noise cancellation somehow? Another try: could it be an IRQ issue since I noticed before the alsa update the irq is different - HDA Intel at 0xda100000 irq 22 + HDA Intel at 0xda100000 irq 33 - HDA ATI HDMI at 0xda010000 irq 17 + HDA ATI HDMI at 0xda010000 irq 34
Now, for some obscure reason I got confused in my previous messages when I told you the external mic is working after the update. It seems it's always the internal mic that's recording and when I plug the external mic, it makes no difference. Attached is the current alsa report.
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 826137e..3c5f495 100644d --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -5338,7 +5338,7 @@ again: spec->aloopback_mask = 0x50; spec->aloopback_shift = 0;
- spec->powerdown_adcs = 1;
- /*spec->powerdown_adcs = 1;*/ spec->digbeep_nid = 0x26; spec->mux_nids = stac92hd71bxx_mux_nids; spec->adc_nids = stac92hd71bxx_adc_nids;
At Thu, 1 Oct 2009 14:07:03 +0300, Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?= =?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Arbi'a 10 Shawwal 1430 9:36:10 am Takashi Iwai wrote:
At Wed, 30 Sep 2009 08:18:31 +0300,
Hm, are you using pulseaudio? Just to be sure, try like below: % arecord -Dplughw -fdat -vv foo.wav
Yes, pulseaudio is running according to ps -e output. I ran arecord command as you said and no difference.
OK.
Also, does the patch below have any influence?
I applied that patch (commented the line) but no influence.
Then it's not about ADC power-off feature.
Basically the signal path from the built-in mic is very simple, so there is no much room to change...
I really don't know but it's a very bad SNR in Linux. Now, could it be that in Vista they are implementing a Noise cancellation somehow?
Possibly. But in general, the digital-mic input is often better quality than analog-mics. I asked whether this appears in the external mic, too.
One thing I haven't mentioned is the IDT vendor-specific verbs for digital mic settings, such as rate, voltage, etc. These are listed in the datasheet publicly available.
Another try: could it be an IRQ issue since I noticed before the alsa update the irq is different
HDA Intel at 0xda100000 irq 22
HDA Intel at 0xda100000 irq 33
HDA ATI HDMI at 0xda010000 irq 17
HDA ATI HDMI at 0xda010000 irq 34
This is likely the influence of MSI, which is used newly as default.
Now, for some obscure reason I got confused in my previous messages when I told you the external mic is working after the update. It seems it's always the internal mic that's recording and when I plug the external mic, it makes no difference. Attached is the current alsa report.
Hm, that's odd. Could you check whether enable_msi=0 option changes the behavior?
Takashi
On Yaum al-Khamees 11 Shawwal 1430 4:30:16 pm Takashi Iwai wrote:
Now, for some obscure reason I got confused in my previous messages when I told you the external mic is working after the update. It seems it's always the internal mic that's recording and when I plug the external mic, it makes no difference. Attached is the current alsa report.
Hm, that's odd. Could you check whether enable_msi=0 option changes the behavior?
I added options snd-hda-intel enable_msi=1 and tested with arecord -fdat |aplay and don't see any difference when I plug the extrnal mic, besides, the controls I have doesn't contain any capture2 device as I have expected. How am I supposed to switch manually between then. In Vista it switches automatically and I can also switch manually.
Attached is the current report and thanks a lot for your great help and care.
At Thu, 1 Oct 2009 17:11:23 +0300, Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?= =?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Khamees 11 Shawwal 1430 4:30:16 pm Takashi Iwai wrote:
Now, for some obscure reason I got confused in my previous messages when I told you the external mic is working after the update. It seems it's always the internal mic that's recording and when I plug the external mic, it makes no difference. Attached is the current alsa report.
Hm, that's odd. Could you check whether enable_msi=0 option changes the behavior?
I added options snd-hda-intel enable_msi=1
No, enable_msi=0. This will take back to the old behavior.
and tested with arecord -fdat |aplay and don't see any difference when I plug the extrnal mic, besides, the controls I have doesn't contain any capture2 device as I have expected.
There is no capture2 device as such.
How am I supposed to switch manually between then. In Vista it switches automatically and I can also switch manually.
The switch is done always automatically as long as possible.
Takashi
At Thu, 01 Oct 2009 15:30:16 +0200, I wrote:
Now, for some obscure reason I got confused in my previous messages when I told you the external mic is working after the update. It seems it's always the internal mic that's recording and when I plug the external mic, it makes no difference. Attached is the current alsa report.
Hm, that's odd. Could you check whether enable_msi=0 option changes the behavior?
I found the culprit. It's actually a bug happening between the analog and the digital mic switches. Try the patch below.
Takashi
=== From 02d3332285377c9de395c2b5b792805d43923fd0 Mon Sep 17 00:00:00 2001 From: Takashi Iwai tiwai@suse.de Date: Thu, 1 Oct 2009 16:38:11 +0200 Subject: [PATCH] ALSA: hda - Fix digita/analog mic auto-switching with IDT codecs
When the auto-mic switching between an analog and a digital mic is needed with IDT codecs, the current driver doesn't reset the connection of the digital mux.
This patch fixes the behavior by checking both mux connections properly.
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_sigmatel.c | 20 ++++++++++++++------ 1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/sound/pci/hda/patch_sigmatel.c b/sound/pci/hda/patch_sigmatel.c index 826137e..a9b2682 100644 --- a/sound/pci/hda/patch_sigmatel.c +++ b/sound/pci/hda/patch_sigmatel.c @@ -182,8 +182,8 @@ struct sigmatel_jack {
struct sigmatel_mic_route { hda_nid_t pin; - unsigned char mux_idx; - unsigned char dmux_idx; + signed char mux_idx; + signed char dmux_idx; };
struct sigmatel_spec { @@ -3469,18 +3469,26 @@ static int set_mic_route(struct hda_codec *codec, break; if (i <= AUTO_PIN_FRONT_MIC) { /* analog pin */ - mic->dmux_idx = 0; i = get_connection_index(codec, spec->mux_nids[0], pin); if (i < 0) return -1; mic->mux_idx = i; + mic->dmux_idx = -1; + if (spec->dmux_nids) + mic->dmux_idx = get_connection_index(codec, + spec->dmux_nids[0], + spec->mux_nids[0]); } else if (spec->dmux_nids) { /* digital pin */ - mic->mux_idx = 0; i = get_connection_index(codec, spec->dmux_nids[0], pin); if (i < 0) return -1; mic->dmux_idx = i; + mic->mux_idx = -1; + if (spec->mux_nids) + mic->mux_idx = get_connection_index(codec, + spec->mux_nids[0], + spec->dmux_nids[0]); } return 0; } @@ -4557,11 +4565,11 @@ static void stac92xx_mic_detect(struct hda_codec *codec) mic = &spec->ext_mic; else mic = &spec->int_mic; - if (mic->dmux_idx) + if (mic->dmux_idx >= 0) snd_hda_codec_write_cache(codec, spec->dmux_nids[0], 0, AC_VERB_SET_CONNECT_SEL, mic->dmux_idx); - else + if (mic->mux_idx >= 0) snd_hda_codec_write_cache(codec, spec->mux_nids[0], 0, AC_VERB_SET_CONNECT_SEL, mic->mux_idx);
On Yaum al-Khamees 11 Shawwal 1430 5:42:56 pm Takashi Iwai wrote:
I found the culprit. It's actually a bug happening between the analog and the digital mic switches. Try the patch below.
Takashi
Dear Takashi, To complete this thread, what about missing options like 1. Disabling "Headphone Jack Sense" to allow both speakers and headphones to work together in case
2. jack retasking where I can plug my mic in the headphone jack and expect it to work
2. Capture boost
At Fri, 2 Oct 2009 01:11:01 +0300, Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?= =?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Khamees 11 Shawwal 1430 5:42:56 pm Takashi Iwai wrote:
I found the culprit. It's actually a bug happening between the analog and the digital mic switches. Try the patch below.
Takashi
Dear Takashi, To complete this thread, what about missing options like
- Disabling "Headphone Jack Sense" to allow both speakers and headphones to
work together in case
You can give "hp_detect = 0" to hints via sysfs and reconfigure.
- jack retasking where I can plug my mic in the headphone jack and expect it
to work
I thought it works now?
- Capture boost
"Mux" volume corresponds to it (for analog mic). The digital mic has another capture volume independently on this codec.
Takashi
On Yaum al-Jumma 12 Shawwal 1430 8:34:57 am Takashi Iwai wrote:
At Fri, 2 Oct 2009 01:11:01 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Khamees 11 Shawwal 1430 5:42:56 pm Takashi Iwai wrote:
I found the culprit. It's actually a bug happening between the analog and the digital mic switches. Try the patch below.
Takashi
Dear Takashi, To complete this thread, what about missing options like
- Disabling "Headphone Jack Sense" to allow both speakers and headphones
to work together in case
You can give "hp_detect = 0" to hints via sysfs and reconfigure.
But this is not user friendly. I used to see it as an option on other cards.
- jack retasking where I can plug my mic in the headphone jack and
expect it to work
I thought it works now?
No. If I plug the mic in the mic jack it works but if I plug it in the headphone jack it doesn't.
- Capture boost
"Mux" volume corresponds to it (for analog mic). The digital mic has another capture volume independently on this codec.
I will test this when I am back.
At Fri, 2 Oct 2009 09:15:22 +0300, Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?= =?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Jumma 12 Shawwal 1430 8:34:57 am Takashi Iwai wrote:
At Fri, 2 Oct 2009 01:11:01 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Khamees 11 Shawwal 1430 5:42:56 pm Takashi Iwai wrote:
I found the culprit. It's actually a bug happening between the analog and the digital mic switches. Try the patch below.
Takashi
Dear Takashi, To complete this thread, what about missing options like
- Disabling "Headphone Jack Sense" to allow both speakers and headphones
to work together in case
You can give "hp_detect = 0" to hints via sysfs and reconfigure.
But this is not user friendly. I used to see it as an option on other cards.
It's intentional. Otherwise user would choose it accidentally and cry out in 99% of probability :)
- jack retasking where I can plug my mic in the headphone jack and
expect it to work
I thought it works now?
No. If I plug the mic in the mic jack it works but if I plug it in the headphone jack it doesn't.
Errr, so you want to record from the headphone jack? This isn't specified in your BIOS to behave so, thus no go. (Currently the behavior of the driver depends on the BIOS information.) Write your own model quirk to override it.
Both of your demands are not for "normal" users. The driver could serve for that, but it needs some adjustment. Of course, I'd happily apply any patch if you can provide.
Takashi
On Yaum al-Jumma 12 Shawwal 1430 9:37:01 am Takashi Iwai wrote:
Dear Takashi, To complete this thread, what about missing options like
- Disabling "Headphone Jack Sense" to allow both speakers and
headphones to work together in case
You can give "hp_detect = 0" to hints via sysfs and reconfigure.
But this is not user friendly. I used to see it as an option on other cards.
It's intentional. Otherwise user would choose it accidentally and cry out in 99% of probability :)
Linus Torvalds said it better than me
This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease ... This is why you want graphical tools (that are there by default, so that you don't have to know enough even to know to get them) to configure stuff even for "experts". Because I'm an expert Unix user, but that doesn't mean that I'm expert in some Gnome internal configuration issues. ;) Seriously, I don't care a lot about this option.
- jack retasking where I can plug my mic in the headphone jack and
expect it to work
I thought it works now?
No. If I plug the mic in the mic jack it works but if I plug it in the headphone jack it doesn't.
Errr, so you want to record from the headphone jack? This isn't specified in your BIOS to behave so, thus no go. (Currently the behavior of the driver depends on the BIOS information.) Write your own model quirk to override it.
I don't know why the BIOS is involved. According to http://www.intel.com/design/chipsets/hdaudio.htm let me quote
"Intel HD Audio also provides improvements that support better jack retasking. The computer can sense when a device is plugged into an audio jack, determine what kind of device it is, and change the port function if the device has been plugged into the wrong port. For example, if a microphone is plugged into a speaker jack, the computer will recognize the error and can change the jack to function as a microphone jack. This is an important step in getting audio to a point where it ‘just works‘-users won‘t need to worry about getting the right device plugged into the right audio jack."
I also don't care about this feature myself but I love to see Linux at the top and have accurate information about the current status. So, is it really a BIOS issue or a driver issue?
Both of your demands are not for "normal" users. The driver could serve for that, but it needs some adjustment. Of course, I'd happily apply any patch if you can provide.
Thanks a lot Takashi, you are doing an outstanding job. Please, keep it up.
At Fri, 2 Oct 2009 14:24:11 +0300, Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?= =?utf-8?q?_=D8=B7=D9=87?=) wrote:
On Yaum al-Jumma 12 Shawwal 1430 9:37:01 am Takashi Iwai wrote:
Dear Takashi, To complete this thread, what about missing options like
- Disabling "Headphone Jack Sense" to allow both speakers and
headphones to work together in case
You can give "hp_detect = 0" to hints via sysfs and reconfigure.
But this is not user friendly. I used to see it as an option on other cards.
It's intentional. Otherwise user would choose it accidentally and cry out in 99% of probability :)
Linus Torvalds said it better than me
This 'users are idiots, and are confused by functionality' mentality of Gnome is a disease ... This is why you want graphical tools (that are there by default, so that you don't have to know enough even to know to get them) to configure stuff even for "experts". Because I'm an expert Unix user, but that doesn't mean that I'm expert in some Gnome internal configuration issues. ;) Seriously, I don't care a lot about this option.
Heh, too many complains by the wrong operation disease developers a lot.
The things should be placed to the right position. For the headphone jack detection switch, the mixer layer is the right place, IMO. The mixer app may change it so easily, and you find suddenly something wrong with an accident single click. That's why it's placed in another layer in the sysfs interface (and can be configured statically with a "firmware" patch as well).
- jack retasking where I can plug my mic in the headphone jack and
expect it to work
I thought it works now?
No. If I plug the mic in the mic jack it works but if I plug it in the headphone jack it doesn't.
Errr, so you want to record from the headphone jack? This isn't specified in your BIOS to behave so, thus no go. (Currently the behavior of the driver depends on the BIOS information.) Write your own model quirk to override it.
I don't know why the BIOS is involved. According to http://www.intel.com/design/chipsets/hdaudio.htm let me quote
"Intel HD Audio also provides improvements that support better jack retasking. The computer can sense when a device is plugged into an audio jack, determine what kind of device it is, and change the port function if the device has been plugged into the wrong port. For example, if a microphone is plugged into a speaker jack, the computer will recognize the error and can change the jack to function as a microphone jack. This is an important step in getting audio to a point where it ‘just works‘-users won‘t need to worry about getting the right device plugged into the right audio jack." I also don't care about this feature myself but I love to see Linux at the top and have accurate information about the current status. So, is it really a BIOS issue or a driver issue?
It describes just about the possible functionalities of HD-audio. Unfortunately, most codecs don't support the jack-type detections but only checks the presence of jacks, so far. The dream is sweet, the reality is bitter.
Takashi
On Yaum al-Jumma 12 Shawwal 1430 2:45:51 pm Takashi Iwai wrote:
At Fri, 2 Oct 2009 14:24:11 +0300,
Munzir Taha (=?utf-8?q?=D9=85=D9=86=D8=B0=D8=B1?=
=?utf-8?q?_=D8=B7=D9=87?=) wrote:
It describes just about the possible functionalities of HD-audio. Unfortunately, most codecs don't support the jack-type detections but only checks the presence of jacks, so far. The dream is sweet, the reality is bitter.
Umm! That info is misleading! Thanks for the clarification Takashi. I tested this in Vista and it's also not working so that's fine.
Now I noticed every time I reboot sound is muted. Is this a bug?
Also, can you make a release so Ubuntu and other distro can update to fix bugs such as: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/427670
participants (2)
-
Munzir Taha (منذر طه) -
Takashi Iwai