Built-in microphone on Lenovo USB webcam doesn't work when hald is running

Attached is the output of "hald --daemon=no --verbose=yes", which have been trimmed to see only the part that happen after the camera is plugged in.

I completely forgot to mention: the microphone work perfectly well in intrepid and jaunty without shutting down hald.

Reportedly fixed in intrepid/jaunty.

This might be a problem with the automatic ACLs which hal sets, since hal does not otherwise meddle with sound devices. First, please give me the output of "id" for your user. Are you in the "audio" group?

Please give me the output of "getfacl /dev/snd/*" and "sudo fuser -v /dev/snd/*" while hal is running, and after you stopped it. Are the devices inaccessible while hal is running?

As requested:

etienne@curst:~$ id
uid=1000(etienne) gid=1000(etienne) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),115(admin),124(sambashare),125(vboxusers),1000(etienne)
etienne@curst:~$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D1c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

etienne@curst:~$ sudo fuser -v /dev/snd/*
[sudo] password for etienne:
                     USER PID ACCESS COMMAND
/dev/snd/controlC0: etienne 6145 F.... pulseaudio
                     etienne 6360 f.... mixer_applet2

etienne@curst:~$ sudo /etc/init.d/hal stop
 * Stopping Hardware abstraction layer hald [ OK ]
etienne@curst:~$ sudo fuser -v /dev/snd/*
                     USER PID ACCESS COMMAND
/dev/snd/controlC0: etienne 6145 F.... pulseaudio
                     etienne 6360 f.... mixer_applet2
etienne@curst:~$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D1c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

So I am indeed in the audio group, and the ACL appears to be the same, whether hald is running or not.

Sorry about that ...

After unplugging/replugging the camera with hald *not*, the output of getfacl differ:

etienne@curst:~$ getfacl /dev/snd/*
getfacl: Removing leading '/' from absolute path names
# file: dev/snd/controlC0
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/controlC1
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/pcmC0D0c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D0p
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC0D1c
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/pcmC1D0c
# owner: root
# group: audio
user::rw-
group::rw-
other::---

# file: dev/snd/seq
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

# file: dev/snd/timer
# owner: root
# group: audio
user::rw-
user:etienne:rw-
group::rw-
mask::rw-
other::---

We can see that there is no ACI for user etienne after unplugging/replugging the camera when hald is not running. Recording started working just fine, though.

Thank you. It's clearly not an access permission problem then, since you could even access the sound devices without any ACL at all (because you are in the audio group).

Next theory: while hal is running, pulseaudio picks up the sound device in hal and blocks it. That is not quite obvious, though, since your fuser output shows that pulseaudio continues to use the sound card after you stopped hal. However, does it *still* use the soundcard after unplugging/replugging the web cam?

If you don't touch hal and leave it running:
 - Does the webcam microphone work with gnome-sound-recorder? (Apps -> Entertainment -> Audio recorder)
 - Does arecord work after "killall pulseaudio"?

It should be noted that pulseaudio still isn't very good in emulating ALSA, and it was probably much worse in Hardy.

I must be very thick, because I cannot find where to tell gnome-sound-recorder to use the webcam mic for recording instead of the built-in microphone on my laptop. If I go to System > Preferences > Sound, change the Sound Capture device in Audio Conferencing (I presume this is where you go to chose the default GNOME sound capture, right?) for "USB Audio", and then click test, I get an error that says:

    "Failed to construct test pipeline for 'gconfaudiosrc ! audioconvert ! audioresample ! gconfaudiosink profile=chat'"

Then, when opening gnome-sound-recorder, I get an error that says:

    "Your audio capture settings are invalid. Please correct them in the Multimedia settings."

So I cannot test with gnome-sound-recorder :(

Even after I "killall pulseaudio", arecord still give the same error as described in the bug description, "arecord: pcm_read:1347: read error: Input/output error".

Sorry for the delay, I was on holidays last week.

OK, so if it isn't pulseaudio, we have to dig further. Can you please generate a full strace:

  sudo killall hald

Now make sure that sound recording works and capture the trace:

  strace -f -o /tmp/arecord-works.strace -s 1024 -v / /usr/bin/arecord -D hw:1,0 -d 3 -f cd -t wav test.wav

  sudo strace -f -o /tmp/hal.strace -s 1024 -v /usr/sbin/hald --verbose=yes --daemon=no

then wait a bit until the flood settles, check that sound recording fails again, and capture that trace:

  strace -f -o /tmp/arecord-fails.strace -s 1024 -v / /usr/bin/arecord -D hw:1,0 -d 3 -f cd -t wav test.wav

As I said, I have no idea what hal does with the sound device, I hope that the straces can shed some light on this.

Thank you!

Many, many thanks for looking into that - I am completely helpless with this problem.

hald --verbose=yes do seem to have something to say when recording ("Error removing device"), so there is hope.

Keeping notes about my analysis and some facts; please ignore.

arecord does in both cases (hopefully I decoded the ioctls correctly):
open("/dev/snd/controlC1", O_RDONLY) = 3
close(3) = 0
open("/dev/snd/controlC1", O_RDWR) = 3
ioctl(3, USBDEVFS_CONTROL, 0xbfbfc454) = 0
ioctl(3, 0x40045532, 0xbfbfc474) = 0
open("/dev/snd/pcmC1D0c", O_RDWR|O_NONBLOCK) = 4
close(3) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0xbfbfc2d4) = 0
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
ioctl(4, AGPIOC_INFO, 0xbfbfc2d0) = 0
ioctl(4, AGPIOC_RELEASE or APM_IOC_SUSPEND, 0xbfbfc2c8) = 0
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(4, F_SETFL, O_RDWR) = 0
ioctl(4, AGPIOC_ACQUIRE or APM_IOC_STANDBY, 0xbfbfc790) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0 # SNDRV_PCM_IOCTL_HW_REFINE
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbf9e70) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4110, 0xbfbfa400) = 0
ioctl(4, 0xc25c4111, 0xbfbfa400) = 0 # SNDRV_PCM_IOCTL_HW_PARAMS
ioctl(4, 0xc0684113, 0xbfbfa2c0) = 0
ioctl(4, 0x4140, 0) = 0 # SNDRV_PCM_IOCTL_PREPARE

arecord if it works:
ioctl(4, 0x800c4151, 0xbfbfa6a0) = 0 # SNDRV_PCM_IOCTL_READI_FRAMES

arecord if it fails:
[... ioctl(4, 0xc0684113, 0xbf9db8a0) = 0 ... ]
ioctl(4, 0x800c4151, 0xbf9dbc80) = -1 EIO (Input/output error)

hal does not access /dev:
egrep '(open|ioctl).*dev/snd' hal.strace

... but proc:
open("/proc/asound/cards", O_RDONLY|O_LARGEFILE) = 13
open("/proc/asound/card1/pcm0p/info", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/proc/asound/card1/pcm0c/info", O_RDONLY|O_LARGEFILE) = 16
open("/proc/asound/card0/pcm0p/info", O_RDONLY|O_LARGEFILE) = 16

this is from hald/linux/device.c, sound_add(), called if a new device is discovered (also at hald start), and fd gets closed. This is just an informational operation, I don't believe that this causes the issue.

arecord on 8.04.1 with hald running works for me, both with and without pulseaudio. mixer_applet2 is the only thing holding open /dev/snd/controlC0.

So I stared at the straces and source code, and decoded ioctls for two hours, without being able to pinpoint the problem. However, I learned where the problem can *not* be, and have some more tests for you.

 * arecord opens and configures (with ioctls) the sound device just fine; however, when it actually tries to read data from it (SNDRV_PCM_IOCTL_READI_FRAMES, through aplay/aplay.c, pcm_read() -> snd_pcm_readi()) it fails. This rules out any permission problem.

 * The strace does not provide sufficient information to show whether the sound device was configured with the same parameters in both cases (SNDRV_PCM_IOCTL_HW_PARAMS only gets a pointer passed which is not decoded). However, it is pretty unlikely that this is the reason.

 * hald itself and its callouts do not *ever* open /dev/snd/*. It opens /proc/asound/cards and .../info to get device properties when a new sound device is found, but do not keep open any FDs. I strongly doubt that hald itself is the cause for this. To verify this, please do these two tests:

   - sudo killall hald
   - tail -f /proc/asound/card*/pcm*/info /proc/asound/cards # this will keep those files permanently open
   - arecord ...

   I expect that this will still work. If not, then opening those files (as hal does temporarily) is the cause, but it is unlikely.

  - sudo /etc/init.d/hal start
  - log out of GNOME session, ctrl-alt-f1, log into terminal
  - killall -15 -1 # this will kill *all* your running applications
  - sudo /etc/init.d/gdm stop
  - arecord ...

  If arecord still fails here, please stop hal and test arecord again. This will tell us whether it is hald itself, or something in the desktop that listens to hal to pick up the new sound device, and grab it.

