Microsoft VX-1000 Microphone Drivers Crash in x86_64

Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

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:

Jul 5 16:49:52 kyleabaker-desktop kernel: [104818.122525] usb 2-1: new
full speed USB device using ohci_hcd and address 5
Jul 5 16:49:53 kyleabaker-desktop kernel: [104818.349087] gspca:
probing 045e:00f7
Jul 5 16:49:53 kyleabaker-desktop kernel: [104818.361046] sonixj:
Sonix chip id: 11
Jul 5 16:49:53 kyleabaker-desktop kernel: [104818.367105] input:
sonixj as /devices/pci0000:00/0000:00:02.0/usb2/2-1/input/input5
Jul 5 16:49:53 kyleabaker-desktop kernel: [104818.367172] gspca: video0 created
Jul 5 16:49:53 kyleabaker-desktop kernel: [104818.367174] gspca: found
int in endpoint: 0x83, buffer_len=1, interval=100
Jul 5 16:49:53 kyleabaker-desktop kernel: [104818.367235] gspca:
probing 045e:00f7
Jul 5 16:53:35 kyleabaker-desktop kernel: [105040.981955] gspca: found
int in endpoint: 0x83, buffer_len=1, interval=100
Jul 5 16:53:37 kyleabaker-desktop kernel: [105042.537923] ohci_hcd
0000:00:02.0: leak ed ffff88003796e370 (#81) state 2
Jul 5 16:53:37 kyleabaker-desktop kernel: [105042.537957] gspca: found
int in endpoint: 0x83, buffer_len=1, interval=100
Jul 5 16:53:37 kyleabaker-desktop kernel: [105042.537960] gspca:
bandwidth not wide enough - trying again
Jul 5 16:53:37 kyleabaker-desktop kernel: [105042.564943] gspca: found
int in endpoint: 0x83, buffer_len=1, interval=100
Jul 5 16:54:08 kyleabaker-desktop kernel: [105073.800352] gspca: found
int in endpoint: 0x83, buffer_len=1, interval=100

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.

--
Kyle Baker

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Mon, 5 Jul 2010 17:40:18 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Wed, Jul 7, 2010 at 1:44 AM, Jean-Francois Moine <moinejf@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/pci0000:00/0000: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

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Wed, 7 Jul 2010 02:57:54 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Wed, Jul 7, 2010 at 5:06 AM, Jean-Francois Moine <moinejf@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

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Wed, 7 Jul 2010 17:32:43 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Thu, Jul 8, 2010 at 6:14 AM, Jean-Francois Moine <moinejf@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
		[   22.483465] gspca-2.9.50: 045e:00f7 bad interface 2
		[  139.718647] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[  147.487578] gspca-2.9.50: frame overflow 234239 > 233472
		[  158.147090] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100

gspca_dev->nbalt -= 3;

	Initial startup (audio works)
		$ dmesg | grep "gspca"
		[   21.295529] gspca: main v2.9.0 registered
		[   21.296266] gspca-2.9.50: probing 045e:00f7
		[   21.321505] gspca-2.9.50: video0 created
		[   21.321508] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.321528] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.321536] gspca-2.9.50: 045e:00f7 bad interface 2

	Started Cheese (video works, no audio)
		$ dmesg | grep "gspca"
		[   21.295529] gspca: main v2.9.0 registered
		[   21.296266] gspca-2.9.50: probing 045e:00f7
		[   21.321505] gspca-2.9.50: video0 created
		[   21.321508] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.321528] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.321536] gspca-2.9.50: 045e:00f7 bad interface 2
		[  130.140725] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[  138.444830] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100

gspca_dev->nbalt -= 4;

	Initial startup (audio works)
		$ dmesg | grep "gspca"
		[   21.775525] gspca: main v2.9.0 registered
		[   21.776456] gspca-2.9.50: probing 045e:00f7
		[   21.793435] gspca-2.9.50: video0 created
		[   21.793438] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.793455] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.793463] gspca-2.9.50: 045e:00f7 bad interface 2

	Started Cheese (video works, no audio)
		$ dmesg | grep "gspca"
		[   21.775525] gspca: main v2.9.0 registered
		[   21.776456] gspca-2.9.50: probing 045e:00f7
		[   21.793435] gspca-2.9.50: video0 created
		[   21.793438] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.793455] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.793463] gspca-2.9.50: 045e:00f7 bad interface 2
		[  102.566613] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[  107.669128] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100

