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 """
Could you provide alsa-info output. Specifically, I'm interested in the mixers of the card with the mic array.
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!).
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
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.
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.
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?
*** Bug 49056 has been marked as a duplicate of this bug. ***
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.
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).
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...
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?
Committed Tanu's patch for this.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.