The latter is my best suspicion so far. It might be the mixer applet, however, that does not actually talk to hal. It might pick it up by something in between. Does arecord start working again if you keep hal running, have a running GNOME session, but "killall mixer_applet2"?

Thanks!

Also, just for kicks, does arecord work in memory mapped mode, thus with -M?

I also had a quick look at the usbaudio driver [1], but it doesn't actually handle reading from the device. Beyond that I'm a kernel n00b I'm afraid. So ATM I do not have a clue *why* read()ing from the device returns EIO.

[1] http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=blob;f=sound/usb/usbaudio.c;h=967b823eace083bbad39e4fae5378243b61dbbe7;hb=HEAD

Could you try installing the intrepid kernel and see whether that makes any difference?

> The latter is my best suspicion so far. It might be the mixer applet,
> however, that does not actually talk to hal. It might pick it up by
> something in between. Does arecord start working again if you keep hal
> running, have a running GNOME session, but "killall mixer_applet2"?

No, killing the mixer applet did not fixed it (ie, hald running, arecord
error).

Getting out of GNOME to test now.

Martin Pitt wrote:
> Could you try installing the intrepid kernel and see whether that makes
> any difference?

Good idea; however, I will not be abelt to do that right away. Will do
this weekend.

Martin Pitt wrote:
> Also, just for kicks, does arecord work in memory mapped mode, thus with
> -M?

