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

[Arun Raghavan]

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