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

[Tanu Kaskinen]

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