No, it does not either.

Martin Pitt wrote:
> Also, just for kicks, does arecord work in memory mapped mode, thus with
> -M?

Hold on! It does not, but it do fail with an error. It just sit there,
not exiting despite -d 3 and spin. If I strace the running process, I get:

    etienne@curst:~$ strace -p 7019
    Process 7019 attached - interrupt to quit
    restart_syscall(<... resuming interrupted call ...>

If I kill arecord with Ctrl-C, the test.wav is empty.

Attaching the output of strace -f -o /tmp/arecord-memmap.strace -s 1024
-v arecord -M -D hw:1,0 -d 3 -f cd -t wav test.wav

Sorry, could not attach the file, as strace do not write if killed with Ctrl-C. Here is a quick cut-and-paste of the last few line of strace -f -s 1024 -v arecord -M -D hw:1,0 -d 3 -f cd -t wav test.wav :

write(2, "Recording WAVE \'test.wav\' : ", 28Recording WAVE 'test.wav' : ) = 28
write(2, "Signed 16 bit Little Endian, ", 29Signed 16 bit Little Endian, ) = 29
write(2, "Rate 44100 Hz, ", 15Rate 44100 Hz, ) = 15
write(2, "Stereo", 6Stereo) = 6
write(2, "\n", 1
) = 1
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9fa00) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4110, 0xbff9ffc0) = 0
ioctl(4, 0xc25c4111, 0xbff9ffc0) = 0
ioctl(4, 0xc0684113, 0xbff9fe50) = 0
ioctl(4, 0x80104132, 0xbff9fd8c) = 0
ioctl(4, 0x80104132, 0xbff9fd8c) = 0
mmap2(NULL, 90112, PROT_READ|PROT_WRITE, MAP_SHARED, 4, 0) = 0xb7c33000
ioctl(4, 0x4140, 0) = 0
unlink("test.wav") = 0
open("test.wav", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 3
write(3, "RIFFT\23\10\0WAVE", 12) = 12
write(3, "fmt \20\0\0\0", 8) = 8
write(3, "\1\0\2\0D\254\0\0\20\261\2\0\4\0\20\0", 16) = 16
write(3, "data0\23\10\0", 8) = 8
ioctl(4, 0x4142, 0xbffa0240) = 0
poll(

I will be doing the test out of GNOME tonight, as my laptop battery is going to die anytime now.

Martin Pitt wrote:
> - sudo /etc/init.d/hal start
> - log out of GNOME session, ctrl-alt-f1, log into terminal
> - killall -15 -1 # this will kill *all* your running applications
> - sudo /etc/init.d/gdm stop
> - arecord ...

It fail with the same error. Then I unplugged and replugged the camera,
and it still failed. I stopped hald, tried arecord and it failed again.
 Then I unplugged and replugged the camera, and then arecord worked fine.

Bah, that's so utterly confusing now. Does arecord work or fail if you stop hal and run "tail -f /proc/asound/card*/pcm*/info /proc/asound/cards" in parallel? That's the *only* thing that hal does wrt. sound devices.

If you say that it is fixed in intrepid, trying the intrepid kernel would really be worthwhile, too. If that helps, maybe we can supply a backported usb sound driver.

Indeed, on a fully up-to-date hardy system, after installing linux-image-generic from intrepid (along with linux-firmware and linux-image-2.6.27-7-generic) and rebooting, arecord works just fine and capute from the webcam mic no problem. All thing being equal, this point to a problem with the kernel.

And it must be something rather specific 2.6.24. For kicks, I installed gutsy (kernel 2.6.22-14), and recording using arecord worked out-of-the-box, no killing of hald required.

I'm not absolutely positive what's in hardy's lbm and lum, but can you install linux-backports-modules-hardy-generic, reboot and see if it resolves the problem under hardy kernel?

I still experience the problem with linux-backports-modules-hardy-generic installed. Sorry!

It is worth noting that I have linux-ubuntu-modules for the running kernel installed, and that does not help.

Hey guys, i want to leave the list.

Whats the process ?

Thanks

On Thu, Jan 29, 2009 at 11:05 AM, Etienne Goyer <<email address hidden>
> wrote:

> It is worth noting that I have linux-ubuntu-modules for the running
> kernel installed, and that does not help.
>
> --
> Built-in microphone on Lenovo USB webcam doesn't work when hald is running
> https://bugs.launchpad.net/bugs/310760
> You received this bug notification because you are subscribed to Hardy.
>

--
___

Davi Thiesse

Manually compiling the latest alsa-driver-1.0.19 (./configure; make; sudo make install) fixes the problem, so it is indeed a problem with the version of ALSA we ship in hardy.

Thanks, Etienne. I agree that providing a newer alsa in l-b-m sounds like a good solution.

I did a bit of further testing. Manually compiling and installing upstream ALSA 1.0.16 (from ftp://ftp.alsa-project.org/pub/driver/alsa-driver-1.0.19.tar.bz2) without having lum installed, it actually work. So the problem could be somewhere in our delta from upstream. Either that, or my test are not good. I will be investigating a bit more and report back shortly.

Yep, confirmed.

On -23-generic, without lum installed, it work if I install upstream alsa-driver-1.0.16 with ./configure, make, sudo make install, the mic on the webcam work just fine and can record. I confirmed that I was using the module I just compiled by looking at /proc/asound/version.

Then, if I install lum-2.6.24-23-generic and reboot, the mic would not work anymore (I would the "input/output error" discussed above). Again, I confirmed I was using the module from lum by looking at /proc/asound/version.

Just for anyone else tracking this issue, I had Etienne test the following:

1) sudo apt-get install linux-ubuntu-modules-2.6.24-23-generic
2) create a file /etc/hal/fdi/policy/ignore-17ef7802.fdi to look like:

<deviceinfo version="0.2">
  <device>
    <match key="usb_device.vendor_id" int="6127">
      <match key="usb_device.product_id" int="18434">
        <merge key="info.ignore" type="bool">true</merge>
      </match>
    </match>
  </device>
</deviceinfo>

3) reboot and test

