2012-05-07 20:06, Arun Raghavan skrev:
On Mon, 2012-05-07 at 13:02 -0700, David Henningsson wrote:
2012-05-07 03:47, Tanu Kaskinen skrev:
On Mon, 2012-05-07 at 09:46 +0530, Arun Raghavan wrote:
On Tue, 2012-05-01 at 20:09 +0300, Tanu Kaskinen wrote:
Changes in v2:
- Call the mapping a generic 4-channel input mapping
instead of a 4-channel mic array mapping. The mapping
will be used also by sound cards that have two stereo
input jacks, so in those cases talking about mic arrays
is wrong.
- Added a comment about using the "hw" device name.
BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=45813
---
src/modules/alsa/alsa-mixer.c | 1 +
src/modules/alsa/mixer/profile-sets/default.conf | 9 +++++++++
2 files changed, 10 insertions(+)
diff --git a/src/modules/alsa/alsa-mixer.c b/src/modules/alsa/alsa-mixer.c
index abb12ee..8b54f75 100644
--- a/src/modules/alsa/alsa-mixer.c
+++ b/src/modules/alsa/alsa-mixer.c
@@ -3888,6 +3888,7 @@ static int mapping_verify(pa_alsa_mapping *m, const
pa_channel_map *bonus) {
{ "analog-surround-61", N_("Analog Surround 6.1") },
{ "analog-surround-70", N_("Analog Surround 7.0") },
{ "analog-surround-71", N_("Analog Surround 7.1") },
+ { "analog-4-channel-input", N_("Analog 4-channel Input") },
Since this is limited to some specific hardware, shouldn't we set up
udev rules instead of always probing?
"All devices supporting 4-channel input" isn't very specific hardware
IMHO,
I agree with Arun on this one. Besides, it is not obvious to me what the
channel mapping should be either, and couldn't that vary between
different 4-channel hardware? Is the aux* just causing all inputs to be
added for whatever the client wants to have...?
and I doubt udev can be used to query the amount of supported
channels.
Hmm...that raises a thought I didn't consider before. Why don't we do
this in alsa-lib? If this varies between devices, we could create e g,
for 4-channel mic hardware A, we set up a alsa-lib ttable to have
"front" record two channels, the two left ones mixing in to the left and
the two right ones mixing into the right. Or in what way do we actually
use all four channels today?
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.
// David
--- /usr/share/alsa/cards/USB-Audio.conf 2012-03-16 14:36:52.000000000 -0700
+++ USB-Audio.conf 2012-05-08 05:53:04.862276125 -0700
@@ -32,6 +32,12 @@
"SB Audigy 2 NX" six_channels
}
+USB-Audio.pcm.front_type {
+ # Playstation eye
+ "USB Camera-B4.04.27.1" four_channel_mixdown
+ # Add kinect, io4 etc here
+}
+
# If a device does not use the first PCM device for digital data, the device
# number for the iec958 device can be changed here.
USB-Audio.pcm.iec958_device {
@@ -109,15 +115,59 @@
".pcm.front:CARD=" $CARD
]
}
+
default {
- # We could use softvol, but the driver might have guessed a
- # wrong name for the real volume control.
- type hw
- card $CARD
- device 0
+ @func refer
+ name {
+ @func concat
+ strings [
+ "cards.USB-Audio.pcm.front_"
+ {
+ @func refer
+ name {
+ @func concat
+ strings [
+ "cards.USB-Audio.pcm.front_type."
+ { @func card_name card $CARD }
+ ]
+ }
+ default default
+ }
+ ":CARD=" $CARD
+ ]
+ }
}
}
+USB-Audio.pcm.front_default {
+ # We could use softvol, but the driver might have guessed a
+ # wrong name for the real volume control.
+ @args [ CARD ]
+ @args.CARD { type string }
+ type hw
+ card $CARD
+ device 0
+}
+
+USB-Audio.pcm.front_four_channel_mixdown {
+ @args [ CARD ]
+ @args.CARD { type string }
+ type route
+ ttable.0.0 0.5
+ ttable.1.0 0.5
+ ttable.2.1 0.5
+ ttable.3.1 0.5
+ slave {
+ pcm {
+ type hw
+ card $CARD
+ device 0
+ }
+ channels 4
+ }
+}
+
+
USB-Audio.pcm.default {
@args [ CARD ]
@args.CARD { type string }
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
