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

[David Henningsson]

2012-05-08 20:42, Tanu Kaskinen skrev:
> 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.
>

Never answered this one: I'd say, yes, if we can remove the current 
custom profile-set configuration files in exchange for doing the same 
thing in alsa-lib, that would be a good thing in general. But I don't 
know if it's feasible everywhere, and I don't see it as a high priority 
currently. But before adding new custom profiles, we should first 
consider tweaking alsa-lib instead.

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic