Inverted internal mic

From 3ef2a105a85195c14e25190bca53bb55260feffa Mon Sep 17 00:00:00 2001

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because
1) we already have quirking infrastructure there
2) we already have some working quirks already in that layer
3) it would benefit other sound applications that use ALSA directly.

The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality.

For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us.

Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem?

At Tue, 28 Feb 2012 09:57:56 +0100,

Quoted 26 lines · David Henningsson

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because
1) we already have quirking infrastructure there
2) we already have some working quirks already in that layer
3) it would benefit other sound applications that use ALSA directly.

The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality.

For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us.

Quoted 9 lines

Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem?

The remaining problem in the patch is that the signal is recorded only on left when you record in stereo. I guess the reporter tested only a program like Skype, which uses only a mono stream.

If this behavior, only one channel in a stereo stream, is acceptable, it's a reasonable fix, I think.

Quoted 24 lines · Takashi Iwai

At Tue, 28 Feb 2012 09:57:56 +0100,

Quoted 22 lines · David Henningsson

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because
1) we already have quirking infrastructure there
2) we already have some working quirks already in that layer
3) it would benefit other sound applications that use ALSA directly.

The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality.

Quoted 4 lines

Quoted 4 lines

For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us.

A follow-up question here would be if it is easy for you (or Kailang?) to figure this out, or if we should resort to the suggest workaround for Realtek ALC268 and ALC272X as well?

Quoted 14 lines

Quoted 9 lines

Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem?

The remaining problem in the patch is that the signal is recorded only on left when you record in stereo. I guess the reporter tested only a program like Skype, which uses only a mono stream.

Quoted 2 lines

If this behavior, only one channel in a stereo stream, is acceptable, it's a reasonable fix, I think.

That is indeed a disadvantage, but I don't know if we have something better to offer? E g, we could try an alsa-lib ttable solution, but that would then have a problem with knowing whether the Internal Mic is currently selected or not.

If the program:

- tries to record in mono:
* As the industry standard for mapping mono is to map it to the left
channel, I assume this is what ALSA/HDA does in this case as well, so unchanged and working behaviour

- record in stereo, then take left channel only:
* unchanged and working behaviour

- record in stereo, then take right channel only:
* regression as the inverted channel will now be zero, but this would
be highly unconventional and unusual, I assume?

- record in stereo, then merge both channels:
* this is the normal and common case for VoIP applications going
through PulseAudio (Skype etc). Improvement, this will fix the bug; although the result will be -6 dB compared to the original signal.

- record in stereo, keep signal in stereo for playback:
* this somewhat depends on how the playback is set up, but I would
say that it would be an improvement in most cases if the speakers are relatively close to one another...I guess?

At Tue, 28 Feb 2012 10:54:00 +0100,

Quoted 31 lines · David Henningsson

Quoted 28 lines · Takashi Iwai

At Tue, 28 Feb 2012 09:57:56 +0100,

Quoted 26 lines · David Henningsson

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because
1) we already have quirking infrastructure there
2) we already have some working quirks already in that layer
3) it would benefit other sound applications that use ALSA directly.

The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality.

For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us.

Quoted 3 lines

A follow-up question here would be if it is easy for you (or Kailang?) to figure this out, or if we should resort to the suggest workaround for Realtek ALC268 and ALC272X as well?

Actually, Kailang (Cc'ed now) and I talked about it when I visited Taipei in the last year, and he mentioned that there is no way to detect the FM chip from the codec. It seems that SSID listing is the only way.

Quoted 14 lines

Quoted 14 lines

Quoted 9 lines

Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem?

The remaining problem in the patch is that the signal is recorded only on left when you record in stereo. I guess the reporter tested only a program like Skype, which uses only a mono stream.

Quoted 7 lines

Quoted 2 lines

If this behavior, only one channel in a stereo stream, is acceptable, it's a reasonable fix, I think.

That is indeed a disadvantage, but I don't know if we have something better to offer? E g, we could try an alsa-lib ttable solution, but that would then have a problem with knowing whether the Internal Mic is currently selected or not.

Note that in alsa-lib, the HD-audio "default" is already set up to copy left-channel for mono streams. You can see a line setting "route_policy" to "copy" in HDA-Intel.conf.

Thus, when ALSA apps run without PA, it'd work in both stereo and mono.

Quoted 19 lines

If the program:

- tries to record in mono:
* As the industry standard for mapping mono is to map it to the left
channel, I assume this is what ALSA/HDA does in this case as well, so unchanged and working behaviour

- record in stereo, then take left channel only:
* unchanged and working behaviour

- record in stereo, then take right channel only:
* regression as the inverted channel will now be zero, but this would
be highly unconventional and unusual, I assume?

- record in stereo, then merge both channels:
* this is the normal and common case for VoIP applications going
through PulseAudio (Skype etc). Improvement, this will fix the bug; although the result will be -6 dB compared to the original signal.

Quoted 4 lines

- record in stereo, keep signal in stereo for playback:
* this somewhat depends on how the playback is set up, but I would
say that it would be an improvement in most cases if the speakers are relatively close to one another...I guess?

Well, I think this could be also worked around in PA. Can PA switch the downmixing to the mono to a simple left-channel copy, only for certain devices, or at least via a config?

If this is feasible, the rest is how to identify such a device. And this can be done equally well in user-space, too, as there is no hidden information about it.

Of course, this is not the best of the best. Ideally, the driver provides multiple PCM streams and PA switches between them and switches the downmixing simultaneously per input-source change. But this needs a lot of works, and maybe requires a fundamental infrastructure change, too.

Quoted 33 lines · Takashi Iwai

At Tue, 28 Feb 2012 10:54:00 +0100,

Quoted 31 lines · David Henningsson

Quoted 28 lines · Takashi Iwai

At Tue, 28 Feb 2012 09:57:56 +0100,

Quoted 26 lines · David Henningsson

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

There are various ways we can work around this in both the kernel, alsa-lib and PulseAudio layers. It's a matter of picking the right one. I'm leaning towards trying to fix it in the kernel's codec drivers, because
1) we already have quirking infrastructure there
2) we already have some working quirks already in that layer
3) it would benefit other sound applications that use ALSA directly.

