Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Wed, Jul 14, 2010 at 6:31 AM, Jean-Francois Moine moin...@free.fr wrote: I have just done the pull request. The patch should be applied in the kernel 2.6.36 and it contains: Jean-Francois, Long Thank you, please be patient, You did most of the work, but I appreciate your generosity so much. Linux wouldn't work without kind people like you who help people like me who are not as experienced! I've been trying so hard for ~3 years to contribute and this is my biggest contribution considering thousands of people will be using this driver fix soon when its merged with the latest Kernel! It's very generous of you to share the publicity for this webcam patch with me! I have a new-found respect for the work you're doing and want to help in any way I can. I've learned sonixj.c very well now after reading the code for a week and would love to help with improving it and optimize it to get better performance. Please let me know if I can ever be of assistance for testing or otherwise! If you ever need to pass this driver on to someone else (like Michel Xhaard did with you), please consider me! I would love to help improve upon this driver and help maintain it! I'm a college student and not as experienced as you, but you've shown me a great deal and how to debug projects like this and for that I am greatful! I sincerely appreciate and thank you for you help and friendliness! It has been a pleasure debugging with you. Please call on me when you need to test this driver again against future changes! I'm still curious about the following if you feel like answering: Is there anyway to give the camera button an action when the camera is not on? In windows, pressing the button would launch a predefined application (Windows Live Messenger), but I would like to write in the ability to open either a buddy list or Cheese or something relevant from the button if possible. Thank you very much, -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Mon, 12 Jul 2010 19:01:51 -0400 Kyle Baker kyleaba...@gmail.com wrote: These do fix the audio problem, but they may not be good for other Sensor OV7660 devices. I am not sure how to identify only my model here, but that may be ideal for a better patch. I wonder if this patch would also be needed for the VX-3000 model? Hi Kyle, Thanks for the patch, but it is more complex. In fact, only the bridge sn9c105 may do audio stream and the sensor ov7660 is used with other bridges (the VX3000 is the same as the VX1000 and contains the sn9c105 and the ov7660). In the new gspca test version (2.9.52), I modified the driver for it checks the audio device. If present, the bandwidth is reduced and for the sn9c105, the bit 0x04 of the GPIO register is always set (I hope that the audio connection is done in the same way by all manufacturer!). May you check it? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Tue, Jul 13, 2010 at 3:13 PM, Jean-Francois Moine moin...@free.fr wrote: In the new gspca test version (2.9.52), I modified the driver for it checks the audio device. If present, the bandwidth is reduced and for the sn9c105, the bit 0x04 of the GPIO register is always set (I hope that the audio connection is done in the same way by all manufacturer!). I can verify that GSPCA 2.9.52 does indeed work with VX-1000. How long does it take typically for these changes to work their way into the Kernel? I'd love to see this included in the Kernel by the time Ubuntu 10.10 is released so I can stop tweaking webcam settings. On a different note, I've noticed that there is a bug either with Cheese or with the camera drivers after recording video. The problem is that, after I record a video in Cheese, the recording stops and the video is saved, but the record button is now disabled until I reopen the application. I'm curious why this would happen, but I think that more people would notice this bug if it were a Cheese bug. I'm wondering if there is something that isn't transferred or set correctly after ending the video/audio data transfers. Cheese is working with V4L2 well in all other aspects. I have been testing with Ubuntu 10.10, so I will install your latest drivers in Ubuntu 10.04 (stable) to see what happens. I know that on my laptop in Ubuntu 10.04 (where video worked, but audio didn't), the video would save and the button is re-enabled correctly. I'll test this against your latest release to see what happens since Ubuntu 10.04 installs GSPCA 2.7.0 by default. I will let you know of the results soon. And one more question. Is there anyway to give the camera button an action when the camera is not on? In windows, pressing the button would launch a predefined application (Windows Live Messenger), but I would like to write in the ability to open either a buddy list or Cheese or something relevant from the button if possible. Thanks. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Tue, Jul 13, 2010 at 7:59 PM, Kyle Baker kyleaba...@gmail.com wrote: On a different note, I've noticed that there is a bug either with Cheese or with the camera drivers after recording video. The problem is that, after I record a video in Cheese, the recording stops and the video is saved, but the record button is now disabled until I reopen the application. I've tested this on my Ubuntu 10.04 32-bit laptop with both GSPCA 2.7.0 and GSPCA 2.9.52. The results match, Cheese 2.30.1 works as intended. However, I'm using the same version of Cheese on my Ubuntu 10.10 64-bit computer and results are different. I'll keep an eye on this issue and if it doesn't clear up by time of Ubuntu 10.10 release then I'll look back into it. FYI, there is a warning message in the make process that I wanted to bring your attention to. Its not causing problems, but maybe it can be removed? .../gspca-2.9.52/build/jpeg.h:152: warning: ‘jpeg_set_qual’ defined but not used Cheers. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sun, 11 Jul 2010 17:18:53 -0400 Kyle Baker kyleaba...@gmail.com wrote: Is the previous maintainer, Michel Xhaard, still working on this driver at all? I wonder if he might be able to help identify the problem or narrow it down. Which function is called when I open Cheese or other video applications? Initializing the webcam appears to be correct, however, sd_start() or the one that starts the video capture appears to be toggling or changing some setting. If I knew of a way, I would insert more debug messages to help pinpoint the place where the microphone breaks along with some boolean to show that its working or not. Hi, Michel Xhaard gave me all the gspca stuff and stopped working on it two years ago. He did not even tell me which of his webcams were working with gspca v2... The video capture is started in sd_start(). Checking all sequences again, I found that the GPIO is also set near line 1752. May you comment it and test? msleep(100); // reg_w1(gspca_dev, 0x02, 0x62); break; Otherwise, here is a way to know the exact bad USB exchange. First, in sonixj.c, add a long delay in the register write functions just before the debug messages: - line 1350 msleep(1000); // add this PDEBUG(D_USBO, reg_w1 [%04x] = %02x, value, data); - line 1365 msleep(1000); // add this PDEBUG(D_USBO, reg_w [%04x] = %02x %02x .., value, buffer[0], buffer[1]); After installation, connect the webcam and set the gspca debug level to 0xcf: echo 0xcf /sys/module/gspca_main/parameters/debug Check if the webcam microphone is working, and look at the kernel messages by: tail -f /var/log/messages Then, start the video capture. You should see each USB exchange in the 'tail' window. When the audio stops, the bad exchange is the one just printed... If the audio stopped before any exchange, this could mean that something went wrong when setting the alternate setting or on URB creation. BTW, your webcam is connected to a USB 1.1 port with the driver ohci_hcd. Have you some USB 2.0 port that you could use? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Mon, Jul 12, 2010 at 4:18 AM, Jean-Francois Moine moin...@free.fr wrote: The video capture is started in sd_start(). Checking all sequences again, I found that the GPIO is also set near line 1752. May you comment it and test? I tested this and it did not show any different results. Otherwise, here is a way to know the exact bad USB exchange. [snip] After installation, connect the webcam and set the gspca debug level to 0xcf: echo 0xcf /sys/module/gspca_main/parameters/debug I'm unable to set the debug level due to the following error: bash: /sys/module/gspca_main/parameters/debug: Permission denied I even tried as sudo. The debug file contents are 3 with no quotes at runtime. I worked around this by changing PDEBUG(D_USBO, ... to PDEBUG(D_PROBE, ... and I think I've found the exact point that the microphone is cut off. Check if the webcam microphone is working, and look at the kernel messages by: tail -f /var/log/messages Microphone is working at this point still with no unusual messages. Then, start the video capture. You should see each USB exchange in the 'tail' window. When the audio stops, the bad exchange is the one just printed... If the audio stopped before any exchange, this could mean that something went wrong when setting the alternate setting or on URB creation. This didn't appear to be the case. I tested it 5-6 times to verify that I saw the correct line. Here is the exchange from plugging in my webcam until I quit Cheese. The point that the mic quits is at [ 224.692515] sonixj-2.9.51: reg_w1 [0002] = 62 as far as I can tell. I hope this sheds some light on the issue. Repeating this several times appears to show the same values each time, so it may be a GPIO setting that is incorrect. I don't understand the driver code as intricately as you. Jul 12 05:03:47 kyleabaker-desktop kernel: [ 117.600025] usb 2-10: new full speed USB device using ohci_hcd and address 4 Jul 12 05:03:47 kyleabaker-desktop kernel: [ 117.832495] Linux video capture interface: v2.00 Jul 12 05:03:47 kyleabaker-desktop kernel: [ 117.835301] gspca: main v2.9.0 registered Jul 12 05:03:47 kyleabaker-desktop kernel: [ 117.836042] gspca-2.9.51: probing 045e:00f7 Jul 12 05:03:48 kyleabaker-desktop kernel: [ 118.840036] sonixj-2.9.51: reg_w1 [00f1] = 01 Jul 12 05:03:49 kyleabaker-desktop kernel: [ 119.850013] sonixj-2.9.51: reg_w1 [00f1] = 00 Jul 12 05:03:49 kyleabaker-desktop kernel: [ 119.854147] sonixj-2.9.51: Sonix chip id: 11 Jul 12 05:03:50 kyleabaker-desktop kernel: [ 120.860022] sonixj-2.9.51: reg_w [0001] = 29 74 .. Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.872517] sonixj-2.9.51: reg_w1 [00f1] = 00 Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874230] input: sonixj as /devices/pci:00/:00:02.0/usb2/2-10/input/input4 Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874315] gspca-2.9.51: video0 created Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874318] gspca-2.9.51: found int in endpoint: 0x83, buffer_len=1, interval=100 Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874337] gspca-2.9.51: 045e:00f7 bad interface 1 Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874345] gspca-2.9.51: 045e:00f7 bad interface 2 Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874361] usbcore: registered new interface driver sonixj Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.874363] sonixj: registered Jul 12 05:03:51 kyleabaker-desktop kernel: [ 121.970290] usbcore: registered new interface driver snd-usb-audio Jul 12 05:05:22 kyleabaker-desktop kernel: [ 212.443063] gspca-2.9.51: found int in endpoint: 0x83, buffer_len=1, interval=100 Jul 12 05:05:23 kyleabaker-desktop kernel: [ 213.450017] sonixj-2.9.51: reg_w1 [0001] = 61 Jul 12 05:05:24 kyleabaker-desktop kernel: [ 214.460030] sonixj-2.9.51: reg_w [0001] = 61 44 .. Jul 12 05:05:25 kyleabaker-desktop kernel: [ 215.472516] sonixj-2.9.51: reg_w [0008] = 81 21 .. Jul 12 05:05:26 kyleabaker-desktop kernel: [ 216.480018] sonixj-2.9.51: reg_w [0017] = 20 07 .. Jul 12 05:05:27 kyleabaker-desktop kernel: [ 217.490018] sonixj-2.9.51: reg_w [009a] = 00 40 .. Jul 12 05:05:28 kyleabaker-desktop kernel: [ 218.500019] sonixj-2.9.51: reg_w [00d4] = 60 00 .. Jul 12 05:05:29 kyleabaker-desktop kernel: [ 219.518667] sonixj-2.9.51: reg_w [0003] = 00 1a .. Jul 12 05:05:30 kyleabaker-desktop kernel: [ 220.532524] sonixj-2.9.51: reg_w1 [0001] = 63 Jul 12 05:05:31 kyleabaker-desktop kernel: [ 221.542516] sonixj-2.9.51: reg_w1 [0017] = 20 Jul 12 05:05:32 kyleabaker-desktop kernel: [ 222.559770] sonixj-2.9.51: reg_w1 [0001] = 62 Jul 12 05:05:33 kyleabaker-desktop kernel: [ 223.570016] sonixj-2.9.51: reg_w1 [0001] = 42 Jul 12 05:05:34 kyleabaker-desktop kernel: [ 224.692515] sonixj-2.9.51: reg_w1 [0002] = 62 Jul 12 05:05:36 kyleabaker-desktop kernel: [ 226.690016] sonixj-2.9.51: reg_w1 [0002] = 40 Jul 12 05:05:37 kyleabaker-desktop kernel: [ 227.700014] sonixj-2.9.51: reg_w1 [0002] = 40 Jul 12 05:05:38
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Mon, 12 Jul 2010 05:28:15 -0400 Kyle Baker kyleaba...@gmail.com wrote: Here is the exchange from plugging in my webcam until I quit Cheese. The point that the mic quits is at [ 224.692515] sonixj-2.9.51: reg_w1 [0002] = 62 as far as I can tell. I hope this sheds some light on the issue. Repeating this several times appears to show the same values each time, so it may be a GPIO setting that is incorrect. I don't understand the driver code as intricately as you. Fine job! The register 02 is the GPIO register. It seems the audio does not work when the bit 0x04 is not set. I am working on the driver for the other webcams, but you may patch it yourself removing the register 02 settings at lines 1752, 2320 and 2321 of sonixj.c. Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Mon, Jul 12, 2010 at 7:21 AM, Jean-Francois Moine moin...@free.fr wrote:
Fine job! The register 02 is the GPIO register. It seems the audio does
not work when the bit 0x04 is not set. I am working on the driver for
the other webcams, but you may patch it yourself removing the register
02 settings at lines 1752, 2320 and 2321 of sonixj.c.
Thank you for your help. I've gotten this working for me by using the
following conditional to determine if the driver should run the code
that changes register 02 or not.
if (sd-sensor != SENSOR_OV7660)
reg_w1(gspca_dev, 0x02, 0x62);
and
if (sd-sensor != SENSOR_OV7660) {
reg_w1(gspca_dev, 0x02, reg2);
reg_w1(gspca_dev, 0x02, reg2);
}
These do fix the audio problem, but they may not be good for other
Sensor OV7660 devices. I am not sure how to identify only my model
here, but that may be ideal for a better patch. I wonder if this patch
would also be needed for the VX-3000 model?
I've attached the patch that I'm using. I attached the diff -c and
diff -uNr style patches. the uNr style looks more like the
changesets I've found at LinuxTV.org so it may be the easiest to
apply. I hope the patch helps!
Hopefully this will make it into the Kernel source before too long so
it works on other computers without modification. :D
Cheers.
--
Kyle Baker
sonixj-vx1000.patch
Description: Binary data
sonixj-vx1000-diff-uNr.patch
Description: Binary data
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sat, 10 Jul 2010 22:30:58 -0400 Kyle Baker kyleaba...@gmail.com wrote: Is this change from 0x40 to 0x44 intended to fix the bad interface messages as well as the mic becoming disabled? Also, is a reboot after installing these drivers and changes required? I'm only curious because it takes so much longer to test changes. The change from 0x40 to 0x44 is applied to the GPIO register of the SN9C105 which is the bridge of the webcam. I was thinking that some values of this register could break the audio input. It does not seem so. The bad interface messages are printed when the audio interfaces are called by HAL for probe by the video driver. This is not an error. I will remove this message in the next version. Rebooting after installing a new version of a module is not needed. The module may be removed from memory by 'rmmod'. In your case, when updating sonixj, you just need to unplug the webcam, do rmmod gspca_sonixj and replug the webcam. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sun, Jul 11, 2010 at 9:50 AM, Jean-Francois Moine moin...@free.fr wrote: The change from 0x40 to 0x44 is applied to the GPIO register of the SN9C105 which is the bridge of the webcam. I was thinking that some values of this register could break the audio input. It does not seem so. It looks like this webcam has not been working properly since Ubuntu Hardy. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/280657 I'm not sure of the version included in Hardy. Would it help if I tried to find the GSPCA version from Hardy to compare the changes? In searching for details on this webcam model, I came across some patches that you submitted a while back that initialize the GPIO with different values. I tested those, but saw no results. I see you've worked on this specific driver quiet a bit in the past: http://linuxtv.org/hg/~hgoede/gspca/rev/65247a979498 Is the previous maintainer, Michel Xhaard, still working on this driver at all? I wonder if he might be able to help identify the problem or narrow it down. Which function is called when I open Cheese or other video applications? Initializing the webcam appears to be correct, however, sd_start() or the one that starts the video capture appears to be toggling or changing some setting. If I knew of a way, I would insert more debug messages to help pinpoint the place where the microphone breaks along with some boolean to show that its working or not. Thanks. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Sat, Jul 10, 2010 at 5:36 AM, Jean-Francois Moine moin...@free.fr wrote: So, the GPIO register is the second one of the bridge. It is initialized at line 71 of sonixj.c. May you change it from 0x40 to 0x44? (see attached diff) I've compiled the driver with this updated setting and it appears to be the same. The microphone works initially, until video is loaded. $ dmesg | grep gspca [ 22.141766] gspca: main v2.9.0 registered [ 22.163928] gspca-2.9.50: probing 045e:00f7 [ 22.181869] gspca-2.9.50: video0 created [ 22.181872] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 22.181894] gspca-2.9.50: 045e:00f7 bad interface 1 [ 22.181902] gspca-2.9.50: 045e:00f7 bad interface 2 [ 544.774056] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 546.318045] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 Is this change from 0x40 to 0x44 intended to fix the bad interface messages as well as the mic becoming disabled? Also, is a reboot after installing these drivers and changes required? I'm only curious because it takes so much longer to test changes. Thanks. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Thu, 8 Jul 2010 18:54:41 -0400 Kyle Baker kyleaba...@gmail.com wrote: My conclusion, reducing gspca_dev-nbalt by values 1-5 apparently fix the bandwidth issue and don't alter the video input. However, they also do not correct the issue where the microphone breaks and becomes disabled. OK. So, this means that the sonixj driver sets something in the webcam which prevents the audio to run. I don't see anything but the GPIO. I have no ms-win trace from your webcam. May you do it? I just need the connection and one second of streaming with a USB sniffer in text mode as sniffbin. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Fri, Jul 9, 2010 at 2:03 PM, Jean-Francois Moine moin...@free.fr wrote: OK. So, this means that the sonixj driver sets something in the webcam which prevents the audio to run. I don't see anything but the GPIO. I was considering adding more code to print out more detailed IO information. I have no ms-win trace from your webcam. May you do it? I just need the connection and one second of streaming with a USB sniffer in text mode as sniffbin. I tried using a couple of USB sniffers in Windows 7, but I'm unable to find one that has an option to save in text mode as sniffbin. Apologies in advanced for the length of the log files that I managed to capture. I captured the device connection, video capture start and stop, then device removed. The capture start took a moment to begin since the application loaded more slowly with usb capturing in progress. --- I tried using the open source SnoopyPro under Windows 7 and I'm not sure how well it works normally, but I was unable to capture any usb traffic in Win7. If you have any other suggestions let me know, because I've never used a usb sniffer before. I connected my webcam to a Windows XP laptop and was able to get it to capture (Windows XP laptop is 32-bit, Windows7/Ubuntu 10.10 desktop is 64-bit...which is what I am working to get the webcam working on). http://sourceforge.net/projects/usbsnoop/ In the USB Devices list I see my camera listed 3 times: USB\VID_045EPID_00F7REV_0101MI_00,USB\VID_045EPID_00F7MI_00 USB\VID_045EPID_00F7REV_0101MI_01,USB\VID_045EPID_00F7MI_01 USB\VID_045EPID_00F7REV_0101,USB\VID_045EPID_00F7 Log file from SnoopyPro: http://bit.ly/bNJiLu --- I also installed a free usb sniffer called Simple USB Logger that seemed to do a very good job and I captured data from the point that the camera was plugged into usb, then start capture, end capture and unplugged from usb. So it should be a large bit of the data you will need. http://www.all-freeware.com/download/67384/simple-usb-logger.html Log file from Simple USB Logger: http://bit.ly/92ipQ8 --- I hope these help and are what you were looking for. Let me know if you needed something different or if there is more information I can send to you. I've saved the exact program versions in case you have trouble getting them for any reason and would like to look into them: SnoopyPro: http://bit.ly/bX6r9r Simple USB Logger: http://bit.ly/bshLuz Thanks. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Wed, 7 Jul 2010 17:32:43 -0400 Kyle Baker kyleaba...@gmail.com wrote: I've edited the gspca.c file with your suggestion to begin testing, but I'm unable to get the new drivers to compile with and Error 2. Strange! Well, I put the change my test version. May you get this one from my web page and test it? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Thu, Jul 8, 2010 at 6:14 AM, Jean-Francois Moine moin...@free.fr wrote: Strange! Well, I put the change my test version. May you get this one from my web page and test it? Okay, now I've exhausted the quick fixes that you've suggested and have come to a new conclusion. Without modifying the value in gspca_dev-nbalt the drivers will report bandwidth not wide enough - trying again. Modifying this value to subtract between 1 and 8 seems to eliminate this bandwidth error. However, the results ultimately stay the same as before where there is video and no audio for decreasing gspca_dev-nbalt from 0-5. Video input stops working after decreasing by 6-8 while still breaking the audio input, except for decreasing by 8 where the video breaks and audio remains...due to a no transfer endpoint found message. My conclusion, reducing gspca_dev-nbalt by values 1-5 apparently fix the bandwidth issue and don't alter the video input. However, they also do not correct the issue where the microphone breaks and becomes disabled. Below is a log that I kept of each test, compiling the changes, rebooting, testing and recording, then repeating for each decrement. - gspca_dev-nbalt -= 0; /* or same as no change */ Initial startup (audio works) $ dmesg | grep gspca [ 21.268018] gspca: main v2.9.0 registered [ 21.268850] gspca-2.9.50: probing 045e:00f7 [ 21.285392] gspca-2.9.50: video0 created [ 21.285395] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.285413] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.285419] gspca-2.9.50: 045e:00f7 bad interface 2 Started Cheese (video works, no audio) $ dmesg | grep gspca [ 21.268018] gspca: main v2.9.0 registered [ 21.268850] gspca-2.9.50: probing 045e:00f7 [ 21.285392] gspca-2.9.50: video0 created [ 21.285395] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.285413] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.285419] gspca-2.9.50: 045e:00f7 bad interface 2 [ 158.861671] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 160.405694] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 160.405698] gspca-2.9.50: bandwidth not wide enough - trying again [ 160.434684] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 175.635876] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 gspca_dev-nbalt -= 1; Initial startup (audio works) $ dmesg | grep gspca [ 21.905722] gspca: main v2.9.0 registered [ 21.915236] gspca-2.9.50: probing 045e:00f7 [ 21.931505] gspca-2.9.50: video0 created [ 21.931508] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.931528] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.931536] gspca-2.9.50: 045e:00f7 bad interface 2 Started Cheese (video works, no audio) $ dmesg | grep gspca [ 21.905722] gspca: main v2.9.0 registered [ 21.915236] gspca-2.9.50: probing 045e:00f7 [ 21.931505] gspca-2.9.50: video0 created [ 21.931508] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 21.931528] gspca-2.9.50: 045e:00f7 bad interface 1 [ 21.931536] gspca-2.9.50: 045e:00f7 bad interface 2 [ 188.170963] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 188.170963] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 gspca_dev-nbalt -= 2; Initial startup (audio works) $ dmesg | grep gspca [ 22.463556] gspca: main v2.9.0 registered [ 22.466506] gspca-2.9.50: probing 045e:00f7 [ 22.483436] gspca-2.9.50: video0 created [ 22.483438] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 22.483458] gspca-2.9.50: 045e:00f7 bad interface 1 [ 22.483465] gspca-2.9.50: 045e:00f7 bad interface 2 Started Cheese (video works, no audio) $ dmesg | grep gspca [ 22.463556] gspca: main v2.9.0 registered [ 22.466506] gspca-2.9.50: probing 045e:00f7 [ 22.483436] gspca-2.9.50: video0 created [ 22.483438] gspca-2.9.50: found int in endpoint: 0x83, buffer_len=1, interval=100 [ 22.483458] gspca-2.9.50: 045e:00f7 bad interface 1 [
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Wed, Jul 7, 2010 at 1:44 AM, Jean-Francois Moine moin...@free.fr wrote: Hi Kyle, The problem is known. I have no fix yet, but it seems that you use a USB 1.1. or that you have some other device on the same bus. May you try to connect your webcam to an other USB port? Best regards. I tested different ports, but the results are the same. From the log files it appears to be connecting via USB2. Jul 7 01:48:54 kyleabaker-desktop kernel: [ 6186.202520] usb 2-1: new full speed USB device using ohci_hcd and address 6 Jul 7 01:48:54 kyleabaker-desktop kernel: [ 6186.426975] gspca: probing 045e:00f7 Jul 7 01:48:54 kyleabaker-desktop kernel: [ 6186.438792] sonixj: Sonix chip id: 11 Jul 7 01:48:54 kyleabaker-desktop kernel: [ 6186.444844] input: sonixj as /devices/pci:00/:00:02.0/usb2/2-1/input/input7 Jul 7 01:48:54 kyleabaker-desktop kernel: [ 6186.444916] gspca: video0 created Jul 7 01:48:54 kyleabaker-desktop kernel: [ 6186.444918] gspca: found int in endpoint: 0x83, buffer_len=1, interval=100 The only usb devices connected are my keyboard, mouse and vx-1000 webcam. I can get the microphone back if I reset the modules: sudo rmmod gspca_sonixj sudo modprobe gspca_sonixj If the microphone works when used alone (with the sound recorder application) and video works in Cheese, why would they not work together at the same time? I'm looking through the sonixj.c code to see if I can find where its breaking, but I'm not very experienced in C. I've been trying to get this worked out for a year, so if there is anything I can do to help fix this bug let me know. This is a fairly common webcam, so it would be great to see this resolved soon. What is the current priority of this bug? -- Thanks, Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Wed, 7 Jul 2010 02:57:54 -0400 Kyle Baker kyleaba...@gmail.com wrote: If the microphone works when used alone (with the sound recorder application) and video works in Cheese, why would they not work together at the same time? I'm looking through the sonixj.c code to see if I can find where its breaking, but I'm not very experienced in C. I've been trying to get this worked out for a year, so if there is anything I can do to help fix this bug let me know. This is a fairly common webcam, so it would be great to see this resolved soon. What is the current priority of this bug? The video and audio don't work at the same time because the video is opened before the audio and it takes all the USB bandwidth. The problem is in the main gspca.c, not in sonixj.c. It may fixed using a lower alternate setting. To check it, you may add the following lines: if (dev-config-desc.bNumInterfaces != 1) gspca_dev-nbalt -= 1; after gspca_dev-nbalt = intf-num_altsetting; in the function gspca_dev_probe() of gspca.c. If it still does not work, change -= 1 to -= 2 or -= 3 (there are 8 alternate settings in your webcam). For a correct fix, the exact video bandwidth shall be calculated and I could not find yet time enough to do the job and people to test it... Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Wed, Jul 7, 2010 at 5:06 AM, Jean-Francois Moine moin...@free.fr wrote: The video and audio don't work at the same time because the video is opened before the audio and it takes all the USB bandwidth. The problem is in the main gspca.c, not in sonixj.c. It may fixed using a lower alternate setting. To check it, you may add the following lines: if (dev-config-desc.bNumInterfaces != 1) gspca_dev-nbalt -= 1; after gspca_dev-nbalt = intf-num_altsetting; in the function gspca_dev_probe() of gspca.c. If it still does not work, change -= 1 to -= 2 or -= 3 (there are 8 alternate settings in your webcam). I've edited the gspca.c file with your suggestion to begin testing, but I'm unable to get the new drivers to compile with and Error 2. For a correct fix, the exact video bandwidth shall be calculated and I could not find yet time enough to do the job and people to test it... If you find time to start progress on this, I will be ready to test your changes. In the meantime, I will continue trying to compile and test these changes. If I understood more of how everything works then I'd start the bandwidth calculation progress myself. Unfortunately I don't, but I may be able to get a patch working if this will ever compile. Thanks. -- Kyle Baker -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64
On Mon, 5 Jul 2010 17:40:18 -0400 Kyle Baker kyleaba...@gmail.com wrote: I'm testing the VX-1000 model web cam in test builds of Ubuntu 10.10 x86_64 and have found that the gspca drivers allow the microphone to work with a sound recorder initially. However, when I test sound and video together with Cheese, the microphone no longer works and doesn't work again on the computer until the web cam is detached and reattached. I was able to track the events in the system logs as follows: [snip] Jul 5 16:53:37 kyleabaker-desktop kernel: [105042.537960] gspca: bandwidth not wide enough - trying again [snip] I opened Cheese to test sound and video at the 16:53 point. This seems to be unique to x86_64 systems as I'm getting reports that 32-bit users are not having any problems with this, but I don't have a 32-bit install to test myself. The selected input microphone remains the one in the web cam, but the drivers fail or break when it is started with video. Hi Kyle, The problem is known. I have no fix yet, but it seems that you use a USB 1.1. or that you have some other device on the same bus. May you try to connect your webcam to an other USB port? Best regards. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
