On Tue, 2012-05-08 at 18:17 +0300, Tanu Kaskinen wrote: > On Tue, 2012-05-08 at 06:02 -0700, David Henningsson wrote: > > 2012-05-07 20:06, Arun Raghavan skrev: > > > The separate mics may eventually be useful for beamforming and > > > associated processing. Would your approach require changes to alsa-lib > > > again if we wanted to do that? If yes, it might be better to let > > > PulseAudio take care of this. > > The attached patch (untested!) would just add the possibility to do a > > four-to-two channel mixdown when you open front:%f (for the cards > > explicitly selected in the patch), so for four-channel beamforming you > > could still open hw:%f in four channel mode. > > That would still require special profiles in Pulseaudio... > > So, we have three options on the table: > > 1) Have a generic 4-channel input mapping in default.conf. > - Provides access to all four channels on all known and most unknown > devices. > - Causes some unnecessary delay in startup on most systems. > - May expose bugs in the remapping code. > - Patch exists. > > 2) Have udev-triggered device-specific mappings. > - Provides access to all four channels on the devices for which a > udev-rule is written. > - Requires patching for each individual device. > - Depending on the configuration file content, may expose bugs in the > remapping code. > - No patches exist. I know how to make them. > > 3) Downmix to stereo in alsa. > - Provides access only to downmixed audio. > - Requires patching for each individual device. > - No worries about remapping bugs. > - An untested patch exists for one device. I don't know how to make > these patches. > > The downmixing option doesn't sound very nice with iO4. Owners of that > device probably want to access all channels individually. I don't really > see much benefit in option 3 over option 2. The worry about the > remapping bugs is not very relevant, in my opinion. > > I still vote for option 1, but I accept any of the options. I probably > won't write the patches, though, if we go with option 2 or 3. Since this is among the last of the 2.0 blockers and a regression, I'm going to go with 1) for now. Let's continue the conversation and fix things so the hardware-specific quirking is split off appropriately for 2.1 or 3.0. -- Arun