The downside to that is really that we're silencing out one channel for everyone, leading to no application being able to use both channels, even if they would implement some kind of "auto-detect-and-reverse-one-channel" functionality.

For the most part, this has been some Acer Aspire machines running Realtek ALC268 / ALC269 / ALC271X / ALC272X, and for two of these we have proc coefs we can set, but for the other two these proc coefs, if they exist, are unknown to us.

Quoted 8 lines

Quoted 3 lines

A follow-up question here would be if it is easy for you (or Kailang?) to figure this out, or if we should resort to the suggest workaround for Realtek ALC268 and ALC272X as well?

Actually, Kailang (Cc'ed now) and I talked about it when I visited Taipei in the last year, and he mentioned that there is no way to detect the FM chip from the codec. It seems that SSID listing is the only way.

Ok. My question was more about the following: When I look at patch_realtek.c, I can find functions alc271_fixup_dmic and alc269_fixup_stereo_dmic. I have also seen machines having ALC268 and ALC272X that have this internal mic behaviour. Is there a way we can know the corresponding processing coefficients to set for ALC268 and ALC272X as well?

Quoted 26 lines

Quoted 14 lines

Quoted 14 lines

Quoted 9 lines

Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem?

The remaining problem in the patch is that the signal is recorded only on left when you record in stereo. I guess the reporter tested only a program like Skype, which uses only a mono stream.

Quoted 7 lines

Quoted 2 lines

If this behavior, only one channel in a stereo stream, is acceptable, it's a reasonable fix, I think.

That is indeed a disadvantage, but I don't know if we have something better to offer? E g, we could try an alsa-lib ttable solution, but that would then have a problem with knowing whether the Internal Mic is currently selected or not.

Note that in alsa-lib, the HD-audio "default" is already set up to copy left-channel for mono streams. You can see a line setting "route_policy" to "copy" in HDA-Intel.conf.

Quoted 2 lines

Thus, when ALSA apps run without PA, it'd work in both stereo and mono.

Assuming the right channel is muted, yes. But not in the current implementation.

By not making a change in the ALSA layer, it will still be broken for any ALSA apps who record the Internal Mic as a stereo signal. They will get a broken result as the right channel will be phase inverted. That's why I think this is better dealt with in the ALSA layer. Would a zeroed right channel be less broken than a phase inverted right channel? I think so.

Quoted 28 lines

Quoted 19 lines

If the program:

- tries to record in mono:
* As the industry standard for mapping mono is to map it to the left
channel, I assume this is what ALSA/HDA does in this case as well, so unchanged and working behaviour

- record in stereo, then take left channel only:
* unchanged and working behaviour

- record in stereo, then take right channel only:
* regression as the inverted channel will now be zero, but this would
be highly unconventional and unusual, I assume?

- record in stereo, then merge both channels:
* this is the normal and common case for VoIP applications going
through PulseAudio (Skype etc). Improvement, this will fix the bug; although the result will be -6 dB compared to the original signal.

Quoted 4 lines

- record in stereo, keep signal in stereo for playback:
* this somewhat depends on how the playback is set up, but I would
say that it would be an improvement in most cases if the speakers are relatively close to one another...I guess?

Well, I think this could be also worked around in PA. Can PA switch the downmixing to the mono to a simple left-channel copy, only for certain devices, or at least via a config?

Quoted 3 lines

If this is feasible, the rest is how to identify such a device. And this can be done equally well in user-space, too, as there is no hidden information about it.

PA has udev rules to identify the device, so I'm not too worried about the identification, though that is generally frowned upon - I'd say that hardware dependent stuff should be in ALSA rather than PA.

The
difficulty is that we need to switch this on and off when we switch ports - we don't want to regress behaviour for e g line in and other stereo recording sources.

Quoted 5 lines

Of course, this is not the best of the best. Ideally, the driver provides multiple PCM streams and PA switches between them and switches the downmixing simultaneously per input-source change. But this needs a lot of works, and maybe requires a fundamental infrastructure change, too.

Seems almost easier to write a PulseAudio module that automatically detects when one channel is phase inverted, and inverts that channel when that happens. But maybe that is ugly too...

At Tue, 28 Feb 2012 14:07:59 +0100,

Quoted 6 lines · David Henningsson

Ok. My question was more about the following: When I look at patch_realtek.c, I can find functions alc271_fixup_dmic and alc269_fixup_stereo_dmic. I have also seen machines having ALC268 and ALC272X that have this internal mic behaviour. 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.

Quoted 7 lines

Quoted 6 lines

Note that in alsa-lib, the HD-audio "default" is already set up to copy left-channel for mono streams. You can see a line setting "route_policy" to "copy" in HDA-Intel.conf.

Thus, when ALSA apps run without PA, it'd work in both stereo and mono.

Quoted 2 lines

Assuming the right channel is muted, yes. But not in the current implementation.

It should work no matter whether the right channel is muted or not. The plug layer will use only the left channel when a mono stream is recorded since route_policy=copy is set. Remember that it's about "default" PCM, not about "hw" PCM that PA uses. We don't touch "hw" intentionally because it's really intended to be a raw access.

Quoted 6 lines

By not making a change in the ALSA layer, it will still be broken for any ALSA apps who record the Internal Mic as a stereo signal. They will get a broken result as the right channel will be phase inverted. That's why I think this is better dealt with in the ALSA layer. Would a zeroed right channel be less broken than a phase inverted right channel? I think so.

Quoted 10 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,

Quoted 6 lines · David Henningsson

Ok. My question was more about the following: When I look at patch_realtek.c, I can find functions alc271_fixup_dmic and alc269_fixup_stereo_dmic. I have also seen machines having ALC268 and ALC272X that have this internal mic behaviour. 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?

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

Note that in alsa-lib, the HD-audio "default" is already set up to copy left-channel for mono streams. You can see a line setting "route_policy" to "copy" in HDA-Intel.conf.

Thus, when ALSA apps run without PA, it'd work in both stereo and mono.

Quoted 8 lines

Quoted 2 lines

Assuming the right channel is muted, yes. But not in the current implementation.

It should work no matter whether the right channel is muted or not. The plug layer will use only the left channel when a mono stream is recorded since route_policy=copy is set. Remember that it's about "default" PCM, not about "hw" PCM that PA uses. We don't touch "hw" intentionally because it's really intended to be a raw access.

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Quoted 6 lines

Quoted 6 lines

By not making a change in the ALSA layer, it will still be broken for any ALSA apps who record the Internal Mic as a stereo signal. They will get a broken result as the right channel will be phase inverted. That's why I think this is better dealt with in the ALSA layer. Would a zeroed right channel be less broken than a phase inverted right channel? I think so.

Quoted 3 lines

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Well, when you record it in stereo, and play it back, then you hear the sound without problem.

The problem happens only when you sum the
left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal.

Quoted 4 lines · Takashi Iwai

Quoted 3 lines

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Quoted 2 lines

Well, when you record it in stereo, and play it back, then you hear the sound without problem.

That could definitely be questioned: depending on the distance between speakers when you're finally playing it back, you might lose bass frequencies [1]. (That said, I'm not sure how much bass these mics pick up anyway.)

