At Thu, 21 Jun 2012 15:04:44 +0200, David Henningsson wrote:
On 06/21/2012 02:52 PM, Takashi Iwai wrote:
At Thu, 21 Jun 2012 03:15:27 +0200, David Henningsson wrote:
On 06/20/2012 03:31 PM, Takashi Iwai wrote:
At Tue, 19 Jun 2012 09:43:07 +0200, David Henningsson wrote:
On 06/19/2012 05:07 AM, Eliot Blennerhassett wrote:
David Henningsson<david.henningsson<at> canonical.com> writes: > On 02/28/2012 02:22 PM, Takashi Iwai wrote: >> At Tue, 28 Feb 2012 14:07:59 +0100, >> David Henningsson wrote: >> Is there a way we can >>> know the corresponding processing coefficients to set for ALC268 and >>> ALC272X as well? >> >> AFAIK, no, it was specific to the codec model. > > Ok, then we can only hope for Kailang to supply this information if > possible. And if not possible we could attempt the workaround (when/if > we agree on it...) for these devices as well?
Greetings,
Any chance that there has been any progress on this? I have a machine with dmic and ALC272X (details below) that exhibits this problem, and can test any proposed patch.
We have a patch in for the Thinkpad U300s, but that one had a Conexant codec. I haven't had time to start working on kernel patches for the Realtek ones yet, but meanwhile, I'm tracking known machines here:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978
Looking at the codec, it's not so trivial to port the inverted switch to Realtek. In the input path of Realtek codecs, there is no individual capture volume/switch but only a central ADC volume and a MUX (or a mixer).
Yeah, that's part of why I haven't done it myself yet ;-)
I can think of a new boolean switch or an enum to choose whether to shut off the right channel of the input-mux and the loopback volume. But it's feasible only if it make sense to PA.
It seems possible that for ALC269 [1], you could switch path entirely (including ADC). I e, the internal mic would go 0x12 -> 0x23 -> 0x08 and the external mic would go 0x18 -> 0x24 -> 0x07. That way you could then label the volume control on 0x08 "Internal Mic Capture Volume" and "Inverted Internal Mic Capture Volume".
Do you think this is a good strategy, or would it lead to other problems (i e, what happens when you plug your mic in while actively recording)?
If the i-mic is the only user for ADC 0x08, this would work. But when ADC 0x09 has multiple sources like e-mic and line-in, ADC 0x09 would be named as "Capture" (because it's not only "Mic"), and this becomes exclusive with "Internal Mic Capture". It's a bit confusing, IMO.
Yes, this logic can only be used when there are two inputs - mic and internal mic. That is, the same conditions we today have for determining when to have auto-switching on plug/unplug.
Then 0x08 would have "Internal Mic Capture Volume|Switch" and 0x09 would be "Mic Capture Volume|Switch". "Capture Volume|Switch" cannot be used (unless we try to implement some kind of vmaster on the input side, but I don't think that would be necessary).
The alsa-info's I've looked at so far all have had one internal mic and one external mic on the input side. At least the Realtek ones.
Well, it's a bit risky to bet that. I won't be surprised by any largish machines with one more jack for supporting 5.1 output and a digital built-in mic, for example.
Takashi