On 4 May 2014 04:09, Raymond Yau superquad.vortex2@gmail.com wrote:

...

I'm having an issue with " Intel Corporation Haswell-ULT HD Audio Controller" card which is inside the Dell XPS13 9333 developer edition [1].

I've tried two different distributions

• Arch Linux (kernel 3.14)

Output of alsa-utlils-alsa-info.sh [2]

• Ubuntu 14.04 LTS (kernel 3.13)

Output of alsa-utlils-alsa-info.sh [3]

The card behaves correctly under Ubuntu but under Arch Linux I've observed the following issues.

• The microphone does not work correctly. In alsamixer I select

"Internal Mic" as my capture device but when I do

how many audio jacks do your laptop have ?

I am only aware of one. I think it's one of these TRRS jack connectors. Conceptually I should only have two inputs: Internal Mic and headset jack. The alsamixer shows the following channels that I can enable/disable CAPTURE on

- Headphone Mic - Capture - Headset Mic - Internal Mic

which is pretty confusing. I don't know what the "Capture" channel is. Also the names "Headphone Mic" and "Headset Mic" mean the same thing to me. Although that link you sent me seems to suggest to me that

- Headset mic probably refers to plugging in a headset that uses a TRRS jack so audio out and in go through the same jack - Headphone mic probably refers to plugging in a TS jack into the the Headset port (the only audio port on my system) and using that as a microphone

Is that right?

/sys/class/sound/hwC1D0/init_pin_configs: 0x12 0x90a60140 0x14 0x90170110 0x15 0x0321101f 0x16 0x40000000 0x18 0x411111f0 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x40d6832d 0x1e 0x411111f0 0x1f 0x411111f0

/sys/class/sound/hwC1D0/driver_pin_configs: 0x19 0x03a1913d 0x1b 0x03a1113c

seem driver assign sequence number c and d to some of the pin to indicate support of headset mic and headphone mic

Unfortunately without some explanation of the above pin mappings (I'm not an ALSA developer) I cannot understand what the above means. I'm guessing column1 is pin number and column2 is value? What is init_pin_configs and what is driver_pin_configs?

do your laptop specification support headset, headphone or mic if your laptop has only one jack ?

The icon next to the jack is the "headset" (headphones with attached microphone) icon, but I have no idea. The specification refers to the port as "headset (microphone and headphone combo) port". The specs can be found at [1]

http://voices.canonical.com/david.henningsson/2014/03/07/headset-jacks-on-ne...

I do not have a headset or external mic to test with unfortunately. I'm only interested in using the internal mic.

[1] ftp://ftp.dell.com/Manuals/all-products/esuprt_laptop/esuprt_xps_laptop/xps-13-9333_Reference%20Guide_en-us.pdf

Thanks, Dan.

Thank you for your suggestions:

If I run

$ amixer -c0 get Capture Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 63 [100%] [30.00dB] [on] Front Right: Capture 63 [100%] [30.00dB] [on]

So I think it's currently already on (I think I may of switched it on after running the script, but it didn't make any difference). I ran `` amixer -c0 set Capture cap`` and it didn't fix my microphone issue.

I also tried using model=nofixup and that didn't fix the microphone issue either :(

I just tried doing something different and to my surprise it fixed my microphone issue, i.e. after doing this the following commands

$ arecord -d 5 test.wav $ aplay test.wav

work (test.wav isn't complete silence).

There was one mixer control in alsamixer that I hadn't touched with the name "Digital". I had not played with it before because I presumed it shouldn't have anything to do with the internal microphone. I changed it from 0 to some non zero value and to my surprise my internal microphone now works.

So is this a bug or an intended feature? I've attached the output of alsa-utlils-alsa-info.sh before and after the mixer adjustment in the hope that it will help.

On 5 May 2014 09:02, Takashi Iwai tiwai@suse.de wrote:

At Sat, 3 May 2014 12:57:55 +0100, Delcypher wrote:

...

Hi,

I was told to report my bug here because the ALSA bug tracker is no longer active.

I'm having an issue with " Intel Corporation Haswell-ULT HD Audio Controller" card which is inside the Dell XPS13 9333 developer edition [1].

I've tried two different distributions

• Arch Linux (kernel 3.14)

Output of alsa-utlils-alsa-info.sh [2]

• Ubuntu 14.04 LTS (kernel 3.13)

Output of alsa-utlils-alsa-info.sh [3]

The card behaves correctly under Ubuntu but under Arch Linux I've observed the following issues.

• The microphone does not work correctly. In alsamixer I select

"Internal Mic" as my capture device but when I do

$ arecord -d 5 test.wav $ aplay test.wav

test.wav contains silence.

I've also tried enabling/disabling "CAPTURE" on the Capture channel at the same time - I don't really understand why this channel is here (seems a little bizarre) but enabling/disabling "CAPTURE" on this channel doesn't seem to make any difference anyway. Under Ubuntu the "arecord... aplay" command works correctly.

• There probably isn't a way to reproduce this but when I first

installed Arch Linux the sound card was put in a state where the headphone jack would not work at all. Sound would continue playing out of the speakers when the headphone jack was inserted and no sound would come out of the headphones. I did notice that if the headphone jack was only partially inserted I would get some sound sent to one of the headphones.

My intuition is that the card is probably being incorrectly initialised because if you take a look at the output of alsa-utils-alsa-info.sh and diff them. Two very big differences I noticed were that

• The card name (from lscpi) is "Intel Corporation Haswell-ULT HD

Audio Controller" under Ubuntu but under Arch Linux it is "Intel Corporation Device 0a0c"

• The card codec is "Realtek ALC668" under Ubuntu but is "Realtek

ALC3661" under Arch Linux.

One interesting I did notice is that under Arch Linux it is possible to use the microphone from the Audacity program by selecting "HDA Intel PCH: ALC3661Analog (hw0:0) Internal mic:0" as the input (this is not the default). Unfortunately I know of no way to make other applications use this.

Any thoughts on how to fix this?

[1] http://www.dell.com/uk/business/p/xps-13-linux/pd [2] https://gist.github.com/delcypher/11367224 [3] https://gist.github.com/delcypher/11367302

The "Capture Switch" is off, according to alsa-info.sh output. Try to turn it on. % amixer -c0 set Capture cap

If this doesn't help, it must be a quirk added in 3.14 kernel: commit f47e5dc464251f661da9495fcbf003a0d22c1360 ALSA: hda - Add a headset quirk for Dell XPS 13

I added relevant people in Cc.

Meanwhile, you can try to pass model=nofixup to snd-hda-intel module for avoiding the added fixup above.

thanks,

Takashi

At Mon, 5 May 2014 09:46:45 +0100, Delcypher wrote:

Thank you for your suggestions:

If I run

$ amixer -c0 get Capture Simple mixer control 'Capture',0 Capabilities: cvolume cswitch Capture channels: Front Left - Front Right Limits: Capture 0 - 63 Front Left: Capture 63 [100%] [30.00dB] [on] Front Right: Capture 63 [100%] [30.00dB] [on]

So I think it's currently already on (I think I may of switched it on after running the script, but it didn't make any difference). I ran `` amixer -c0 set Capture cap`` and it didn't fix my microphone issue.

