On Tue, 2012-05-08 at 18:53 -0700, David Henningsson wrote: > 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? iO4 users probably want full four-channel access. But I don't want to block 2.0 for this - let's provide at least reduced functionality. > > 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. That makes a lot of sense. Currently audio hardware adaptation work has to be done both in ALSA and PulseAudio. I can't see any good reason for why it should be so. The only problem is that I'll need to become an alsa-lib developer now... but that's probably a good thing. Do you think that we should aim to get rid of the current custom profile-set configuration files too? If we decide that there should be no hardware-specific stuff in PulseAudio, I think that would be logical. > > 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. I can "test/ensure" that. I tried first with the "test" approach, which showed that you indeed get silence from an all-aux device with non-aux capture stream channel maps: D: [pulseaudio] resampler.c: Channel matrix: D: [pulseaudio] resampler.c: I00 I01 I02 I03 D: [pulseaudio] resampler.c: +------------------------ D: [pulseaudio] resampler.c: O00 | 0.000 0.000 0.000 0.000 D: [pulseaudio] resampler.c: O01 | 0.000 0.000 0.000 0.000 I: [pulseaudio] remap.c: Using generic matrix remapping Next would then be the "ensure" approach... -- Tanu