gspca_dev->nbalt -= 5;

	Initial startup (audio works)
		$ dmesg | grep "gspca"
		[   21.150636] gspca: main v2.9.0 registered
		[   21.151538] gspca-2.9.50: probing 045e:00f7
		[   21.174690] gspca-2.9.50: video0 created
		[   21.174692] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.174710] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.174717] gspca-2.9.50: 045e:00f7 bad interface 2

	Started Cheese (video works, no audio)
		$ dmesg | grep "gspca"
		[   21.150636] gspca: main v2.9.0 registered
		[   21.151538] gspca-2.9.50: probing 045e:00f7
		[   21.174690] gspca-2.9.50: video0 created
		[   21.174692] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.174710] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.174717] gspca-2.9.50: 045e:00f7 bad interface 2
		[  103.857992] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[  108.318804] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100

gspca_dev->nbalt -= 6;

	Initial startup (audio works)
		$ dmesg | grep "gspca"
		[   21.719670] gspca: main v2.9.0 registered
		[   21.720735] gspca-2.9.50: probing 045e:00f7
		[   21.741407] gspca-2.9.50: video0 created
		[   21.741409] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.741425] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.741433] gspca-2.9.50: 045e:00f7 bad interface 2

	Started Cheese (no video, no audio)
		$ dmesg | grep "gspca"
		[   21.719670] gspca: main v2.9.0 registered
		[   21.720735] gspca-2.9.50: probing 045e:00f7
		[   21.741407] gspca-2.9.50: video0 created
		[   21.741409] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.741425] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.741433] gspca-2.9.50: 045e:00f7 bad interface 2
		[   86.749179] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   98.646330] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100

gspca_dev->nbalt -= 7;

	Initial startup (audio works)
		$ dmesg | grep "gspca"
		[   21.911549] gspca: main v2.9.0 registered
		[   21.912648] gspca-2.9.50: probing 045e:00f7
		[   21.934429] gspca-2.9.50: video0 created
		[   21.934431] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.934452] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.934460] gspca-2.9.50: 045e:00f7 bad interface 2

	Started Cheese (no video, no audio)
		$ dmesg | grep "gspca"
		[   21.911549] gspca: main v2.9.0 registered
		[   21.912648] gspca-2.9.50: probing 045e:00f7
		[   21.934429] gspca-2.9.50: video0 created
		[   21.934431] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.934452] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.934460] gspca-2.9.50: 045e:00f7 bad interface 2
		[  108.513126] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[  121.592828] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100

gspca_dev->nbalt -= 8;

	Initial startup (audio works)
		$ dmesg | grep "gspca"
		[   21.215610] gspca: main v2.9.0 registered
		[   21.217198] gspca-2.9.50: probing 045e:00f7
		[   21.233435] gspca-2.9.50: video0 created
		[   21.233437] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.233459] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.233467] gspca-2.9.50: 045e:00f7 bad interface 2

	Started Cheese (no video, audio works)
		$ dmesg | grep "gspca"
		[   21.215610] gspca: main v2.9.0 registered
		[   21.217198] gspca-2.9.50: probing 045e:00f7
		[   21.233435] gspca-2.9.50: video0 created
		[   21.233437] gspca-2.9.50: found int in endpoint: 0x83,
buffer_len=1, interval=100
		[   21.233459] gspca-2.9.50: 045e:00f7 bad interface 1
		[   21.233467] gspca-2.9.50: 045e:00f7 bad interface 2
		[   85.830434] gspca: no transfer endpoint found

-------------------------------------

The point of breaking the microphone appears to be at the same
instance that the second "found int in endpoint: 0x83, buffer_len=1,
interval=100" occurs. This is in the alloc_and_submit_int_urb()
function in gspca.c.

Is there any way that I can do a deeper trace on this to find what is
actually going wrong here?

Does this help at all?

Thanks.

