2012-05-08 08:17, Tanu Kaskinen skrev: > 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... Once we get there, yes. But I don't see that coming in the foreseeable future, or do you? > > 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. That is very simple: just add one row per device, where the lookup key is what you get out of /proc/asound/cards (the name right after "]: " and before " - "). > > 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. I'd like to try to keep hardware specific stuff on the ALSA side of things as much as possible. It just feels better that way - both because it would potentially help other sound servers and programs using ALSA directly, and because I want to avoid cluttering PulseAudio. > 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. > Thanks for the summary. I'm not going to drive this to doom's day either. I can live with my machine booting up 10 ms slower (or whatever). So if you can ensure/test that a program recording mono or stereo signals will actually give reasonable results back to that application (from 4 aux channels), I'm okay with option 1 as well. // David
