[pulseaudio-discuss] [PATCH v2] alsa: Add support for sound cards with 4-channel input.

[David Henningsson]

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