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
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