linux-ubuntu-modules-2.6.24-23-generic provides alsa-driver-1.0.16 and the .fdi file prevents hal from probing the device. Etienne provided the following feedback:

"It works perfectly well. At least, in the sense that we can get both the mic and the webcam working. Of course, the webcam do not work in application that relies on HAL (ie, Cheese), but in those that use ALSA/V4L directly (such as VLC), it work just fine indeed."

An earlier message claims that this is fixed in Interpid/Jaunty. However I have a Lenovo USB Webcam, and I'm experiencing the exact same symptoms in Jaunty.
1) Plugin in Webcam.
2) Microphone capture doesn't work
3) Stop HAL and replugin webcam
3) Microphone capture works

So is this bug really fixed?

I should also mention that Leann's "fix" to have HAL ignore the webcam also works in Jaunty.

Karol,

I just tried on my machine running Jaunty, and the webcam microphone does work for me no problem with both Sound Recorder and arecord. Was you installation fresh, or an upgrade from 8.04?

Leann,

I did try your solution above, and it does work to a certain extent. With the HAL policy file you propose, the microphone work just fine: you can record sound using arecord, Sound Recorder, etc. However, once the camera have been used once, the microphone stop working.

Step to reproduce:

1. Create the /etc/hal/fdi/policy/ignore-17ef7802.fdi as Leann explained above. Restart hald or reboot.

