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
