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 >>>> 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. >> >> 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... -- David Henningsson, Canonical Ltd. http://launchpad.net/~diwic