2. With the webcam plugged in, try recording sound using arecord, such as:

    arecord -Dhw:1,0 -d 3 -f cd -t wav test.wav

You may also use Sound recorder. You can use the webcam microphone at will, it works continuously.

3. Use an application that access the camera, such as VLC or MPlayer. For example:

    vlc v4l:// :v4l-vdev="/dev/video0"

or:

    mplayer tv:// -tv driver=v4l

Notice that, in both example above, we are not even have to be using the webcam mic. If we do specify the webcam microphone (ie, using argument :v4l-adev="/dev/dsp1" to vlc), sound is captured just fine from the webcam microphone.

4. Try arecord again, and notice you get the IO error:

ubuntu@ubuntu-laptop:~$ arecord -Dhw:1,0 -d 3 -f cd -t wav test.wav
Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
arecord: pcm_read:1347: read error: Input/output error

5. If you unplug/replug the camera, state is reset so that the microphone just fine until the camera is accessed, at which point you get the IO error (just like above).

So, it seems like the webcam microphone work just fine until the camera is accessed, after which the microphone stop working. Maybe the camera driver (gspca) leave the device in a state broken in such a way that the microphone is not usable? It may also explain why the microphone would not work when hald is running; perhaps hald is opening/querying the camera in a way that break the microphone function of the device. It would also explain why unplugging/replugging the webcam "fix" the microphone (at least, until the camera is accessed).

I am taking my comment from yesterday, that it work in Jaunty, back. It show exactly as the same symptom as when we use the HAL policy Leann suggested on hardy, that is: the microphone on the webcam works no problem until the camera is used once, then it stops working and arecord report IO an error.

So, I guess the title of the bug should be changed, and the status of the bug in "linux (Ubuntu)" should be set to "triaged".

Just to be sure, I also tested on hardy amd64, and I got the same result as on i386, so it appear it is not architecture-related.

Just tried with the latest mainline, linux-image-2.6.30-020630rc8-generic, and it have the same problem: microphone works, and stop working after we try using the camera with VLC or MPlayer.

Also, the camera (the video) do not work on that mainline kernel, but that is beside the point of this bug and the topic for another report. :)

will need hardware to do detailed debug, now arranging to purchase a unit here in Taipei for testing

AceLan, it is probably easier if you have your own cam, but if bad come to worse, just let me know and I will get you access to a machine that have one plugged in.

Thanks a lot for looking into that!

Etienne,

You have mentioned that
>On -23-generic, without lum installed, it work if I install upstream alsa-driver-1.0.16
I would like to know have you check the record function after using the camera.

I always test using arecord, such as:

    arecord -D hw:1,0 -d 3 -f cd -t wav test.wav

Thanks, AceLan!

Etienne, what's the kernel version you are using, I'll give you a kernel module for the test.

AceLan,

I am using 2.6.28-13-generic, the latest on jaunty, on my personal laptop. But i fyou want me to test one for hardy, I canuse whichever you want.

Thanks a lot!

Etienne,
  Would you please help test a patched kernel & modules, available at

  http://people.ubuntu.com/~lexical/archive/lp310760/

  This is not a perfect solution and it would be helpful if other webcams with the chip of Vimicro VC0323 can also be tested and confirmed to work well. Please refer to:

  http://mxhaard.free.fr/spca5xx.html

Etienne, if Keng-Yu's patch can fix this issue, the problem is very clear now. The i2c commands used to turn on/off the LED on the webcam are wrong for this model. The turn on function is not working, so the LED is always dark even if you're using the camera, and the turn off command will influence the MIC function that result to this problem. The short term solution is to avoid to send out the turn off LED command if the sensor model is MI1310_SOC. For the long term solution, we'll need the H/W spec. and I don't know if we have the chance to obtain that.

Keng-Yü,

It works! I have just tested in hardy, and both the camera and microphone works at the same, without using the HAL policy suggested by Leann. Basically, with the kernel you built, the camera and microphone works in any application (arecord, VLC, etc), and keep on working across unplug/replug.