Quoted 4 lines

The problem happens only when you sum the
left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal.

So the official recommendation is that summing left and right to make a mono signal, is to be considered an invalid operation?

At Tue, 28 Feb 2012 19:11:15 +0100,

Quoted 6 lines · David Henningsson

Quoted 4 lines · Takashi Iwai

Quoted 3 lines

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Quoted 7 lines

Quoted 2 lines

Well, when you record it in stereo, and play it back, then you hear the sound without problem.

That could definitely be questioned: depending on the distance between speakers when you're finally playing it back, you might lose bass frequencies [1]. (That said, I'm not sure how much bass these mics pick up anyway.)

Well, it might be, in the worst case.

Quoted 7 lines

Quoted 4 lines

The problem happens only when you sum the
left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal.

So the official recommendation is that summing left and right to make a mono signal, is to be considered an invalid operation?

It's not invalid in general but invalid for this digital mic. That's the only point. Thus, avoiding summing only for known bad devices is also a way to go, IMO. It'd work more or less stably. OTOH, muting the right reduces the risk but it also has a problem of the lower volume and the lack of right signal in stereo streams, both of which aren't easily avoided.

So we need to find some point of compromise...

Quoted 33 lines · Takashi Iwai

At Tue, 28 Feb 2012 19:11:15 +0100,

Quoted 6 lines · David Henningsson

Quoted 4 lines · Takashi Iwai

Quoted 3 lines

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Quoted 7 lines

Quoted 2 lines

Well, when you record it in stereo, and play it back, then you hear the sound without problem.

That could definitely be questioned: depending on the distance between speakers when you're finally playing it back, you might lose bass frequencies [1]. (That said, I'm not sure how much bass these mics pick up anyway.)

Well, it might be, in the worst case.

Quoted 7 lines

Quoted 4 lines

The problem happens only when you sum the
left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal.

So the official recommendation is that summing left and right to make a mono signal, is to be considered an invalid operation?

It's not invalid in general but invalid for this digital mic. That's the only point. Thus, avoiding summing only for known bad devices is also a way to go, IMO. It'd work more or less stably. OTOH, muting the right reduces the risk but it also has a problem of the lower volume and the lack of right signal in stereo streams, both of which aren't easily avoided.

Quoted 1 line

So we need to find some point of compromise...

Avoiding summing only for known bad devices and only when mixer is set to capture Internal Mic, is a quite complex condition that would have to implemented in not only PulseAudio, but every application using ALSA directly. (Well, and wants to either sum, or to avoid loss of bass and strange stereo effects.)

The lower volume problem is also an argument only if you want to sum the signal; so in this case it's lower volume against a cancelled signal altogether, in which case lower volume is better.

That leaves the lack of right signal in stereo streams, as a disadvantage with the proposed solution. In which use cases do you think this is a problem?

At Wed, 29 Feb 2012 10:21:35 +0100,

Quoted 35 lines · David Henningsson

Quoted 33 lines · Takashi Iwai

At Tue, 28 Feb 2012 19:11:15 +0100,

Quoted 6 lines · David Henningsson

Quoted 4 lines · Takashi Iwai

Quoted 3 lines

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Quoted 7 lines

Quoted 2 lines

Well, when you record it in stereo, and play it back, then you hear the sound without problem.

That could definitely be questioned: depending on the distance between speakers when you're finally playing it back, you might lose bass frequencies [1]. (That said, I'm not sure how much bass these mics pick up anyway.)

Well, it might be, in the worst case.

Quoted 7 lines

Quoted 4 lines

The problem happens only when you sum the
left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal.

So the official recommendation is that summing left and right to make a mono signal, is to be considered an invalid operation?

It's not invalid in general but invalid for this digital mic. That's the only point. Thus, avoiding summing only for known bad devices is also a way to go, IMO. It'd work more or less stably. OTOH, muting the right reduces the risk but it also has a problem of the lower volume and the lack of right signal in stereo streams, both of which aren't easily avoided.

Quoted 7 lines

Quoted 1 line

So we need to find some point of compromise...

Avoiding summing only for known bad devices and only when mixer is set to capture Internal Mic, is a quite complex condition that would have to implemented in not only PulseAudio, but every application using ALSA directly. (Well, and wants to either sum, or to avoid loss of bass and strange stereo effects.)

As mentioned, ALSA-native "default" doesn't sum for mono signals. It's not optimal for stereo, yeah, but better than summing blindly.

Quoted 3 lines

The lower volume problem is also an argument only if you want to sum the signal; so in this case it's lower volume against a cancelled signal altogether, in which case lower volume is better.

Of course. But my comparison is "pick up only left" vs "sum but right-mute". In the latter case, the lower volume happens also in stereo streams (as a total volume), too.

Quoted 3 lines

That leaves the lack of right signal in stereo streams, as a disadvantage with the proposed solution. In which use cases do you think this is a problem?

Honestly, I don't know. It sounds really like a user's preference to me.

BTW, it'd be possible to give some offsets to the internal mic capture volume to compensate the lack of a stream.

Or, to make this behavior
selective via a mixer control. In either way (especially the latter) will make the code more complex. So the question still remains: how much compromise.

Hi,