-- 
Kyle Baker

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Thu, 8 Jul 2010 18:54:41 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Fri, Jul 9, 2010 at 2:03 PM, Jean-Francois Moine <moinejf@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_045E&PID_00F7&REV_0101&MI_00,USB\VID_045E&PID_00F7&MI_00
USB\VID_045E&PID_00F7&REV_0101&MI_01,USB\VID_045E&PID_00F7&MI_01
USB\VID_045E&PID_00F7&REV_0101,USB\VID_045E&PID_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

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Fri, 9 Jul 2010 17:04:03 -0400
Kyle Baker <kyleabaker@gmail.com> wrote:

> 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

I could not use the "Simple USB Logger". With "SnoopyPro", it is easier:
- start ms-win
- start snoopypro
- open the binary log file
- select all
- expand
- select all
- copy
- start notepad
- paste
- save the log file
- and move it to Linux.

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)

If this does not work, I saw some other little differences..

Best regards.

-- 
Ken ar c'hentañ	|	      ** Breizh ha Linux atav! **
Jef		|		http://moinejf.free.fr/

[-- Attachment #2: patch.pat --]
[-- Type: application/octet-stream, Size: 493 bytes --]

--- sonixj.c~	2010-06-04 11:35:56.000000000 +0200
+++ sonixj.c	2010-07-10 11:03:02.000000000 +0200
@@ -468,7 +468,7 @@ static const u8 sn_ov7648[0x1c] = {
 
 static const u8 sn_ov7660[0x1c] = {
 /*	reg0	reg1	reg2	reg3	reg4	reg5	reg6	reg7 */
-	0x00,	0x61,	0x40,	0x00,	0x1a,	0x00,	0x00,	0x00,
+	0x00,	0x61,	0x44,	0x00,	0x1a,	0x00,	0x00,	0x00,
 /*	reg8	reg9	rega	regb	regc	regd	rege	regf */
 	0x81,	0x21,	0x00,	0x00,	0x00,	0x00,	0x00,	0x00,
 /*	reg10	reg11	reg12	reg13	reg14	reg15	reg16	reg17 */

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Sat, Jul 10, 2010 at 5:36 AM, Jean-Francois Moine <moinejf@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

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Sat, 10 Jul 2010 22:30:58 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Sun, 11 Jul 2010 17:18:53 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Mon, Jul 12, 2010 at 4:18 AM, Jean-Francois Moine <moinejf@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/pci0000:00/0000: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 kyleabaker-desktop kernel: [  228.720016]
sonixj-2.9.51: reg_w1 [0015] = 28
Jul 12 05:05:39 kyleabaker-desktop kernel: [  229.730020]
sonixj-2.9.51: reg_w1 [0016] = 1e
Jul 12 05:05:40 kyleabaker-desktop kernel: [  230.742519]
sonixj-2.9.51: reg_w1 [0012] = 01
Jul 12 05:05:41 kyleabaker-desktop kernel: [  231.750015]
sonixj-2.9.51: reg_w1 [0013] = 01
Jul 12 05:05:42 kyleabaker-desktop kernel: [  232.760073]
sonixj-2.9.51: reg_w1 [0018] = 07
Jul 12 05:05:43 kyleabaker-desktop kernel: [  233.770014]
sonixj-2.9.51: reg_w1 [00d2] = 6a
Jul 12 05:05:44 kyleabaker-desktop kernel: [  234.790030]
sonixj-2.9.51: reg_w1 [00d3] = 50
Jul 12 05:05:45 kyleabaker-desktop kernel: [  235.792515]
sonixj-2.9.51: reg_w1 [00c6] = 00
Jul 12 05:05:46 kyleabaker-desktop kernel: [  236.802516]
sonixj-2.9.51: reg_w1 [00c7] = 00
Jul 12 05:05:47 kyleabaker-desktop kernel: [  237.810018]
sonixj-2.9.51: reg_w1 [00c8] = 50
Jul 12 05:05:48 kyleabaker-desktop kernel: [  238.830014]
sonixj-2.9.51: reg_w1 [00c9] = 3c
Jul 12 05:05:49 kyleabaker-desktop kernel: [  239.832516]
sonixj-2.9.51: reg_w1 [0018] = 07
Jul 12 05:05:50 kyleabaker-desktop kernel: [  240.840017]
sonixj-2.9.51: reg_w1 [0017] = a0
Jul 12 05:05:51 kyleabaker-desktop kernel: [  241.850068]
sonixj-2.9.51: reg_w1 [0005] = 00
Jul 12 05:05:52 kyleabaker-desktop kernel: [  242.860017]
sonixj-2.9.51: reg_w1 [0007] = 00
Jul 12 05:05:53 kyleabaker-desktop kernel: [  243.870016]
sonixj-2.9.51: reg_w1 [0006] = 00
Jul 12 05:05:54 kyleabaker-desktop kernel: [  244.880016]
sonixj-2.9.51: reg_w1 [0014] = 08
Jul 12 05:05:55 kyleabaker-desktop kernel: [  245.890305]
sonixj-2.9.51: reg_w [0020] = 00 2d ..
Jul 12 05:05:56 kyleabaker-desktop kernel: [  246.900017]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:05:57 kyleabaker-desktop kernel: [  247.910015]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:05:58 kyleabaker-desktop kernel: [  248.920015]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:05:59 kyleabaker-desktop kernel: [  249.940014]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:00 kyleabaker-desktop kernel: [  250.950019]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:01 kyleabaker-desktop kernel: [  251.960015]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:02 kyleabaker-desktop kernel: [  252.970014]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:03 kyleabaker-desktop kernel: [  253.980306]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:04 kyleabaker-desktop kernel: [  254.997213]
sonixj-2.9.51: reg_w1 [009a] = 05
Jul 12 05:06:05 kyleabaker-desktop kernel: [  256.000020]
sonixj-2.9.51: reg_w1 [0099] = 5a
Jul 12 05:06:06 kyleabaker-desktop kernel: [  257.010014]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:07 kyleabaker-desktop kernel: [  258.026869]
sonixj-2.9.51: reg_w1 [0005] = 20
Jul 12 05:06:08 kyleabaker-desktop kernel: [  259.030015]
sonixj-2.9.51: reg_w1 [0007] = 20
Jul 12 05:06:09 kyleabaker-desktop kernel: [  260.050023]
sonixj-2.9.51: reg_w1 [0006] = 20
Jul 12 05:06:11 kyleabaker-desktop kernel: [  261.400021]
sonixj-2.9.51: reg_w [00c0] = 2d 2d ..
Jul 12 05:06:12 kyleabaker-desktop kernel: [  262.410019]
sonixj-2.9.51: reg_w [00ca] = 28 d8 ..
Jul 12 05:06:13 kyleabaker-desktop kernel: [  263.420015]
sonixj-2.9.51: reg_w [00ce] = 32 dd ..
Jul 12 05:06:14 kyleabaker-desktop kernel: [  264.430016]
sonixj-2.9.51: reg_w1 [0018] = 47
Jul 12 05:06:15 kyleabaker-desktop kernel: [  265.442517]
sonixj-2.9.51: reg_w1 [0018] = 07
Jul 12 05:06:16 kyleabaker-desktop kernel: [  266.450016]
sonixj-2.9.51: reg_w1 [0017] = 22
Jul 12 05:06:17 kyleabaker-desktop kernel: [  267.460025]
sonixj-2.9.51: reg_w1 [0001] = 06
Jul 12 05:06:18 kyleabaker-desktop kernel: [  268.470016]
sonixj-2.9.51: reg_w1 [0096] = 00
Jul 12 05:06:19 kyleabaker-desktop kernel: [  269.480018]
sonixj-2.9.51: reg_w [0084] = 14 00 ..
Jul 12 05:06:20 kyleabaker-desktop kernel: [  270.497626]
sonixj-2.9.51: reg_w [008a] = e8 0f ..
Jul 12 05:06:21 kyleabaker-desktop kernel: [  271.602523]
sonixj-2.9.51: reg_w1 [0001] = 61
Jul 12 05:06:22 kyleabaker-desktop kernel: [  272.612517]
sonixj-2.9.51: reg_w1 [0017] = 20
Jul 12 05:06:23 kyleabaker-desktop kernel: [  273.620018]
sonixj-2.9.51: reg_w1 [0001] = 61
Jul 12 05:06:24 kyleabaker-desktop kernel: [  274.640013]
sonixj-2.9.51: reg_w1 [0001] = 0b
Jul 12 05:06:24 kyleabaker-desktop kernel: [  274.644749]
gspca-2.9.51: found int in endpoint: 0x83, buffer_len=1, interval=100

> 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?

I know my computer has USB 2.0 ports, but they all seem to be falling
back to 1.1 (if thats what you're seeing them as). I understand the
bandwidth is greater in USB 2.0, but are there other problems that
would be causing this?

Thanks, I think we may be getting somewhere now.

-- 
Kyle Baker

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Mon, 12 Jul 2010 05:28:15 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]

On Mon, Jul 12, 2010 at 7:21 AM, Jean-Francois Moine <moinejf@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

[-- Attachment #2: sonixj-vx1000.patch --]
[-- Type: application/octet-stream, Size: 1032 bytes --]

*** sonixj-original.c	2010-07-10 05:03:02.000000000 -0400
--- sonixj-patch.c	2010-07-12 17:52:20.000000000 -0400
***************
*** 1749,1755 ****
  		reg_w1(gspca_dev, 0x01, 0x62);
  		reg_w1(gspca_dev, 0x01, 0x42);
  		msleep(100);
! 		reg_w1(gspca_dev, 0x02, 0x62);
  		break;
  	default:
  /*	case SENSOR_HV7131R: */
--- 1749,1756 ----
  		reg_w1(gspca_dev, 0x01, 0x62);
  		reg_w1(gspca_dev, 0x01, 0x42);
  		msleep(100);
! 		if (sd->sensor != SENSOR_OV7660)
! 			reg_w1(gspca_dev, 0x02, 0x62);
  		break;
  	default:
  /*	case SENSOR_HV7131R: */
***************
*** 2317,2324 ****
  		reg2 = 0x40;
  		break;
  	}
! 	reg_w1(gspca_dev, 0x02, reg2);
! 	reg_w1(gspca_dev, 0x02, reg2);
  
  	reg_w1(gspca_dev, 0x15, sn9c1xx[0x15]);
  	reg_w1(gspca_dev, 0x16, sn9c1xx[0x16]);
--- 2318,2327 ----
  		reg2 = 0x40;
  		break;
  	}
! 	if (sd->sensor != SENSOR_OV7660) {
! 		reg_w1(gspca_dev, 0x02, reg2);
! 		reg_w1(gspca_dev, 0x02, reg2);
! 	}
  
  	reg_w1(gspca_dev, 0x15, sn9c1xx[0x15]);
  	reg_w1(gspca_dev, 0x16, sn9c1xx[0x16]);

[-- Attachment #3: sonixj-vx1000-diff-uNr.patch --]
[-- Type: application/octet-stream, Size: 687 bytes --]

--- sonixj-original.c	2010-07-10 05:03:02.000000000 -0400
+++ sonixj-patch.c	2010-07-12 17:52:20.000000000 -0400
@@ -1749,7 +1749,8 @@
 		reg_w1(gspca_dev, 0x01, 0x62);
 		reg_w1(gspca_dev, 0x01, 0x42);
 		msleep(100);
-		reg_w1(gspca_dev, 0x02, 0x62);
+		if (sd->sensor != SENSOR_OV7660)
+			reg_w1(gspca_dev, 0x02, 0x62);
 		break;
 	default:
 /*	case SENSOR_HV7131R: */
@@ -2317,8 +2318,10 @@
 		reg2 = 0x40;
 		break;
 	}
-	reg_w1(gspca_dev, 0x02, reg2);
-	reg_w1(gspca_dev, 0x02, reg2);
+	if (sd->sensor != SENSOR_OV7660) {
+		reg_w1(gspca_dev, 0x02, reg2);
+		reg_w1(gspca_dev, 0x02, reg2);
+	}
 
 	reg_w1(gspca_dev, 0x15, sn9c1xx[0x15]);
 	reg_w1(gspca_dev, 0x16, sn9c1xx[0x16]);

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Jean-Francois Moine]

On Mon, 12 Jul 2010 19:01:51 -0400
Kyle Baker <kyleabaker@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/

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Tue, Jul 13, 2010 at 3:13 PM, Jean-Francois Moine <moinejf@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

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Tue, Jul 13, 2010 at 7:59 PM, Kyle Baker <kyleabaker@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

Re: Microsoft VX-1000 Microphone Drivers Crash in x86_64

[Kyle Baker]

On Wed, Jul 14, 2010 at 6:31 AM, Jean-Francois Moine <moinejf@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