Bug 45813 - [regression] 4-mic arrays broken with iec958-surround-40 profile removal
[regression] 4-mic arrays broken with iec958-surround-40 profile removal
Status: RESOLVED FIXED
Product: PulseAudio
Classification: Unclassified
Component: alsa
unspecified
Other All
: medium normal
Assigned To: Tanu Kaskinen
pulseaudio-bugs
:
: 49056 (view as bug list)
Depends on:
Blocks: 45812
  Show dependency treegraph
 
Reported: 2012-02-08 22:55 UTC by Arun Raghavan
Modified: 2013-02-13 04:08 UTC (History)
4 users (show)

See Also:


Attachments
alsa-info.sh output with Playstation Eye (283.92 KB, text/plain)
2012-02-09 16:17 UTC, Yani Ioannou
Details
Fix candidate: add a new input mapping with "hw" device (1.76 KB, patch)
2012-04-21 05:50 UTC, Tanu Kaskinen
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Arun Raghavan 2012-02-08 22:55:47 UTC
From comment 18 on bug #39664:

"""
I'd like to note that the removal of the iec958-surround-40 profile affected
other mics too, notably the Playstation 3 Eye which no longer works with
pulseaudio in recent Ubuntu distributions and which is affecting a lot of
people, including me.

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/889624

I've seen similar reports for Arch Linux and Fedora.

This should not be a special-case profile, it should be in default.conf. There
are several 4-channel microphone arrays on the market usually packaged in
webcams. Just googling I find the following 4-channel mic array webcams at
bestbuy you can walk in and buy:

http://www.bestbuy.com/site/Creative+-+Live!+Cam+inPerson+HD+Webcam/3613018.p?id=1218463912602&skuId=3613018
http://www.bestbuy.com/site/FreeTalk+-+Skype+Conference+Webcam/2477095.p?id=1218329600068&skuId=2477095
"""
Comment 1 Arun Raghavan 2012-02-08 22:58:12 UTC
Could you provide alsa-info output. Specifically, I'm interested in the mixers of the card with the mic array.
Comment 2 Yani Ioannou 2012-02-09 16:09:55 UTC
Hi Arun,

Sorry - the alsa mixer controls don't work with the PS3 eye, that's a whole other problem I'm trying to solve (see my discussion here: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/886449) and looks like it's either a regression in the gscpa driver or a min-max volume control quirk that needs to be added to snd-usb-audio. I suspect the latter because even if I blacklist gspca and load snd-usb-audio alone it doesn't work, but there are claims it worked before 2.6.33 (see http://patchwork.linuxtv.org/patch/4533/).

Anyway it does work with pulseaudio somehow once the appropriate 4-channel input is created, and the module is loaded (which I'm forcing in default.pa because for some reason it isn't loaded by the autoloader). I've found the same is necessary for the Xbox kinect (even just using the latest pulseaudio git which is supposed to work with it!).
Comment 3 Yani Ioannou 2012-02-09 16:17:46 UTC
Created attachment 56840 [details]
alsa-info.sh output with Playstation Eye

Here is the alsa-info output for what it's worth, but keep in mind in alsa mixer controls do not work correctly:

$ amixer -c 1 controls
numid=1,iface=MIXER,name='Mic Capture Volume'
$ amixer -c 1 contents
numid=1,iface=MIXER,name='Mic Capture Volume'
  ; type=INTEGER,access=rw---R--,values=4,min=0,max=1,step=0
amixer: Control hw:1 element read error: Invalid argument

When running the latest alsa-drivers from git with debug=verbose:

[22837.457719] usb 2-4: new high speed USB device number 38 using ehci_hcd
[22837.593948] ALSA stream.c:452 38:2:1: add audio endpoint 0x84
[22837.597024] ALSA clock.c:242 current rate 1105 is different from the runtime rate 16000
[22837.597159] ALSA mixer.c:866 3:1: cannot get min/max values for control 2 (id 3)
[22837.597165] ALSA mixer.c:1212 [3] FU [Mic Capture Volume] ch = 4, val = 0/1/1
[22837.882197] usb 2-4: usbfs: USBDEVFS_CONTROL failed cmd mtp-probe rqt 128 rq 6 len 1024 ret -71
[22891.954797] ALSA mixer.c:317 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x301, type = 4
[22891.954804] ALSA mixer.c:866 3:1: cannot get min/max values for control 2 (id 3)
[22891.957295] ALSA mixer.c:317 cannot get ctl value: req = 0x81, wValue = 0x201, wIndex = 0x301, type = 4
[22891.957300] ALSA mixer.c:412 cannot get current value for control 2 ch 1: err = -22
Comment 4 Tanu Kaskinen 2012-04-21 02:07:47 UTC
Have I understood this bug correctly:

* Previously, 4-mic arrays worked previously by luck (by using the "iec958" alsa device, even though these arrays don't have anything to do with iec958).
* Now they don't work anymore, because the nonsense mapping (iec958-surround-40) was removed.

Does someone already have a clear opinion about how to make the mic arrays work again?

My impression is that alsa doesn't define any 4-channel input devices (can somebody confirm?). This means that fixing this properly in Pulseaudio alone is not possible. I guess we could try to use the "hw" device for now, even though that will also only work with luck. That would still be better than using the "iec958" device.
Comment 5 Tanu Kaskinen 2012-04-21 05:29:49 UTC
I sent a message about this to alsa-devel: http://thread.gmane.org/gmane.linux.alsa.devel/96968

While waiting for comments, I'll make a fix candidate by using the "hw" device name.
Comment 6 Tanu Kaskinen 2012-04-21 05:50:01 UTC
Created attachment 60414 [details] [review]
Fix candidate: add a new input mapping with "hw" device

Here's a fix candidate. Yani, could you test this?
Comment 7 Phillip Berndt 2012-04-22 11:44:53 UTC
*** Bug 49056 has been marked as a duplicate of this bug. ***
Comment 8 Phillip Berndt 2012-04-22 11:50:26 UTC
The proposed change to src/modules/alsa/mixer/profile-sets/default.conf resolved my problems with 4-channel recording. pactl list now offers me the new profile
 input:analog-mic-array-4: analog-mic-array-4 Input (sinks: 0, sources: 1, priority. 1)
for my Alesis iO4 USB sound card, and recording through PA works as expected.
Comment 9 David Henningsson 2012-04-22 19:22:07 UTC
Arun, Tanu,

Whenever you add something to default.conf, there is also something else to be weighted in: The startup/probe time. 
That's the reason I didn't put all the extra hdmi profiles into default.conf but kept them in extra-hdmi.conf. 

For 99,9% of our users, approximately, probing this one is going to fail after opening the device, which is costing us...well, a quick look at my computer here...it's about 2 ms for the internal card and about 10 ms for my USB headset. Maybe not that much but... 

I don't know how common these 4-channel mics are out in the real world - I have never seen or used one myself - but if they still are as uncommon as I believe they are, it could be worth not bloating default.conf with yet another profile and instead put these in a separate .conf file (quirked with udev rules to match).
Comment 10 Tanu Kaskinen 2012-04-22 21:08:06 UTC
10 ms sounds actually quite much... Assuming that it's for only one profile probe, it will be multiplied when trying different mapping combinations.

I would prefer caching the probing results instead of building a database of all 4-channel mics in the world. To me it seems that such hardware can become quite common, if it really achieves much better sound quality.

If others agree that we want caching, then we need to decide what to do for 2.0, and will someone commit to working on this for 3.0...
Comment 11 Tanu Kaskinen 2012-05-01 10:27:28 UTC
I sent an updated patch to the mailing list: http://thread.gmane.org/gmane.comp.audio.pulseaudio.general/13140

The discussion on alsa-devel stopped before getting an agreement on the new device name. I haven't pushed that more, because I think "hw" will actually work on almost all hardware. The device name issue can be figured out when we actually find hardware that doesn't work with "hw".

We need to get a decision about having the new mapping in default.conf. I'm for having it there. David, are you against it?
Comment 12 Arun Raghavan 2012-05-11 06:23:40 UTC
Committed Tanu's patch for this.
Comment 13 Dave M G 2013-02-13 04:08:24 UTC
Has the fix for this bug been included in the latest Alsa release yet?

I am trying to use an Alesis iO4 with Ubuntu 12.10. I have Alsa version 1.0.25, and I am experiencing the same problem as reported in Bug 49056 (which links back to this as a duplicate).

I notice this bug is marked as resolved in May 2012, but in February 2013 I am still unable to use my Alesis.

Can someone please clarify for me (a non-expert in ALSA), the status of the fix for this, and if there is anything I need to do to ensure my Alesis iO4 works?

(I also see there is a patch attached to this bug report, but I don't know how to implement it and I suspect it's not intended for newbies like myself who are using the ALSA from the Ubuntu repositories.)

Thank you for any information.