Recently I came across a Conexant as well, and I decided to write a patch for it, that would take the approach that the internal mic is forced mono on the kcontrol, and make sure the right channel is always muted. The patch is verified by the reporter to fix this problem. It could use some perfection though - it would make sense to to the same to the internal mic boost as well, and the strcmp('Internal Mic') call could maybe be turned into something more elegant. But before going ahead with that, I'd like to hear your opinion on the matter, if you agree that this is a good approach to the problem?

References:

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/903853/+attachment/2631623/+files/alsa-info.txt.VmCN7lMBL4

https://bugs.launchpad.net/bugs/903853

Quoted 56 lines · Takashi Iwai

At Wed, 29 Feb 2012 10:21:35 +0100,

Quoted 35 lines · David Henningsson

Quoted 33 lines · Takashi Iwai

At Tue, 28 Feb 2012 19:11:15 +0100,

Quoted 6 lines · David Henningsson

Quoted 4 lines · Takashi Iwai

Quoted 3 lines

I'm talking about recording an internal mic in *stereo*, as I just wrote below. Or don't you agree that is a valid and probably fairly common use case?

Quoted 7 lines

Quoted 2 lines

Well, when you record it in stereo, and play it back, then you hear the sound without problem.

That could definitely be questioned: depending on the distance between speakers when you're finally playing it back, you might lose bass frequencies [1]. (That said, I'm not sure how much bass these mics pick up anyway.)

Well, it might be, in the worst case.

Quoted 7 lines

Quoted 4 lines

The problem happens only when you sum the
left and right signals into mono. Thus, as long as the stream is handled as stereo, it could be passed as is, although it's not optimal.

So the official recommendation is that summing left and right to make a mono signal, is to be considered an invalid operation?

It's not invalid in general but invalid for this digital mic. That's the only point. Thus, avoiding summing only for known bad devices is also a way to go, IMO. It'd work more or less stably. OTOH, muting the right reduces the risk but it also has a problem of the lower volume and the lack of right signal in stereo streams, both of which aren't easily avoided.

Quoted 7 lines

Quoted 1 line

So we need to find some point of compromise...

Avoiding summing only for known bad devices and only when mixer is set to capture Internal Mic, is a quite complex condition that would have to implemented in not only PulseAudio, but every application using ALSA directly. (Well, and wants to either sum, or to avoid loss of bass and strange stereo effects.)

As mentioned, ALSA-native "default" doesn't sum for mono signals. It's not optimal for stereo, yeah, but better than summing blindly.

Quoted 3 lines

The lower volume problem is also an argument only if you want to sum the signal; so in this case it's lower volume against a cancelled signal altogether, in which case lower volume is better.

Of course. But my comparison is "pick up only left" vs "sum but right-mute". In the latter case, the lower volume happens also in stereo streams (as a total volume), too.

Quoted 6 lines

Quoted 3 lines

That leaves the lack of right signal in stereo streams, as a disadvantage with the proposed solution. In which use cases do you think this is a problem?

Honestly, I don't know. It sounds really like a user's preference to me.

Ok.

Quoted 2 lines

BTW, it'd be possible to give some offsets to the internal mic capture volume to compensate the lack of a stream.

Hmm...could you elaborate on this? What type of offsets are you referring to?

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 4 lines

Quoted 2 lines

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?

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

Quoted 4 lines · David Henningsson <david.henningsson <at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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.

regards

--
Eliot

Machine details:
emachines 350
Codec: Realtek ALC272X
Vendor Id: 0x10ec0272
Subsystem Id: 0x10250349
Revision Id: 0x100001

_______________________________________________
Alsa-devel mailing list
[email protected]
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

Could you give alsa-info.sh output? This makes debugging a lot easier.

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 1 line

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).

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.

Quoted 9 lines · David Henningsson

Hi,

One of the more common problems on laptop machines, is that the internal mic provides a stereo signal but with one channel phase inverted, or differential output.

This means problems for applications recording two channels but later merging them into one, leaving them with zero or near-zero output.

If the mic capture looks phase inverted, this might actually be a way to reduce common mode noise on the pickup.
It might be a differential input for improved dynamic range. In which case, just dropping one of the channels is not the best, quality wise, option.
To get the highest quality output, it might be best to do a differential calculation.
I.e. Channel A - Channel B.

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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)?

At Thu, 21 Jun 2012 03:15:27 +0200,

Quoted 50 lines · David Henningsson

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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".

Quoted 2 lines

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.

Quoted 52 lines · Takashi Iwai

At Thu, 21 Jun 2012 03:15:27 +0200,

Quoted 50 lines · David Henningsson

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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".

Quoted 8 lines

Quoted 2 lines

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.

At Thu, 21 Jun 2012 15:04:44 +0200,

Quoted 72 lines · David Henningsson

Quoted 52 lines · Takashi Iwai

At Thu, 21 Jun 2012 03:15:27 +0200,

Quoted 50 lines · David Henningsson

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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".

Quoted 8 lines

Quoted 2 lines

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).

Quoted 2 lines

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.

Quoted 77 lines · Takashi Iwai

At Thu, 21 Jun 2012 15:04:44 +0200,

Quoted 74 lines · David Henningsson

Quoted 52 lines · Takashi Iwai

At Thu, 21 Jun 2012 03:15:27 +0200,

Quoted 50 lines · David Henningsson

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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".

Quoted 8 lines

Quoted 2 lines

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.

Quoted 3 lines

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.

It is always difficult to bet on the future, but sure, that's a drawback. So what were you suggesting instead, in a little more detail?

At Thu, 21 Jun 2012 16:23:48 +0200,

Quoted 83 lines · David Henningsson

Quoted 80 lines · Takashi Iwai

At Thu, 21 Jun 2012 15:04:44 +0200,

Quoted 67 lines · David Henningsson

Quoted 52 lines · Takashi Iwai

At Thu, 21 Jun 2012 03:15:27 +0200,

Quoted 50 lines · David Henningsson

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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".

Quoted 8 lines

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 2 lines

It is always difficult to bet on the future, but sure, that's a drawback. So what were you suggesting instead, in a little more detail?

Well, I thought of a mixer switch or enum to specify the inverted mic right-channel on/off. If right channel is off, the ADC right channel mute is set autotmatically when the d-mic is selected as the input source.

