Re: [alsa-devel] Fwd: Dell Studio 14, internal mic
Takashi,
As mentioned below I have a Dell Studio 14, with a two channel mic built into the screen, speakers, and two headphone jacks and a mic jack on the side.
I've attached an updated alsa-info.sh output for 1.0.21. Things are working significantly better now (vs. 1.0.20) but a little messed up in the mixer controls. (When the module loads it says its making a guess for the chip.)
For the playback settings, "headphone" controls both headphones (should only set one of the headphone jacks), "headphone as lineout" sets the front-most headphone jack as lineout and disables the speaker off feature when something is plugged into the front-most jack (good, unless this is supposed to be available/work for both headphone jacks?), "headphone 1" does nothing (bad, should be other headphone control?), "front" sets the built-in speaker volume as expected, "pc beep" makes a lot of crackling on the speaker when a "ding" is hit on a terminal and so is muted (maybe not alsa's fault?)
Plugging in the headphones (with "headphone as lineout" disabled) now mutes the "front" speakers as expected.
For the capture settings, "digital" should be the first setting since its the master capture control, "front mic" controls the stereo built-in mic (good), "line" doesn't do anything(?), "mic" sets the mic jack (good), there are two capture volumes (capture and capture 1) and two "input source"s (line, mic, or front mic). I think there should only be mic or front mic unless there's someway to set the mic jack as "line in" somewhere else?
I can now record from the built-in mic ("front mic") vs 1.0.20.
So to summarize: - independent headphones don't have separate headphone volumes - "digital" should be the master capture control - there seems to be duplicate capture controls (capture & capture 1, wit corresponding "input sources") - "pc beep" seems to be a bit busted
Alistair
On Mon, Sep 14, 2009 at 6:29 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 12 Sep 2009 22:48:28 -0400, Alistair Boyle wrote:
Hi,
I sent this email to the alsa-user mailing list a while back but didn't get much of a response. It looks like you're the guy to talk to about this from looking at the alsa repository. Hopefully you can help me get this working.
Please post to alsa-devel ML and add me to Cc.
What I can advise now is to try the very latest alsa-driver, e.g. 1.0.21 release.
HTH,
Takashi
Alistair Boyle
---------- Forwarded message ---------- From: Alistair Boyle alistair.js.boyle@gmail.com Date: Tue, Aug 4, 2009 at 2:26 AM Subject: Dell Studio 14, internal mic To: alsa-users@alsa-project.org
Hello,
I've got a new Dell Studio 14. The laptop has a built-in mic and speakers, two head-phone jacks and a microphone jack. Using the snd-hda-intel driver (kernel 2.6.30), sound plays fine through the built-in speakers and I can record through the mic jack. It doesn't look like there's a way to set the 2 headphone jack volumes, nor is there a way to set the capture source to the built-in mic. Finally, and not surprisingly, when headphones are plugged in the built-in speakers don't mute.
(The built-in mic is the current priority.)
It looks like there were tweaks added to handle the (nominally similar) Dell Studio 15 and 17 which can be forced on with the "model=dell-m6" driver option but adding this option to the module removed all the capture devices from the amixer options. A similar result occurs for dell-m6-amic and dmic.
I'm at a loss as to where to look next. I'm "code competent" and with a pointer in the right direction I can debug.
I've attached the suggested debug info.
So a couple questions, in no particular order:
Has anyone dealt with the Dell Studio 14 laptops so far?
Is there any other debug output that would be helpful?
Where should I start looking in the code?
Alistair
At Mon, 14 Sep 2009 12:36:47 -0400, Alistair Boyle wrote:
Takashi,
As mentioned below I have a Dell Studio 14, with a two channel mic built into the screen, speakers, and two headphone jacks and a mic jack on the side.
I've attached an updated alsa-info.sh output for 1.0.21. Things are working significantly better now (vs. 1.0.20) but a little messed up in the mixer controls. (When the module loads it says its making a guess for the chip.)
For the playback settings, "headphone" controls both headphones (should only set one of the headphone jacks), "headphone as lineout" sets the front-most headphone jack as lineout and disables the speaker off feature when something is plugged into the front-most jack (good, unless this is supposed to be available/work for both headphone jacks?), "headphone 1" does nothing (bad, should be other headphone control?), "front" sets the built-in speaker volume as expected, "pc beep" makes a lot of crackling on the speaker when a "ding" is hit on a terminal and so is muted (maybe not alsa's fault?)
Plugging in the headphones (with "headphone as lineout" disabled) now mutes the "front" speakers as expected.
For the capture settings, "digital" should be the first setting since its the master capture control,
You should keep this "Digital" control to 50%, corresponding to 0dB.
"front mic" controls the stereo built-in mic (good), "line" doesn't do anything(?), "mic" sets the mic jack (good), there are two capture volumes (capture and capture 1) and two "input source"s (line, mic, or front mic). I think there should only be mic or front mic unless there's someway to set the mic jack as "line in" somewhere else?
This is my question, too. The original patch mentioned about a line-in. I guess a prototype machine had it, but not on real machines.
I can now record from the built-in mic ("front mic") vs 1.0.20.
So to summarize:
- independent headphones don't have separate headphone volumes
- "digital" should be the master capture control
- there seems to be duplicate capture controls (capture & capture 1,
wit corresponding "input sources")
- "pc beep" seems to be a bit busted
OK, now I fixed these issues. There were some left-over bugs indeed. The driver also supports the automatic mic selection via plugging for S14 now.
(Note that the multiple capture controls are no bug. The codec has multiple ADCs and the driver provides the multiple streams, too. But, together with the auto-mic feature, only one ADC is used now.)
Try the latest alsa-driver snapshot below, and report back. ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
thanks,
Takashi
Alistair
On Mon, Sep 14, 2009 at 6:29 AM, Takashi Iwai tiwai@suse.de wrote:
At Sat, 12 Sep 2009 22:48:28 -0400, Alistair Boyle wrote:
Hi,
I sent this email to the alsa-user mailing list a while back but didn't get much of a response. It looks like you're the guy to talk to about this from looking at the alsa repository. Hopefully you can help me get this working.
Please post to alsa-devel ML and add me to Cc.
What I can advise now is to try the very latest alsa-driver, e.g. 1.0.21 release.
HTH,
Takashi
Alistair Boyle
---------- Forwarded message ---------- From: Alistair Boyle alistair.js.boyle@gmail.com Date: Tue, Aug 4, 2009 at 2:26 AM Subject: Dell Studio 14, internal mic To: alsa-users@alsa-project.org
Hello,
I've got a new Dell Studio 14. The laptop has a built-in mic and speakers, two head-phone jacks and a microphone jack. Using the snd-hda-intel driver (kernel 2.6.30), sound plays fine through the built-in speakers and I can record through the mic jack. It doesn't look like there's a way to set the 2 headphone jack volumes, nor is there a way to set the capture source to the built-in mic. Finally, and not surprisingly, when headphones are plugged in the built-in speakers don't mute.
(The built-in mic is the current priority.)
It looks like there were tweaks added to handle the (nominally similar) Dell Studio 15 and 17 which can be forced on with the "model=dell-m6" driver option but adding this option to the module removed all the capture devices from the amixer options. A similar result occurs for dell-m6-amic and dmic.
I'm at a loss as to where to look next. I'm "code competent" and with a pointer in the right direction I can debug.
I've attached the suggested debug info.
So a couple questions, in no particular order:
Has anyone dealt with the Dell Studio 14 laptops so far?
Is there any other debug output that would be helpful?
Where should I start looking in the code?
Alistair
On Tue, Sep 15, 2009 at 6:45 AM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 14 Sep 2009 12:36:47 -0400, Alistair Boyle wrote:
For the capture settings, "digital" should be the first setting since its the master capture control,
You should keep this "Digital" control to 50%, corresponding to 0dB.
"front mic" controls the stereo built-in mic (good), "line" doesn't do anything(?), "mic" sets the mic jack (good), there are two capture volumes (capture and capture 1) and two "input source"s (line, mic, or front mic). I think there should only be mic or front mic unless there's someway to set the mic jack as "line in" somewhere else?
This is my question, too. The original patch mentioned about a line-in. I guess a prototype machine had it, but not on real machines.
I can now record from the built-in mic ("front mic") vs 1.0.20.
This seems to be a bit of a regression: the recording source labels are reversed. To record from the built-in mic I have to set the "input source" selector to "mic" instead of "front mic" and vice-versa for plugging in a mic. There doesn't seem to be any automatic switching of recording sources occurring. Both recording sources still work.
So to summarize: - independent headphones don't have separate headphone volumes - "digital" should be the master capture control - there seems to be duplicate capture controls (capture & capture 1, wit corresponding "input sources") - "pc beep" seems to be a bit busted
OK, now I fixed these issues. There were some left-over bugs indeed. The driver also supports the automatic mic selection via plugging for S14 now.
(Note that the multiple capture controls are no bug. The codec has multiple ADCs and the driver provides the multiple streams, too. But, together with the auto-mic feature, only one ADC is used now.)
Try the latest alsa-driver snapshot below, and report back. ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/alsa-driver-snapshot.tar.gz
The headphones are still both controlled by the single "headphone" control and are not independent and the "pc beep" still emits crackling on a xterm beep and has to be muted.
The reason I was asking about the "digital" control is because, when using Skype, the program tries to adjust the recording volume on-the-fly. In windows this works fine, in linux I see it trying to fiddle with the "front mic" recording volume which only has three settings and doesn't affect the mic jack. I'd think "Digital" would be more appropriate to twiddle since it controls both the built-in mic and the jacked one and has finer control. I can disable this behavior in Skype but I'm guessing there's no way, in general, for programs to know which alsa control is generally the "master" record control and they're just guessing that the first one they grab is?
I've attached a new alsa-info.
Thanks for the speedy response! Alistair
At Tue, 15 Sep 2009 13:54:16 -0400, Alistair Boyle wrote:
[1 <text/plain; UTF-8 (quoted-printable)>] On Tue, Sep 15, 2009 at 6:45 AM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 14 Sep 2009 12:36:47 -0400, Alistair Boyle wrote:
For the capture settings, "digital" should be the first setting since its the master capture control,
You should keep this "Digital" control to 50%, corresponding to 0dB.
"front mic" controls the stereo built-in mic (good), "line" doesn't do anything(?), "mic" sets the mic jack (good), there are two capture volumes (capture and capture 1) and two "input source"s (line, mic, or front mic). I think there should only be mic or front mic unless there's someway to set the mic jack as "line in" somewhere else?
This is my question, too. The original patch mentioned about a line-in. I guess a prototype machine had it, but not on real machines.
I can now record from the built-in mic ("front mic") vs 1.0.20.
This seems to be a bit of a regression: the recording source labels are reversed. To record from the built-in mic I have to set the "input source" selector to "mic" instead of "front mic" and vice-versa for plugging in a mic. There doesn't seem to be any automatic switching of recording sources occurring. Both recording sources still work.
Are you sure that you are using the very latest one? Double-check the latest alsa-driver-snapshot.tar.gz.
Takashi
On Wed, Sep 16, 2009 at 1:34 AM, Takashi Iwai tiwai@suse.de wrote:
At Tue, 15 Sep 2009 13:54:16 -0400, Alistair Boyle wrote:
On Tue, Sep 15, 2009 at 6:45 AM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 14 Sep 2009 12:36:47 -0400, Alistair Boyle wrote:
For the capture settings, "digital" should be the first setting since its the master capture control,
You should keep this "Digital" control to 50%, corresponding to 0dB.
...
This seems to be a bit of a regression: the recording source labels
...
Are you sure that you are using the very latest one? Double-check the latest alsa-driver-snapshot.tar.gz.
Oh, sorry. Yup, that's much better. Auto mic switching on plugin and the independent headphones are working properly now, including muting the speakers when a headphone is plugged in.
Two issues remaining:
1. The "pc beep" is still making a bad buzz/crackling noise when an xterm beep occurs. There's also a new "speaker" control but it doesn't affect this behavior (unrelated?).
2. It should be the "capture" control that Skype or some other application should be twiddling to adjust recording volume automatically? Is it this control that should come first when they are enumerated, or is there some property that is missing from this control to tell the application which control to use? (ie: is there anything the alsa-driver does to help the application get this right?)
Updated alsa-info.sh with new output attached.
At Wed, 16 Sep 2009 17:18:11 -0400, Alistair Boyle wrote:
On Wed, Sep 16, 2009 at 1:34 AM, Takashi Iwai tiwai@suse.de wrote:
At Tue, 15 Sep 2009 13:54:16 -0400, Alistair Boyle wrote:
On Tue, Sep 15, 2009 at 6:45 AM, Takashi Iwai tiwai@suse.de wrote:
At Mon, 14 Sep 2009 12:36:47 -0400, Alistair Boyle wrote:
For the capture settings, "digital" should be the first setting since its the master capture control,
You should keep this "Digital" control to 50%, corresponding to 0dB.
...
This seems to be a bit of a regression: the recording source labels
...
Are you sure that you are using the very latest one? Double-check the latest alsa-driver-snapshot.tar.gz.
Oh, sorry. Yup, that's much better. Auto mic switching on plugin and the independent headphones are working properly now, including muting the speakers when a headphone is plugged in.
Two issues remaining:
- The "pc beep" is still making a bad buzz/crackling noise when an
xterm beep occurs. There's also a new "speaker" control but it doesn't affect this behavior (unrelated?).
Hm, this is basically independent from my change, and I guess this is a codec hardware issue.
- It should be the "capture" control that Skype or some other
application should be twiddling to adjust recording volume automatically? Is it this control that should come first when they are enumerated, or is there some property that is missing from this control to tell the application which control to use? (ie: is there anything the alsa-driver does to help the application get this right?)
The "Capture" volume is available. Skype should choose it as default. Isn't it just the old saved setup that screws up?
Takashi
On Thu, Sep 17, 2009 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 16 Sep 2009 17:18:11 -0400, Alistair Boyle wrote:
...
- It should be the "capture" control that Skype or some other
application should be twiddling to adjust recording volume automatically? Is it this control that should come first when they are enumerated, or is there some property that is missing from this control to tell the application which control to use? (ie: is there anything the alsa-driver does to help the application get this right?)
The "Capture" volume is available. Skype should choose it as default. Isn't it just the old saved setup that screws up?
Clearing ~/.Skype and restarting gets the same behavior. Skype is playing the "front mic" control instead of "capture". I see a bunch of
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hdmi
errors on the console when it modifies the "front mic" control. This is with skype-2.0.0.72.
Alistair
At Thu, 17 Sep 2009 13:25:22 -0400, Alistair Boyle wrote:
On Thu, Sep 17, 2009 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 16 Sep 2009 17:18:11 -0400, Alistair Boyle wrote:
...
- It should be the "capture" control that Skype or some other
application should be twiddling to adjust recording volume automatically? Is it this control that should come first when they are enumerated, or is there some property that is missing from this control to tell the application which control to use? (ie: is there anything the alsa-driver does to help the application get this right?)
The "Capture" volume is available. Skype should choose it as default. Isn't it just the old saved setup that screws up?
Clearing ~/.Skype and restarting gets the same behavior. Skype is playing the "front mic" control instead of "capture". I see a bunch of
Hm, then it's rather a problem of Skype.
ALSA lib control.c:909:(snd_ctl_open_noupdate) Invalid CTL hdmi
errors on the console when it modifies the "front mic" control. This is with skype-2.0.0.72.
Takashi
2009/9/17 Takashi Iwai tiwai@suse.de:
At Thu, 17 Sep 2009 13:25:22 -0400, Alistair Boyle wrote:
On Thu, Sep 17, 2009 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 16 Sep 2009 17:18:11 -0400, Alistair Boyle wrote:
...
- It should be the "capture" control that Skype or some other
application should be twiddling to adjust recording volume automatically? Is it this control that should come first when they are enumerated, or is there some property that is missing from this control to tell the application which control to use? (ie: is there anything the alsa-driver does to help the application get this right?)
The "Capture" volume is available. Skype should choose it as default. Isn't it just the old saved setup that screws up?
Clearing ~/.Skype and restarting gets the same behavior. Skype is playing the "front mic" control instead of "capture". I see a bunch of
Hm, then it's rather a problem of Skype.
Okay. Thanks for all your help so far!
- The "pc beep" is still making a bad buzz/crackling noise when an
xterm beep occurs. There's also a new "speaker" control but it doesn't affect this behavior (unrelated?).
Hm, this is basically independent from my change, and I guess this is a codec hardware issue.
The last item was the "pc beep" thing. It looks like you're the guy to talk to about that too: is there any debugging I can do on my end to help sort that out? It looks from the log like there's some tricky business with getting the beep frequency right?
At Thu, 17 Sep 2009 15:51:55 -0400, Alistair Boyle wrote:
2009/9/17 Takashi Iwai tiwai@suse.de:
At Thu, 17 Sep 2009 13:25:22 -0400, Alistair Boyle wrote:
On Thu, Sep 17, 2009 at 12:31 PM, Takashi Iwai tiwai@suse.de wrote:
At Wed, 16 Sep 2009 17:18:11 -0400, Alistair Boyle wrote:
...
- It should be the "capture" control that Skype or some other
application should be twiddling to adjust recording volume automatically? Is it this control that should come first when they are enumerated, or is there some property that is missing from this control to tell the application which control to use? (ie: is there anything the alsa-driver does to help the application get this right?)
The "Capture" volume is available. Skype should choose it as default. Isn't it just the old saved setup that screws up?
Clearing ~/.Skype and restarting gets the same behavior. Skype is playing the "front mic" control instead of "capture". I see a bunch of
Hm, then it's rather a problem of Skype.
Okay. Thanks for all your help so far!
- The "pc beep" is still making a bad buzz/crackling noise when an
xterm beep occurs. There's also a new "speaker" control but it doesn't affect this behavior (unrelated?).
Hm, this is basically independent from my change, and I guess this is a codec hardware issue.
The last item was the "pc beep" thing. It looks like you're the guy to talk to about that too: is there any debugging I can do on my end to help sort that out? It looks from the log like there's some tricky business with getting the beep frequency right?
It's not clear from your description what is the actual problem, i.e. whether it's a wrong HZ calculation or just the loudness. It seems that the loudness is hard-coded and can't be softer. But the frequency should be certainly fixable.
The frequency calculation is found in hda_beep.c.
Takashi
participants (2)
-
Alistair Boyle -
Takashi Iwai