[alsa-devel] [RFC PATCH] Inverted internal mic
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?
References:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/903853/+attachmen...
https://bugs.launchpad.net/bugs/903853
At Tue, 28 Feb 2012 09:57:56 +0100, David Henningsson wrote:
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
- we already have quirking infrastructure there
- we already have some working quirks already in that layer
- 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?
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.
Takashi
On 02/28/2012 10:24 AM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 09:57:56 +0100, David Henningsson wrote:
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
- we already have quirking infrastructure there
- we already have some working quirks already in that layer
- 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.
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?
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.
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, David Henningsson wrote:
On 02/28/2012 10:24 AM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 09:57:56 +0100, David Henningsson wrote:
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
- we already have quirking infrastructure there
- we already have some working quirks already in that layer
- 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.
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.
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.
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.
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?
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.
thanks,
Takashi
On 02/28/2012 11:38 AM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 10:54:00 +0100, David Henningsson wrote:
On 02/28/2012 10:24 AM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 09:57:56 +0100, David Henningsson wrote:
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
- we already have quirking infrastructure there
- we already have some working quirks already in that layer
- 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.
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?
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.
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.
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.
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?
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.
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.
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, David Henningsson wrote:
On 02/28/2012 11:38 AM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 10:54:00 +0100, David Henningsson wrote:
On 02/28/2012 10:24 AM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 09:57:56 +0100, David Henningsson wrote:
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
- we already have quirking infrastructure there
- we already have some working quirks already in that layer
- 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.
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?
AFAIK, no, it was specific to the codec model.
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.
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.
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.
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.
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?
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.
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.
It's actually already handled in ALSA. It's just PA that ignores it via "hw" PCM :) Of course, I don't mean that the handling in alsa-lib config is perfect, and it's a workaround.
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.
Yes, that's the problem.
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...
Yes. I don't think it's appropriate, too.
Takashi
On 02/28/2012 02:22 PM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 14:07:59 +0100, David Henningsson wrote:
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?
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.
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?
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.
At Tue, 28 Feb 2012 15:19:16 +0100, David Henningsson wrote:
On 02/28/2012 02:22 PM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 14:07:59 +0100, David Henningsson wrote:
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?
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.
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?
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.
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.
Takashi
On 02/28/2012 04:20 PM, Takashi Iwai wrote:
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.
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.)
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, David Henningsson wrote:
On 02/28/2012 04:20 PM, Takashi Iwai wrote:
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.
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.
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...
Takashi
On 02/28/2012 08:42 PM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 19:11:15 +0100, David Henningsson wrote:
On 02/28/2012 04:20 PM, Takashi Iwai wrote:
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.
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.
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...
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, David Henningsson wrote:
On 02/28/2012 08:42 PM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 19:11:15 +0100, David Henningsson wrote:
On 02/28/2012 04:20 PM, Takashi Iwai wrote:
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.
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.
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...
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.
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.
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.
thanks,
Takashi
On 02/29/2012 10:56 AM, Takashi Iwai wrote:
At Wed, 29 Feb 2012 10:21:35 +0100, David Henningsson wrote:
On 02/28/2012 08:42 PM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 19:11:15 +0100, David Henningsson wrote:
On 02/28/2012 04:20 PM, Takashi Iwai wrote:
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.
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.
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...
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.
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.
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.
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?
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.
At Wed, 29 Feb 2012 11:45:40 +0100, David Henningsson wrote:
On 02/29/2012 10:56 AM, Takashi Iwai wrote:
At Wed, 29 Feb 2012 10:21:35 +0100, David Henningsson wrote:
On 02/28/2012 08:42 PM, Takashi Iwai wrote:
At Tue, 28 Feb 2012 19:11:15 +0100, David Henningsson wrote:
On 02/28/2012 04:20 PM, Takashi Iwai wrote:
> 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.
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.
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...
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.
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.
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.
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?
cx5051 has separate capture volumes and I thought of adding a base dB offset (+6dB) only to digital-mic so that it'll be higher than other inputs.
Takashi
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.
regards
-- Eliot
Machine details: emachines 350 Codec: Realtek ALC272X Vendor Id: 0x10ec0272 Subsystem Id: 0x10250349 Revision Id: 0x100001
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
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).
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.
Takashi
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)?
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.
Takashi
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.
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
On 06/21/2012 03:19 PM, Takashi Iwai wrote:
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.
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?
Maybe making "virtual" volume controls, that would only be affecting the node when the actual input is selected?
At Thu, 21 Jun 2012 16:23:48 +0200, David Henningsson wrote:
On 06/21/2012 03:19 PM, Takashi Iwai wrote:
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.
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
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 41475ae..dcc77d0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -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; + } + 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; + 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; + 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); + 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),
On 06/22/2012 11:33 AM, Takashi Iwai wrote:
At Thu, 21 Jun 2012 16:23:48 +0200, David Henningsson wrote:
On 06/21/2012 03:19 PM, Takashi Iwai wrote:
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.
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.
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.
(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
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 41475ae..dcc77d0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -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);@@ -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;}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...?
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;
- 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").
- 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),
At Fri, 22 Jun 2012 12:46:55 +0200, David Henningsson wrote:
On 06/22/2012 11:33 AM, Takashi Iwai wrote:
At Thu, 21 Jun 2012 16:23:48 +0200, David Henningsson wrote:
On 06/21/2012 03:19 PM, Takashi Iwai wrote:
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.
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.
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.
(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
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 41475ae..dcc77d0 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -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);@@ -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;}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)?
Yes, it'll be restored. The check "if (v & 0x80)" is only an optimization.
Maybe you mean like this:
new_value = dmic_fixup ? (v | 0x80) : (v & ~0x80); if (new_value == v) continue;
No, this function does only either adding the artificial R-ch mute (when dmix_fiup=1) or restoring the cached value (dmix_fixup=0). And the actual value isn't the value returned from snd_hda_codec_amp_read().
OK, the code is a bit tricky -- I try to explain more. alc_inv_dmic_sync() is called always after some action has been done for ADC amp. Then it checks whether the current input source is d-mic and the fix is needed. If yes, it executes the amp verb with the mute bit, but _without caching_. In that way, the original values of the capture vol/switch are kept there.
When the fix is disabled, the cached values are restored. It's called with force=true.
But then, what if you turn "Inverted Capture" on while "Capture Switch" is off...?
It works because the mute bit is _added_.
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;
- 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").
OK, will change.
Takashi
OK, below is the respin with more comments. Eliot, could you check whether the patch works?
thanks,
Takashi
--- From: Takashi Iwai tiwai@suse.de Subject: [PATCH] ALSA: hda - Add the inverted digital mic workaround to Realtek codecs
Some laptops are equipped with ForteMedia digital mics that give the differential input. With such devices, summing stereo streams into a mono (like PulseAudio does) results in almost silence.
This patch provides a workaround for this bug by adding a new mixer switch to turn on/off the right channel of digital mic, just like a similar fix for Conexant codecs.
When the new switch "Inverted Internal Mic Capture Switch" is off and the current input source is the digital mic, the right channel of the recording stream is muted. When another input source is selected, the right channel is restored.
Signed-off-by: Takashi Iwai tiwai@suse.de --- sound/pci/hda/patch_realtek.c | 127 ++++++++++++++++++++++++++++++++++++++++- 1 file changed, 125 insertions(+), 2 deletions(-)
diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index f8f4906..5c2270b 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -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; /* has inverted digital-mic workaround */ + unsigned int inv_dmic_muted:1; /* R-ch of inv d-mic is muted? */
/* 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,108 @@ DEFINE_CAPMIX_NOSRC(2); DEFINE_CAPMIX_NOSRC(3);
/* + * 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. + */ +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_muted && !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_muted && + 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; + } + /* we care only right channel */ + 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) /* add mute for d-mic */ + v |= 0x80; + 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_muted; + 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_muted) + return 0; + spec->inv_dmic_muted = 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; + struct snd_kcontrol_new *knew = alc_kcontrol_new(spec); + if (!knew) + return -ENOMEM; + *knew = alc_inv_dmic_sw; + knew->name = kstrdup("Inverted Internal Mic Capture Switch", GFP_KERNEL); + if (!knew->name) + return -ENOMEM; + spec->inv_dmic_fixup = 1; + spec->inv_dmic_muted = 0; + spec->inv_dmic_pin = nid; + return 0; +} + +/* * virtual master controls */
@@ -2316,6 +2425,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 +6534,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 +6558,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 +6715,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),
On 06/22/2012 02:46 PM, Takashi Iwai wrote:
/*
- 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! :-)
- 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, David Henningsson wrote:
On 06/22/2012 02:46 PM, Takashi Iwai wrote:
/*
- 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.
- 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.
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.
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.
Thanks for your review!
Takashi
On 06/22/2012 05:37 PM, Takashi Iwai wrote:
At Fri, 22 Jun 2012 17:27:51 +0200, David Henningsson wrote:
On 06/22/2012 02:46 PM, Takashi Iwai wrote:
/*
- 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.
- 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.
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.
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/+attachme...
Happy weekend!
On 23/06/12 05:33, David Henningsson wrote:
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/+attachme...
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 Sat, 23 Jun 2012 14:58:31 +1200, Eliot Blennerhassett wrote:
On 23/06/12 05:33, David Henningsson wrote:
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/+attachme...
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.
Thanks, I'll apply the patch later then.
BTW I initially assumed that "on" == "fix inverted internal mic" rather than "on" == "Enable Internal Mic Right Channel"
It's no "mute" switch but "enable" switch. I follow the logic in conexant codec driver. (But yes, it's a bit confusing.)
Takashi
At Fri, 22 Jun 2012 19:33:06 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] On 06/22/2012 05:37 PM, Takashi Iwai wrote:
At Fri, 22 Jun 2012 17:27:51 +0200, David Henningsson wrote:
On 06/22/2012 02:46 PM, Takashi Iwai wrote:
/*
- 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.
- 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.
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.
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/+attachme...
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)>]
From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
From: David Henningsson david.henningsson@canonical.com 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.
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.
The patch below adds model strings for these fixups for convenience.
Takashi
--- diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 41475ae..ed40c91 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -6031,6 +6031,9 @@ static const struct snd_pci_quirk alc269_fixup_tbl[] = { static const struct alc_model_fixup alc269_fixup_models[] = { {.id = ALC269_FIXUP_AMIC, .name = "laptop-amic"}, {.id = ALC269_FIXUP_DMIC, .name = "laptop-dmic"}, + {.id = ALC269_FIXUP_STEREO_DMIC, .name = "alc269-dmic"}, + {.id = ALC269VB_FIXUP_DMIC, .name = "alc269vb-dmic"}, + {.id = ALC271_FIXUP_DMIC, .name = "alc271-dmic"}, {} };
On 06/23/2012 10:39 AM, Takashi Iwai wrote:
At Fri, 22 Jun 2012 19:33:06 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] On 06/22/2012 05:37 PM, Takashi Iwai wrote:
At Fri, 22 Jun 2012 17:27:51 +0200, David Henningsson wrote:
On 06/22/2012 02:46 PM, Takashi Iwai wrote:
/*
- 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.
- 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.
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.
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/+attachme...
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)>]
From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
From: David Henningsson david.henningsson@canonical.com 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.
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.
Am I missing something?
At Mon, 25 Jun 2012 10:04:26 +0200, David Henningsson wrote:
On 06/23/2012 10:39 AM, Takashi Iwai wrote:
At Fri, 22 Jun 2012 19:33:06 +0200, David Henningsson wrote:
[1 <text/plain; ISO-8859-1 (7bit)>] On 06/22/2012 05:37 PM, Takashi Iwai wrote:
At Fri, 22 Jun 2012 17:27:51 +0200, David Henningsson wrote:
On 06/22/2012 02:46 PM, Takashi Iwai wrote:
/*
- 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.
- 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.
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.
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/+attachme...
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)>]
From d4e041e6d5077b061eb99954e9d71a5ad5f8f4de Mon Sep 17 00:00:00 2001
From: David Henningsson david.henningsson@canonical.com 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.
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.
Ah, right. I forgot that it's specific to ALC269, not VB variant. I'll apply your patch, then.
thanks,
Takashi
At Tue, 19 Jun 2012 03:07:40 +0000 (UTC), 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.
Could you give alsa-info.sh output? This makes debugging a lot easier.
thanks,
Takashi
regards
-- Eliot
Machine details: emachines 350 Codec: Realtek ALC272X Vendor Id: 0x10ec0272 Subsystem Id: 0x10250349 Revision Id: 0x100001
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
On 20/06/12 20:02, Takashi Iwai wrote:
Could you give alsa-info.sh output? This makes debugging a lot easier.
upload=true&script=true&cardinfo= !!################################ !!ALSA Information Script v 0.4.61 !!################################
!!Script ran on: Mon Jun 18 01:44:02 UTC 2012
!!Linux Distribution !!------------------
Ubuntu 12.04 LTS \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 12.04 LTS"
!!DMI Information !!---------------
Manufacturer: eMachines Product Name: eM350 Product Version: V1.06 Firmware Version: V1.06
!!Kernel Information !!------------------
Kernel release: 3.2.0-25-generic-pae Operating System: GNU/Linux Architecture: i686 Processor: i686 SMP Enabled: Yes
!!ALSA Version !!------------
Driver version: 1.0.24 Library version: 1.0.25 Utilities version: 1.0.25
!!Loaded ALSA modules !!-------------------
snd_hda_intel
!!Sound Servers on this system !!----------------------------
Pulseaudio: Installed - Yes (/usr/bin/pulseaudio) Running - Yes
Jack: Installed - Yes (/usr/bin/jackd) Running - No
!!Soundcards recognised by ALSA !!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel HDA Intel at 0x54200000 irq 44
!!PCI Soundcards installed in the system !!--------------------------------------
00:1b.0 Audio device: Intel Corporation N10/ICH 7 Family High Definition Audio Controller (rev 02)
!!Advanced information - PCI Vendor/Device/Subsystem ID's !!-------------------------------------------------------
00:1b.0 0403: 8086:27d8 (rev 02) Subsystem: 1025:0349
!!Modprobe options (Sound related) !!--------------------------------
snd-atiixp-modem: index=-2 snd-intel8x0m: index=-2 snd-via82xx-modem: index=-2 snd-usb-audio: index=-2 snd-usb-caiaq: index=-2 snd-usb-ua101: index=-2 snd-usb-us122l: index=-2 snd-usb-usx2y: index=-2 snd-cmipci: mpu_port=0x330 fm_port=0x388 snd-pcsp: index=-2 snd-usb-audio: index=-2
!!Loaded sound module options !!---------------------------
!!Module: snd_hda_intel align_buffer_size : Y bdl_pos_adj : 1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 beep_mode : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 enable : Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y,Y enable_msi : -1 id : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) index : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 model : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) patch : (null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null) position_fix : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 power_save : 0 power_save_controller : Y probe_mask : -1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 probe_only : 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0 single_cmd : N snoop : Y
!!HDA-Intel Codec information !!--------------------------- --startcollapse--
Codec: Realtek ALC272X Address: 0 AFG Function Id: 0x1 (unsol 1) Vendor Id: 0x10ec0272 Subsystem Id: 0x10250349 Revision Id: 0x100001 No Modem Function Group found Default PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Default Amp-In caps: N/A Default Amp-Out caps: N/A GPIO: io=2, o=0, i=0, unsolicited=1, wake=0 IO[0]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0, unsol=0 Node 0x02 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Headphone Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="ALC272X Analog", type="Audio", device=0 Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] Converter: stream=8, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x03 [Audio Output] wcaps 0x41d: Stereo Amp-Out Control: name="Speaker Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] Converter: stream=8, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x04 [Audio Output] wcaps 0x41d: Stereo Amp-Out Amp-Out caps: ofs=0x40, nsteps=0x40, stepsize=0x03, mute=0 Amp-Out vals: [0x40 0x40] Converter: stream=0, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x05 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x06 [Audio Output] wcaps 0x611: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x07 [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x08 [Audio Input] wcaps 0x10051b: Stereo Amp-In Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x8b 0x8b] Converter: stream=0, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x23 Node 0x09 [Audio Input] wcaps 0x10051b: Stereo Amp-In Control: name="Capture Switch", index=0, device=0 Control: name="Capture Volume", index=0, device=0 Device: name="ALC272X Analog", type="Audio", device=0 Amp-In caps: ofs=0x0b, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x90 0x90] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x22 Node 0x0a [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x0b [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Control: name="Mic Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Beep Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Control: name="Beep Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=In, idx=4, ofs=0 Amp-In caps: ofs=0x17, nsteps=0x1f, stepsize=0x05, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 8 0x18 0x19 0x1a 0x1b 0x1d 0x14 0x15 0x16 Node 0x0c [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x02 0x0b Node 0x0d [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Connection: 2 0x03 0x0b Node 0x0e [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00 0x00] [0x80 0x80] Connection: 2 0x04 0x0b Node 0x0f [Audio Mixer] wcaps 0x20010a: Mono Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x00] [0x80] Connection: 2 0x02 0x0b Node 0x10 [Audio Output] wcaps 0x611: Stereo Digital Converter: stream=0, channel=0 Digital: Digital category: 0x0 PCM: rates [0x5e0]: 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x11 [Pin Complex] wcaps 0x400700: Mono Digital Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x10 Node 0x12 [Pin Complex] wcaps 0x400401: Stereo Pincap 0x00000020: IN Pin Default 0x99a30920: [Fixed] Mic at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x2, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x13 [Pin Complex] wcaps 0x400401: Stereo Pincap 0x00000020: IN Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x14 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Speaker Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0001003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x99130110: [Fixed] Speaker at Int ATAPI Conn = ATAPI, Color = Unknown DefAssociation = 0x1, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c 0x0d* Node 0x15 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0001003c: IN OUT HP EAPD Detect EAPD 0x2: EAPD Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 2 0x0c* 0x0d Node 0x16 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00000034: IN OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0e Node 0x17 [Pin Complex] wcaps 0x40050c: Mono Amp-Out Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80] Pincap 0x00000010: OUT Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x00: Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0f Node 0x18 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Control: name="Mic Boost Volume", index=0, device=0 ControlAmp: chs=3, dir=In, idx=0, ofs=0 Control: name="Mic Jack", index=0, device=0 Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00001734: IN OUT Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x03a19830: [Jack] Mic at Ext Left Conn = 1/8, Color = Pink DefAssociation = 0x3, Sequence = 0x0 Pin-ctls: 0x24: IN VREF_80 Unsolicited: tag=02, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0e Node 0x19 [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000173c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 3 0x0c* 0x0d 0x0e Node 0x1a [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x00001734: IN OUT Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x0d Node 0x1b [Pin Complex] wcaps 0x40058f: Stereo Amp-In Amp-Out Amp-In caps: ofs=0x00, nsteps=0x03, stepsize=0x27, mute=0 Amp-In vals: [0x00 0x00] Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80] Pincap 0x0000173c: IN OUT HP Detect Vref caps: HIZ 50 GRD 80 Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x20: IN VREF_HIZ Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 3 0x0c* 0x0d 0x0e Node 0x1c [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x1d [Pin Complex] wcaps 0x400400: Mono Pincap 0x00000020: IN Pin Default 0x4016892d: [N/A] Speaker at Ext N/A Conn = Digital, Color = Purple DefAssociation = 0x2, Sequence = 0xd Misc = NO_PRESENCE Pin-ctls: 0x20: IN Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Node 0x1e [Pin Complex] wcaps 0x400780: Mono Digital Pincap 0x00000014: OUT Detect Pin Default 0x411111f0: [N/A] Speaker at Ext Rear Conn = 1/8, Color = Black DefAssociation = 0xf, Sequence = 0x0 Misc = NO_PRESENCE Pin-ctls: 0x40: OUT Unsolicited: tag=00, enabled=0 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 1 0x06 Node 0x1f [Vendor Defined Widget] wcaps 0xf00000: Mono Node 0x20 [Vendor Defined Widget] wcaps 0xf00040: Mono Processing caps: benign=0, ncoeff=17 Node 0x21 [Pin Complex] wcaps 0x40058d: Stereo Amp-Out Control: name="Headphone Playback Switch", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Control: name="Headphone Jack", index=0, device=0 Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00] Pincap 0x0000001c: OUT HP Detect Pin Default 0x0321401f: [Jack] HP Out at Ext Left Conn = 1/8, Color = Green DefAssociation = 0x1, Sequence = 0xf Pin-ctls: 0xc0: OUT HP Unsolicited: tag=01, enabled=1 Power states: D0 D1 D2 D3 EPSS Power: setting=D0, actual=D0 Connection: 3 0x0c* 0x0d 0x0e Node 0x22 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x00 0x00] Connection: 10 0x18 0x19 0x1a 0x1b 0x1d 0x14 0x15 0x16 0x0b 0x12 Node 0x23 [Audio Mixer] wcaps 0x20010b: Stereo Amp-In Amp-In caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-In vals: [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] [0x80 0x80] Connection: 10 0x18 0x19 0x1a 0x1b 0x1d 0x14 0x15 0x16 0x0b 0x13 --endcollapse--
!!ALSA Device nodes !!-----------------
crw-rw---T+ 1 root audio 116, 5 Jun 18 13:40 /dev/snd/controlC0 crw-rw---T+ 1 root audio 116, 4 Jun 18 13:40 /dev/snd/hwC0D0 crw-rw---T+ 1 root audio 116, 3 Jun 18 13:40 /dev/snd/pcmC0D0c crw-rw---T+ 1 root audio 116, 2 Jun 18 13:40 /dev/snd/pcmC0D0p crw-rw---T+ 1 root audio 116, 1 Jun 18 13:40 /dev/snd/seq crw-rw---T+ 1 root audio 116, 33 Jun 18 13:40 /dev/snd/timer
/dev/snd/by-path: total 0 drwxr-xr-x 2 root root 60 Jun 18 13:40 . drwxr-xr-x 3 root root 180 Jun 18 13:40 .. lrwxrwxrwx 1 root root 12 Jun 18 13:40 pci-0000:00:1b.0 -> ../controlC0
!!Aplay/Arecord output !!--------------------
APLAY
**** List of PLAYBACK Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC272X Analog [ALC272X Analog] Subdevices: 1/1 Subdevice #0: subdevice #0
ARECORD
**** List of CAPTURE Hardware Devices **** card 0: Intel [HDA Intel], device 0: ALC272X Analog [ALC272X Analog] Subdevices: 1/1 Subdevice #0: subdevice #0
!!Amixer output !!-------------
!!-------Mixer controls for card 0 [Intel]
Card hw:0 'Intel'/'HDA Intel at 0x54200000 irq 44' Mixer name : 'Realtek ALC272X' Components : 'HDA:10ec0272,10250349,00100001' Controls : 17 Simple ctrls : 9 Simple mixer control 'Master',0 Capabilities: pvolume pvolume-joined pswitch pswitch-joined penum Playback channels: Mono Limits: Playback 0 - 64 Mono: Playback 64 [100%] [0.00dB] [on] Simple mixer control 'Headphone',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 64 [100%] [0.00dB] [on] Front Right: Playback 64 [100%] [0.00dB] [on] Simple mixer control 'Speaker',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 64 Mono: Front Left: Playback 64 [100%] [0.00dB] [on] Front Right: Playback 64 [100%] [0.00dB] [on] Simple mixer control 'PCM',0 Capabilities: pvolume penum Playback channels: Front Left - Front Right Limits: Playback 0 - 255 Mono: Front Left: Playback 255 [100%] [0.00dB] Front Right: Playback 255 [100%] [0.00dB] Simple mixer control 'Mic',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Mic Boost',0 Capabilities: volume penum Playback channels: Front Left - Front Right Capture channels: Front Left - Front Right Limits: 0 - 3 Front Left: 0 [0%] [0.00dB] Front Right: 0 [0%] [0.00dB] Simple mixer control 'Beep',0 Capabilities: pvolume pswitch penum Playback channels: Front Left - Front Right Limits: Playback 0 - 31 Mono: Front Left: Playback 0 [0%] [-34.50dB] [off] Front Right: Playback 0 [0%] [-34.50dB] [off] Simple mixer control 'Capture',0 Capabilities: cvolume cswitch penum Capture channels: Front Left - Front Right Limits: Capture 0 - 31 Front Left: Capture 16 [52%] [7.50dB] [off] Front Right: Capture 16 [52%] [7.50dB] [off] Simple mixer control 'Auto-Mute Mode',0 Capabilities: enum Items: 'Disabled' 'Enabled' Item0: 'Disabled'
!!Alsactl output !!--------------
--startcollapse-- state.Intel { control.1 { iface MIXER name 'Headphone Playback Volume' value.0 64 value.1 64 comment { access 'read write' type INTEGER count 2 range '0 - 64' dbmin -6400 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.2 { iface MIXER name 'Headphone Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.3 { iface MIXER name 'Speaker Playback Volume' value.0 64 value.1 64 comment { access 'read write' type INTEGER count 2 range '0 - 64' dbmin -6400 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } control.4 { iface MIXER name 'Speaker Playback Switch' value.0 true value.1 true comment { access 'read write' type BOOLEAN count 2 } } control.5 { iface MIXER name 'Mic Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -3450 dbvalue.1 -3450 } } control.6 { iface MIXER name 'Mic Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.7 { iface MIXER name 'Auto-Mute Mode' value Disabled comment { access 'read write' type ENUMERATED count 1 item.0 Disabled item.1 Enabled } } control.8 { iface MIXER name 'Mic Boost Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 3' dbmin 0 dbmax 3000 dbvalue.0 0 dbvalue.1 0 } } control.9 { iface MIXER name 'Capture Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.10 { iface MIXER name 'Capture Volume' value.0 16 value.1 16 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -1650 dbmax 3000 dbvalue.0 750 dbvalue.1 750 } } control.11 { iface MIXER name 'Beep Playback Volume' value.0 0 value.1 0 comment { access 'read write' type INTEGER count 2 range '0 - 31' dbmin -3450 dbmax 1200 dbvalue.0 -3450 dbvalue.1 -3450 } } control.12 { iface MIXER name 'Beep Playback Switch' value.0 false value.1 false comment { access 'read write' type BOOLEAN count 2 } } control.13 { iface MIXER name 'Master Playback Volume' value 64 comment { access 'read write' type INTEGER count 1 range '0 - 64' dbmin -6400 dbmax 0 dbvalue.0 0 } } control.14 { iface MIXER name 'Master Playback Switch' value true comment { access 'read write' type BOOLEAN count 1 } } control.15 { iface CARD name 'Headphone Jack' value false comment { access read type BOOLEAN count 1 } } control.16 { iface CARD name 'Mic Jack' value false comment { access read type BOOLEAN count 1 } } control.17 { iface MIXER name 'PCM Playback Volume' value.0 255 value.1 255 comment { access 'read write user' type INTEGER count 2 range '0 - 255' tlv '0000000100000008ffffec1400000014' dbmin -5100 dbmax 0 dbvalue.0 0 dbvalue.1 0 } } } --endcollapse--
!!All Loaded Modules !!------------------
Module dm_crypt bcma arc4 joydev acer_wmi sparse_keymap snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device brcmsmac uvcvideo videodev psmouse bnep serio_raw rfcomm snd bluetooth mac80211 parport_pc ppdev brcmutil soundcore cfg80211 crc8 snd_page_alloc cordic mac_hid lp parport i915 drm_kms_helper drm atl1c i2c_algo_bit video wmi
!!Sysfs Files !!-----------
/sys/class/sound/hwC0D0/init_pin_configs: 0x11 0x411111f0 0x12 0x99a30920 0x13 0x411111f0 0x14 0x99130110 0x15 0x411111f0 0x16 0x411111f0 0x17 0x411111f0 0x18 0x03a19830 0x19 0x411111f0 0x1a 0x411111f0 0x1b 0x411111f0 0x1d 0x4016892d 0x1e 0x411111f0 0x21 0x0321401f
/sys/class/sound/hwC0D0/driver_pin_configs:
/sys/class/sound/hwC0D0/user_pin_configs:
/sys/class/sound/hwC0D0/init_verbs:
!!ALSA/HDA dmesg !!--------------
[ 21.319382] type=1400 audit(1339983621.365:9): apparmor="STATUS" operation="profile_replace" name="/usr/lib/connman/scripts/dhclient-script" pid=824 comm="apparmor_parser" [ 21.325408] snd_hda_intel 0000:00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 21.325547] snd_hda_intel 0000:00:1b.0: irq 44 for MSI/MSI-X [ 21.325617] snd_hda_intel 0000:00:1b.0: setting latency timer to 64 [ 21.362113] type=1400 audit(1339983621.409:10): apparmor="STATUS" operation="profile_load" name="/usr/lib/lightdm/lightdm/lightdm-guest-session-wrapper" pid=823 comm="apparmor_parser" [ 21.433174] type=1400 audit(1339983621.481:11): apparmor="STATUS" operation="profile_load" name="/usr/lib/telepathy/mission-control-5" pid=844 comm="apparmor_parser" [ 21.482824] input: HDA Intel Mic as /devices/pci0000:00/0000:00:1b.0/sound/card0/input8 [ 21.495264] input: HDA Intel Headphone as /devices/pci0000:00/0000:00:1b.0/sound/card0/input9 [ 21.524275] atl1c 0000:01:00.0: irq 45 for MSI/MSI-X
2012/2/28, David Henningsson david.henningsson@canonical.com:
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/+attachmen...
Refer to the codec info
It seem that there is a path from [Audio Output] 0x10 through 0x24 to [Audio Input]
Is there any technical reason for not implement "Stereo Mix" as "Input Source" ?
Node 0x10 [Audio Output] wcaps 0xc1d: Stereo Amp-Out R/L Control: name="Master Playback Volume", index=0, device=0 ControlAmp: chs=3, dir=Out, idx=0, ofs=0 Device: name="CONEXANT Analog", type="Audio", device=0 Amp-Out caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-Out vals: [0x4a 0x4a] Converter: stream=8, channel=0 PCM: rates [0x560]: 44100 48000 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0
Node 0x14 [Audio Input] wcaps 0x100d1b: Stereo Amp-In R/L Device: name="CONEXANT Analog", type="Audio", device=0 Amp-In caps: ofs=0x4a, nsteps=0x50, stepsize=0x03, mute=1 Amp-In vals: [0x50 0x50] [0x80 0x80] [0x50 0x50] [0x80 0x80] Converter: stream=4, channel=0 SDI-Select: 0 PCM: rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x1]: PCM Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 4 0x17 0x18 0x23* 0x24
Node 0x24 [Audio Mixer] wcaps 0x20050b: Stereo Amp-In Amp-In caps: ofs=0x4a, nsteps=0x4a, stepsize=0x03, mute=1 Amp-In vals: [0x00 0x00] [0x00 0x00] Power states: D0 D1 D2 D3 D3cold EPSS Power: setting=D0, actual=D0 Connection: 2 0x10 0x11
On 28 February 2012 08:57, David Henningsson david.henningsson@canonical.com wrote:
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. The problem being, if the input is 16bits, the Channel A - Channel B is 17bits. Can any tests be done to see if Channel A - Channel B has a better S/N ratio than simply dropping channel B, and copy channel A to channel B?
Kind Regards
James
At Wed, 20 Jun 2012 22:53:08 +0100, James Courtier-Dutton wrote:
On 28 February 2012 08:57, David Henningsson david.henningsson@canonical.com wrote:
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.
Yes. And this is just like B is phase inverted in the end. (So usually divided by 2, too).
The bigger problem is that the change of input sources may happen on the fly during recording. And, usually such a PDM source is only the digital built-in mic. If you switch to another source, "A - B" results again in a wrong output.
Takashi
participants (5)
-
David Henningsson -
Eliot Blennerhassett -
James Courtier-Dutton -
Raymond Yau -
Takashi Iwai