I have not tested on Jaunty, as we are moving today and we are in a bit of a crunch, but I will try to do that and confirm Monday.

AceLan: Now that you are saying that, it is true that I never saw the LED lit up. As far as I am concerned, I would rather have the microphone working even if the LED doesn't. It would be a start!

Thanks profusely again for all the time you put into that one. It is very appreciated.

I tested in Jaunty. The problem with the microphone is resolved indeed; the mike continue to work after having used the camera. However, the camera in general is not working so well; video is extremely choppy in Cheese, and it hard freeze the machine when trying to access the camera using the V4L interface. But that is another bug; at least, the problem with the microphone is resolved.

Etienne, I have built another Hardy kernel package that might work fine with LED. Since I'm not able to test it, don't have webcam with me, and might have chance to test it untill next Wednesday. If you could test it these days, I can send SRU this week. Thanks.

http://people.canonical.com/~acelan/bugs/lp310760/

AceLan,

Sorry for taking so long to get back to you. I have tested the latest kernel found in the location provided above, and everything works (camera, microphone and LED).

Thanks a whole bunch!

@AceLan, do you know how the current status is for upstream. Especially could you check, whether this is still required for the Karmic kernel? Thanks.

Accepted linux-ubuntu-modules-2.6.24 into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Tested 2.6.24.60 from hardy-proposed, and it work as expected in any application I use (VLC, Cheese, arecord, etc). Camera, microphone and LED are all functional. Thanks a lot!

@Stefan, the patch seems not be included in the mainstream kernel now. I just wrote to the DVB/V4L tree maintainer, if the 2.6.31 will not contain this patch for sure, I'll deliver the Karmic SRU.

Accepted linux into hardy-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

@Stefan, the patch is accepted and merged into the mainstream.

commit 4041f6b3b4deaa3c67fbe71b67c3c18ac9ce0207
Author: AceLan Kao <email address hidden>
Date: Mon Jul 27 05:43:55 2009 -0300

    V4L/DVB (12352): gspca - vc032x: Fix mi1310_soc preview and LED

    The patches
        gspca - vc032x: Add resolution 1280x1024 for sensor mi1310_soc.
        gspca - vc032x: Webcam 041e:405b added and mi1310_soc updated.
    will make the preview function not work, so I disable the 1280x1024 resolution
    and revert back to the origin mi1310_soc settings.
    And, using USB snoop tool on Windows to get the correct i2c commands to
    turn on/off the LED flash.

    Signed-off-by: AceLan Kao <email address hidden>
    Signed-off-by: Jean-Francois Moine <email address hidden>
    Signed-off-by: Mauro Carvalho Chehab <email address hidden>

Hi. Works perfectly here.
Thank you very much !

This bug was fixed in the package linux-ubuntu-modules-2.6.24 - 2.6.24-24.41

---------------
linux-ubuntu-modules-2.6.24 (2.6.24-24.41) hardy-proposed; urgency=low

  [Stefan Bader]

  * SAUCE: igb-next: Fix up the makefile to actually do a build
    - LP: #352440

linux-ubuntu-modules-2.6.24 (2.6.24-24.40) hardy-proposed; urgency=low

  [AceLan Kao]

  * SAUCE: Fix the MIC of the Lenovo webcam problem
    - LP: #310760

  [Stefan Bader]

  * Merge WEXT scan capabilities to iwlwifi
    - LP: #200950
  * SAUCE: Add support in e1000e for a couple of ICH10 PCI IDs
    - LP: #322737
  * Add standalone Intel igb driver as igb-next to support 82576 cards
    - LP: #352440

 -- Stefan Bader <email address hidden> Mon, 14 Sep 2009 21:05:16 +0200

This bug was fixed in the package linux - 2.6.31-12.40

---------------
linux (2.6.31-12.40) karmic; urgency=low

  [ Tim Gardner ]

  * SAUCE: Created MODULE_EXPORT/MODULE_IMPORT macros
    - LP: #430694
  * SAUCE: Use MODULE_IMPORT macro to tie intel_agp to i915
    - LP: #430694

  [ Upstream Kernel Changes ]

  * V4L/DVB (12352): gspca - vc032x: Fix mi1310_soc preview and LED
    - LP: #310760

 -- Tim Gardner <email address hidden> Tue, 06 Oct 2009 20:25:36 -0600