A test patch is below. It seems working with hda-emu.

(Actually in the case of ALC662 / ALC272x, it could be done in the
mixer widget; but it's more generic to fiddle with ADC mute.)

Takashi

---

sound/pci/hda/patch_realtek.c +35 -2

index 41475ae..dcc77d0 100644
@@ -170,6 +170,7 @@ struct alc_spec {
  	hda_nid_t imux_pins[HDA_MAX_NUM_INPUTS];
  	unsigned int dyn_adc_idx[HDA_MAX_NUM_INPUTS];
  	int int_mic_idx, ext_mic_idx, dock_mic_idx; /* for auto-mic */
+	hda_nid_t inv_dmic_pin;
 
  	/* hooks */
  	void (*init_hook)(struct hda_codec *codec);

@@ -201,6 +202,8 @@ struct alc_spec {
  	unsigned int vol_in_capsrc:1; /* use capsrc volume (ADC has no vol) */
  	unsigned int parse_flags; /* passed to snd_hda_parse_pin_defcfg() */
  	unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */
+	unsigned int inv_dmic_fixup:1;
+	unsigned int inv_dmic_enabled:1;
 
  	/* auto-mute control */
  	int automute_mode;

@@ -298,6 +301,7 @@ static inline hda_nid_t get_capsrc(struct alc_spec *spec, int idx)
  }
 
  static void call_update_outputs(struct hda_codec *codec);
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force);
 
  /* select the given imux item; either unmute exclusively or select the route */
  static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,

@@ -368,6 +372,7 @@ static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
  					  AC_VERB_SET_CONNECT_SEL,
  					  imux->items[idx].index);
  	}
+	alc_inv_dmic_sync(codec, true);
  	return 1;
  }
 

@@ -1556,14 +1561,14 @@ typedef int (*getput_call_t)(struct snd_kcontrol *kcontrol,
 
  static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
  				 struct snd_ctl_elem_value *ucontrol,
-				 getput_call_t func, bool check_adc_switch)
+				 getput_call_t func, bool is_put)
  {
  	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
  	struct alc_spec *spec = codec->spec;
  	int i, err = 0;
 
  	mutex_lock(&codec->control_mutex);
-	if (check_adc_switch&&  spec->dyn_adc_switch) {
+	if (is_put&&  spec->dyn_adc_switch) {
  		for (i = 0; i<  spec->num_adc_nids; i++) {
  			kcontrol->private_value =
  				HDA_COMPOSE_AMP_VAL(spec->adc_nids[i],

@@ -1584,6 +1589,8 @@ static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
  						    3, 0, HDA_INPUT);
  		err = func(kcontrol, ucontrol);
  	}
+	if (err>= 0&&  is_put)
+		alc_inv_dmic_sync(codec, false);
   error:
  	mutex_unlock(&codec->control_mutex);
  	return err;

@@ -1676,6 +1683,93 @@ DEFINE_CAPMIX_NOSRC(2);
  DEFINE_CAPMIX_NOSRC(3);
 
  /*
+ * Inverted digital-mic handling
+ */
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force)
+{
+	struct alc_spec *spec = codec->spec;
+	int i;
+
+	if (!spec->inv_dmic_fixup)
+		return;
+	if (spec->inv_dmic_enabled&&  !force)
+		return;
+	for (i = 0; i<  spec->num_adc_nids; i++) {
+		int src = spec->dyn_adc_switch ? 0 : i;
+		bool dmic_fixup = false;
+		hda_nid_t nid;
+		int parm, dir, v;
+
+		if (!spec->inv_dmic_enabled&&
+		    spec->imux_pins[spec->cur_mux[src]] == spec->inv_dmic_pin)
+			dmic_fixup = true;
+		if (!dmic_fixup&&  !force)
+			continue;
+		if (spec->vol_in_capsrc) {
+			nid = spec->capsrc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT;
+			dir = HDA_OUTPUT;

sound/pci/hda/patch_realtek.c +34 -0

+		snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
+				    parm | v);
+	}
+}
+
+static int alc_inv_dmic_sw_get(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	
+	ucontrol->value.integer.value[0] = spec->inv_dmic_enabled;
+	return 0;
+}
+
+static int alc_inv_dmic_sw_put(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	unsigned int val = !!ucontrol->value.integer.value[0];
+
+	if (val == spec->inv_dmic_enabled)
+		return 0;
+	spec->inv_dmic_enabled = val;
+	alc_inv_dmic_sync(codec, true);
+	return 0;
+}
+
+static const struct snd_kcontrol_new alc_inv_dmic_sw = {
+	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+	.info = snd_ctl_boolean_mono_info,
+	.get = alc_inv_dmic_sw_get,
+	.put = alc_inv_dmic_sw_put,

sound/pci/hda/patch_realtek.c +21 -0

+	spec->inv_dmic_fixup = 1;
+	spec->inv_dmic_enabled = 1;
+	spec->inv_dmic_pin = nid;
+	return 0;
+}
+
+/*
   * virtual master controls
   */
 

@@ -2316,6 +2410,7 @@ static int alc_resume(struct hda_codec *codec)
  	codec->patch_ops.init(codec);
  	snd_hda_codec_resume_amp(codec);
  	snd_hda_codec_resume_cache(codec);
+	alc_inv_dmic_sync(codec, true);
  	hda_call_check_power_status(codec, 0x01);
  	return 0;
  }

@@ -6424,6 +6519,13 @@ static void alc272_fixup_mario(struct hda_codec *codec,
  		       "hda_codec: failed to override amp caps for NID 0x2\n");
  }
 
