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