I also tried using model=nofixup and that didn't fix the microphone issue either :(

I just tried doing something different and to my surprise it fixed my microphone issue, i.e. after doing this the following commands

$ arecord -d 5 test.wav $ aplay test.wav

work (test.wav isn't complete silence).

There was one mixer control in alsamixer that I hadn't touched with the name "Digital". I had not played with it before because I presumed it shouldn't have anything to do with the internal microphone. I changed it from 0 to some non zero value and to my surprise my internal microphone now works.

So is this a bug or an intended feature? I've attached the output of alsa-utlils-alsa-info.sh before and after the mixer adjustment in the hope that it will help.

The "Digital" is a mixer element alsa-lib softvol plugin creates, and it is irrelevant with the kernel at all. I guess someone adjusted this accidentally during updates or so.

So, my take is that it's rather an accident.

Takashi

On 5 May 2014 09:02, Takashi Iwai tiwai@suse.de wrote:

...

At Sat, 3 May 2014 12:57:55 +0100, Delcypher wrote:

...

Hi,

I was told to report my bug here because the ALSA bug tracker is no longer active.

I'm having an issue with " Intel Corporation Haswell-ULT HD Audio Controller" card which is inside the Dell XPS13 9333 developer edition [1].

I've tried two different distributions

• Arch Linux (kernel 3.14)

Output of alsa-utlils-alsa-info.sh [2]

• Ubuntu 14.04 LTS (kernel 3.13)

Output of alsa-utlils-alsa-info.sh [3]

The card behaves correctly under Ubuntu but under Arch Linux I've observed the following issues.

• The microphone does not work correctly. In alsamixer I select

"Internal Mic" as my capture device but when I do

$ arecord -d 5 test.wav $ aplay test.wav

test.wav contains silence.

I've also tried enabling/disabling "CAPTURE" on the Capture channel at the same time - I don't really understand why this channel is here (seems a little bizarre) but enabling/disabling "CAPTURE" on this channel doesn't seem to make any difference anyway. Under Ubuntu the "arecord... aplay" command works correctly.

• There probably isn't a way to reproduce this but when I first

installed Arch Linux the sound card was put in a state where the headphone jack would not work at all. Sound would continue playing out of the speakers when the headphone jack was inserted and no sound would come out of the headphones. I did notice that if the headphone jack was only partially inserted I would get some sound sent to one of the headphones.

My intuition is that the card is probably being incorrectly initialised because if you take a look at the output of alsa-utils-alsa-info.sh and diff them. Two very big differences I noticed were that

• The card name (from lscpi) is "Intel Corporation Haswell-ULT HD

Audio Controller" under Ubuntu but under Arch Linux it is "Intel Corporation Device 0a0c"

• The card codec is "Realtek ALC668" under Ubuntu but is "Realtek

ALC3661" under Arch Linux.

One interesting I did notice is that under Arch Linux it is possible to use the microphone from the Audacity program by selecting "HDA Intel PCH: ALC3661Analog (hw0:0) Internal mic:0" as the input (this is not the default). Unfortunately I know of no way to make other applications use this.

Any thoughts on how to fix this?

[1] http://www.dell.com/uk/business/p/xps-13-linux/pd [2] https://gist.github.com/delcypher/11367224 [3] https://gist.github.com/delcypher/11367302

The "Capture Switch" is off, according to alsa-info.sh output. Try to turn it on. % amixer -c0 set Capture cap

If this doesn't help, it must be a quirk added in 3.14 kernel: commit f47e5dc464251f661da9495fcbf003a0d22c1360 ALSA: hda - Add a headset quirk for Dell XPS 13

I added relevant people in Cc.

Meanwhile, you can try to pass model=nofixup to snd-hda-intel module for avoiding the added fixup above.

thanks,

Takashi