+static void alc662_fixup_inv_dmic(struct hda_codec *codec,
+				  const struct alc_fixup *fix, int action)
+{
+	if (action == ALC_FIXUP_ACT_PROBE)
+		alc_add_inv_dmic_mixer(codec, 0x12);
+}
+
  enum {
  	ALC662_FIXUP_ASPIRE,
  	ALC662_FIXUP_IDEAPAD,

@@ -6441,6 +6543,7 @@ enum {
  	ALC662_FIXUP_ASUS_MODE8,
  	ALC662_FIXUP_NO_JACK_DETECT,
  	ALC662_FIXUP_ZOTAC_Z68,
+	ALC662_FIXUP_INV_DMIC,
  };
 
  static const struct alc_fixup alc662_fixups[] = {

@@ -6597,12 +6700,17 @@ static const struct alc_fixup alc662_fixups[] = {
  			{ }
  		}
  	},
+	[ALC662_FIXUP_INV_DMIC] = {
+		.type = ALC_FIXUP_FUNC,
+		.v.func = alc662_fixup_inv_dmic,
+	},
  };
 
  static const struct snd_pci_quirk alc662_fixup_tbl[] = {
  	SND_PCI_QUIRK(0x1019, 0x9087, "ECS", ALC662_FIXUP_ASUS_MODE2),
  	SND_PCI_QUIRK(0x1025, 0x0308, "Acer Aspire 8942G", ALC662_FIXUP_ASPIRE),
  	SND_PCI_QUIRK(0x1025, 0x031c, "Gateway NV79", ALC662_FIXUP_SKU_IGNORE),
+	SND_PCI_QUIRK(0x1025, 0x0349, "eMachines eM250", ALC662_FIXUP_INV_DMIC),
  	SND_PCI_QUIRK(0x1025, 0x038b, "Acer Aspire 8943G", ALC662_FIXUP_ASPIRE),
  	SND_PCI_QUIRK(0x103c, 0x1632, "HP RP5800", ALC662_FIXUP_HP_RP5800),
  	SND_PCI_QUIRK(0x1043, 0x8469, "ASUS mobo", ALC662_FIXUP_NO_JACK_DETECT),

Quoted 85 lines · Takashi Iwai

At Thu, 21 Jun 2012 16:23:48 +0200,

Quoted 83 lines · David Henningsson

Quoted 80 lines · Takashi Iwai

At Thu, 21 Jun 2012 15:04:44 +0200,

Quoted 67 lines · David Henningsson

Quoted 52 lines · Takashi Iwai

At Thu, 21 Jun 2012 03:15:27 +0200,

Quoted 50 lines · David Henningsson

Quoted 29 lines · Takashi Iwai

At Tue, 19 Jun 2012 09:43:07 +0200,

Quoted 27 lines · David Henningsson

Quoted 14 lines · Eliot Blennerhassett

Quoted 4 lines · David Henningsson<david.henningsson<at> canonical.com> writes:

Quoted 3 lines · Takashi Iwai

At Tue, 28 Feb 2012 14:07:59 +0100,
David Henningsson wrote:
Is there a way we can

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

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?

Quoted 5 lines

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:

Quoted 6 lines

Quoted 1 line

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 ;-)

Quoted 3 lines

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".

Quoted 8 lines

Quoted 2 lines

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.

Quoted 7 lines

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.

Quoted 7 lines

Quoted 2 lines

It is always difficult to bet on the future, but sure, that's a drawback. So what were you suggesting instead, in a little more detail?

Well, I thought of a mixer switch or enum to specify the inverted mic right-channel on/off. If right channel is off, the ADC right channel mute is set autotmatically when the d-mic is selected as the input source.

Ok. I think this approach is okay.

Quoted 2 lines

A test patch is below. It seems working with hda-emu.

Thanks for the patch. I haven't tested it, but just read it through, see comments below.

Quoted 106 lines

(Actually in the case of ALC662 / ALC272x, it could be done in the
mixer widget; but it's more generic to fiddle with ADC mute.)

Takashi

---

sound/pci/hda/patch_realtek.c +40 -2

index 41475ae..dcc77d0 100644
@@ -170,6 +170,7 @@ struct alc_spec {
  	hda_nid_t imux_pins[HDA_MAX_NUM_INPUTS];
  	unsigned int dyn_adc_idx[HDA_MAX_NUM_INPUTS];
  	int int_mic_idx, ext_mic_idx, dock_mic_idx; /* for auto-mic */
+	hda_nid_t inv_dmic_pin;
 
  	/* hooks */
  	void (*init_hook)(struct hda_codec *codec);

@@ -201,6 +202,8 @@ struct alc_spec {
  	unsigned int vol_in_capsrc:1; /* use capsrc volume (ADC has no vol) */
  	unsigned int parse_flags; /* passed to snd_hda_parse_pin_defcfg() */
  	unsigned int shared_mic_hp:1; /* HP/Mic-in sharing */
+	unsigned int inv_dmic_fixup:1;
+	unsigned int inv_dmic_enabled:1;
 
  	/* auto-mute control */
  	int automute_mode;

@@ -298,6 +301,7 @@ static inline hda_nid_t get_capsrc(struct alc_spec *spec, int idx)
  }
 
  static void call_update_outputs(struct hda_codec *codec);
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force);
 
  /* select the given imux item; either unmute exclusively or select the route */
  static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,

@@ -368,6 +372,7 @@ static int alc_mux_select(struct hda_codec *codec, unsigned int adc_idx,
  					  AC_VERB_SET_CONNECT_SEL,
  					  imux->items[idx].index);
  	}
+	alc_inv_dmic_sync(codec, true);
  	return 1;
  }
 

@@ -1556,14 +1561,14 @@ typedef int (*getput_call_t)(struct snd_kcontrol *kcontrol,
 
  static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
  				 struct snd_ctl_elem_value *ucontrol,
-				 getput_call_t func, bool check_adc_switch)
+				 getput_call_t func, bool is_put)
  {
  	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
  	struct alc_spec *spec = codec->spec;
  	int i, err = 0;
 
  	mutex_lock(&codec->control_mutex);
-	if (check_adc_switch&&  spec->dyn_adc_switch) {
+	if (is_put&&  spec->dyn_adc_switch) {
  		for (i = 0; i<  spec->num_adc_nids; i++) {
  			kcontrol->private_value =
  				HDA_COMPOSE_AMP_VAL(spec->adc_nids[i],

@@ -1584,6 +1589,8 @@ static int alc_cap_getput_caller(struct snd_kcontrol *kcontrol,
  						    3, 0, HDA_INPUT);
  		err = func(kcontrol, ucontrol);
  	}
+	if (err>= 0&&  is_put)
+		alc_inv_dmic_sync(codec, false);
   error:
  	mutex_unlock(&codec->control_mutex);
  	return err;

@@ -1676,6 +1683,93 @@ DEFINE_CAPMIX_NOSRC(2);
  DEFINE_CAPMIX_NOSRC(3);
 
  /*
+ * Inverted digital-mic handling
+ */
+static void alc_inv_dmic_sync(struct hda_codec *codec, bool force)
+{
+	struct alc_spec *spec = codec->spec;
+	int i;
+
+	if (!spec->inv_dmic_fixup)
+		return;
+	if (spec->inv_dmic_enabled&&  !force)
+		return;
+	for (i = 0; i<  spec->num_adc_nids; i++) {
+		int src = spec->dyn_adc_switch ? 0 : i;
+		bool dmic_fixup = false;
+		hda_nid_t nid;
+		int parm, dir, v;
+
+		if (!spec->inv_dmic_enabled&&
+		    spec->imux_pins[spec->cur_mux[src]] == spec->inv_dmic_pin)
+			dmic_fixup = true;
+		if (!dmic_fixup&&  !force)
+			continue;
+		if (spec->vol_in_capsrc) {
+			nid = spec->capsrc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_OUTPUT;
+			dir = HDA_OUTPUT;
+		} else {
+			nid = spec->adc_nids[i];
+			parm = AC_AMP_SET_RIGHT | AC_AMP_SET_INPUT;
+			dir = HDA_INPUT;
+		}

sound/pci/hda/patch_realtek.c DEFINE_CAPMIX_NOSRC(2); · line 1721

Quoted 5 lines

sound/pci/hda/patch_realtek.c +5 -0

+		v = snd_hda_codec_amp_read(codec, nid, 1, dir, 0);
+		if (v&  0x80) /* if already muted, we don't need to touch */
+			continue;
+		if (dmic_fixup) /* mute for d-mic required */
+			v |= 0x80;

This seems strange. Won't you need to manually unmute in some cases (if the "Inverted Capture" is manually turned on, or external mic is inserted)?

Maybe you mean like this:

new_value = dmic_fixup ? (v | 0x80) : (v & ~0x80); if (new_value == v)

	continue;

But then, what if you turn "Inverted Capture" on while "Capture Switch" is off...?

Quoted 39 lines

sound/pci/hda/patch_realtek.c +39 -0

+		snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_AMP_GAIN_MUTE,
+				    parm | v);
+	}
+}
+
+static int alc_inv_dmic_sw_get(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	
+	ucontrol->value.integer.value[0] = spec->inv_dmic_enabled;
+	return 0;
+}
+
+static int alc_inv_dmic_sw_put(struct snd_kcontrol *kcontrol,
+			       struct snd_ctl_elem_value *ucontrol)
+{
+	struct hda_codec *codec = snd_kcontrol_chip(kcontrol);
+	struct alc_spec *spec = codec->spec;
+	unsigned int val = !!ucontrol->value.integer.value[0];
+
+	if (val == spec->inv_dmic_enabled)
+		return 0;
+	spec->inv_dmic_enabled = val;
+	alc_inv_dmic_sync(codec, true);
+	return 0;
+}
+
+static const struct snd_kcontrol_new alc_inv_dmic_sw = {
+	.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
+	.info = snd_ctl_boolean_mono_info,
+	.get = alc_inv_dmic_sw_get,
+	.put = alc_inv_dmic_sw_put,
+};
+
+static int alc_add_inv_dmic_mixer(struct hda_codec *codec, hda_nid_t nid)
+{
+	struct alc_spec *spec = codec->spec;

sound/pci/hda/patch_realtek.c DEFINE_CAPMIX_NOSRC(2); · line 1765

Quoted 5 lines

sound/pci/hda/patch_realtek.c +5 -0

+	struct snd_kcontrol_new *knew = alc_kcontrol_new(spec);
+	if (!knew)
+		return -ENOMEM;
+	*knew = alc_inv_dmic_sw;
+	knew->name = kstrdup("Inverted Mic Capture Switch", GFP_KERNEL);

It should be "Inverted Internal Mic Capture Switch" (missing word "Internal").

/*
+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky. The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream. This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)

+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp. When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.

Quoted 7 lines · Takashi Iwai

/*
+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky. The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream. This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)

Stereo stereo? It's "stereo" in stereo! :-)

Quoted 7 lines

+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp. When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.

Ok, I get it now.

There is a slight drawback with this (IMO a bit hacky) patch, and that is that you can get a short signal spike on the right channel when you turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it is not a practical problem.

Thanks for looking at this long-standing problem :-)

At Fri, 22 Jun 2012 17:27:51 +0200,

Quoted 11 lines · David Henningsson

Quoted 7 lines · Takashi Iwai

   /*

+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky. The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream. This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)

Stereo stereo? It's "stereo" in stereo! :-)

Yeah, quad channels. Fixed now.

Quoted 8 lines

Quoted 7 lines

+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp. When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.

Quoted 6 lines

Ok, I get it now.

There is a slight drawback with this (IMO a bit hacky) patch, and that is that you can get a short signal spike on the right channel when you turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it is not a practical problem.

Right, I fully admit it's hacky :)

A good thing by this is, however, that it doesn't touch other parts too intrusively but just wraps over it.

Quoted 1 line

Thanks for looking at this long-standing problem :-)

I'm going to commit it once after hearing the test with a real machine from Eliot.

From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001

For users running Ubuntu 12.04 (I think Eliot does), I have also made a dkms package for easy testing of these two patches, and I also asked existing bug reporters to test it.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

[1 <text/plain; ISO-8859-1 (7bit)>]

Quoted 33 lines · Takashi Iwai

At Fri, 22 Jun 2012 17:27:51 +0200,

Quoted 11 lines · David Henningsson

Quoted 7 lines · Takashi Iwai

   /*

+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky. The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream. This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)

Stereo stereo? It's "stereo" in stereo! :-)

Yeah, quad channels. Fixed now.

Quoted 8 lines

Quoted 7 lines

+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp. When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.

Quoted 6 lines

Ok, I get it now.

There is a slight drawback with this (IMO a bit hacky) patch, and that is that you can get a short signal spike on the right channel when you turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it is not a practical problem.

Right, I fully admit it's hacky :)

Quoted 7 lines

A good thing by this is, however, that it doesn't touch other parts too intrusively but just wraps over it.

Quoted 1 line

Thanks for looking at this long-standing problem :-)

I'm going to commit it once after hearing the test with a real machine from Eliot.

Hi,

I'm adding the machines I know of in the patch attached (please commit together with your patch).

For users running Ubuntu 12.04 (I think Eliot does), I have also made a dkms package for easy testing of these two patches, and I also asked existing bug reporters to test it.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

Happy weekend!

Signature · 3 lines

David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
[2 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch <text/x-patch (7bit)>]

Quoted 1 line

From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001

From: David Henningsson <[email protected]>
Date: Fri, 22 Jun 2012 19:12:10 +0200
Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
1810TZ and AOD260

These machines have inverted phase on right channel for their internal mics.

Quoted 4 lines · David Henningsson

For users running Ubuntu 12.04 (I think Eliot does), I have also made a dkms package for easy testing of these two patches, and I also asked existing bug reporters to test it.

Quoted 1 line

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

Thanks David,

I can confirm that the right channel is muted when "Inverted Internal Mic" is "off". and e.g. skype test call works well.

BTW I initially assumed that "on" == "fix inverted internal mic" rather than "on" == "Enable Internal Mic Right Channel"

At Fri, 22 Jun 2012 19:33:06 +0200,

Quoted 67 lines · David Henningsson

[1 <text/plain; ISO-8859-1 (7bit)>]

Quoted 33 lines · Takashi Iwai

At Fri, 22 Jun 2012 17:27:51 +0200,

Quoted 11 lines · David Henningsson

Quoted 7 lines · Takashi Iwai

    /*

+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky. The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream. This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)

Stereo stereo? It's "stereo" in stereo! :-)

Yeah, quad channels. Fixed now.

Quoted 8 lines

Quoted 7 lines

+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp. When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.

Quoted 6 lines

Ok, I get it now.

There is a slight drawback with this (IMO a bit hacky) patch, and that is that you can get a short signal spike on the right channel when you turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it is not a practical problem.

Right, I fully admit it's hacky :)

Quoted 7 lines

A good thing by this is, however, that it doesn't touch other parts too intrusively but just wraps over it.

Quoted 1 line

Thanks for looking at this long-standing problem :-)

I'm going to commit it once after hearing the test with a real machine from Eliot.

Hi,

I'm adding the machines I know of in the patch attached (please commit together with your patch).

For users running Ubuntu 12.04 (I think Eliot does), I have also made a dkms package for easy testing of these two patches, and I also asked existing bug reporters to test it.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

Happy weekend!

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
[2 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch <text/x-patch (7bit)>]

Quoted 1 line

From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001

From: David Henningsson <[email protected]>
Date: Fri, 22 Jun 2012 19:12:10 +0200
Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
1810TZ and AOD260

Quoted 2 lines

These machines have inverted phase on right channel for their internal mics.

These are all ALC269, and we have already a workaround using the hardware COEF verb. Could you check whether it works or not? There are variants for alc269, alc269vb and alc271. One of them might match.

Quoted 69 lines · Takashi Iwai

At Fri, 22 Jun 2012 19:33:06 +0200,

Quoted 67 lines · David Henningsson

[1 <text/plain; ISO-8859-1 (7bit)>]

Quoted 33 lines · Takashi Iwai

At Fri, 22 Jun 2012 17:27:51 +0200,

Quoted 11 lines · David Henningsson

Quoted 7 lines · Takashi Iwai

    /*

+ * Inverted digital-mic handling
+ *
+ * First off, it's a bit tricky. The "Inverted Internal Mic Capture Switch"
+ * gives the additional mute only to the right channel of the digital mic
+ * capture stream. This is a workaround for avoiding the almost silence
+ * by summing the stereo stereo stream from some (known to be ForteMedia)

Stereo stereo? It's "stereo" in stereo! :-)

Yeah, quad channels. Fixed now.

Quoted 8 lines

Quoted 7 lines

+ * digital mic unit.
+ *
+ * The logic is to call alc_inv_dmic_sync() after each action (possibly)
+ * modifying ADC amp. When the mute flag is set, it mutes the R-channel
+ * without caching so that the cache can still keep the original value.
+ * The cached value is then restored when the flag is set off or any other
+ * than d-mic is used as the current input source.

Quoted 6 lines

Ok, I get it now.

There is a slight drawback with this (IMO a bit hacky) patch, and that is that you can get a short signal spike on the right channel when you turn "Capture Switch" on while "Inverted Capture" is off. Hopefully it is not a practical problem.

Right, I fully admit it's hacky :)

Quoted 7 lines

A good thing by this is, however, that it doesn't touch other parts too intrusively but just wraps over it.

Quoted 1 line

Thanks for looking at this long-standing problem :-)

I'm going to commit it once after hearing the test with a real machine from Eliot.

Hi,

I'm adding the machines I know of in the patch attached (please commit together with your patch).

For users running Ubuntu 12.04 (I think Eliot does), I have also made a dkms package for easy testing of these two patches, and I also asked existing bug reporters to test it.

https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1002978/+attachment/3200653/+files/alsa-hda-dkms_0.1_all.deb

Happy weekend!

--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
[2 0001-ALSA-hda-Add-inverted-mic-quirks-for-Asus-U41SV-Acer.patch <text/x-patch (7bit)>]

Quoted 1 line

From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001

From: David Henningsson <[email protected]>
Date: Fri, 22 Jun 2012 19:12:10 +0200
Subject: [PATCH] ALSA: hda - Add inverted mic quirks for Asus U41SV, Acer
1810TZ and AOD260

Quoted 7 lines

Quoted 2 lines

These machines have inverted phase on right channel for their internal mics.

These are all ALC269, and we have already a workaround using the hardware COEF verb. Could you check whether it works or not? There are variants for alc269, alc269vb and alc271. One of them might match.

Do we really have coefs for alc269vb?
The ALC269VB_FIXUP_DMIC fixup looks like it's pins only, and I've confirmed that the alc269 verb does not work for alc269vb, so I assume that verb is alc269va only.