Hey all,
So my pthread crash was solved by changing to a self compiled 2.6.13 kernel with ck patches applied.
So for all those googlers in the future my configuration is:
AMD64 3200+ a8v mainboard, nvidia N6600 gfx, 1GB RAM, 2.6.8 kernel running debian sarge and glibc 2.3.2 and 2.3.5. If your machine looks like this and your pthreads are crashing try changing to a 2.6.13 kernel.
Thanks again to all for the efforts, especially the folks on the glibc list and Johannes, who helped me a lot with debugging this issue.
B.
B. Bogart wrote:
Hey all,
So my pthread crash was solved by changing to a self compiled 2.6.13 kernel with ck patches applied.
now that is weird again. i was pretty sure that it was not the threading that caused the problems after our session yesterday. (probably the cx88xx-driver has got some fixes in 2.6.13 ?)
anyhow, great it seems to finally work
mfg.asdr. IOhannes
Hey,
There is left stills some issues. The most irritating being that I can't depend on the "device 2, mode NTSC 1, dimen 640 480" messages. My patch looks like this:
[device 2, mode NTSC 1, dimen 640 480< | / [pix_video] |
When I open the patch I get nothing on screen (white texture), and I suppose with three capture cards who knows what which video device it opens by default, anyhow I see no image.
Device 2 is the winTV card.
The first time I send this message I get the proper resolution, channel and device, BUT the image looks like it being being interpreted as PAL not NTSC. In order to get the image to appear properly I have to send the message a second time. Each time I send this message I get a "VIDEOSYNC: invalid argument" message to STDERR.
Trying to use one of the leadtek cards gets even more ugly.
I'm sending "device 1, mode NTSC 0, dimen 320 240" (See below this message about why I'm using 320x240)
This gives me no texture (just white), thought I should be seeing at least noise or blue-screen. I also get a "VIDEOCMCAPTURE: invalid argument" message. This only happens the first time I send this message, after that I get no messages in the console nor STDERR.
now the funny bit, If I switch back to the winTV and send the SAME message: "device 2, mode NTSC 1, dimen 640 480" I get white noise, not the video input I got the first time I sent that message. In order to get the video back I need to actually send the message: "device 2, mode NTSC 0, dimen 640 480".
So I reopen the patch and send the same message above: "device 2, mode NTSC 0, dimen 640 480" Now the first time I click on it I get my PAL interpreted video signal, the second time I get the white noise signal.
After much more testing I see that If the first thing I do is send the correct message directly after opening the patch then it seems to work ok, the mode and device message work as expected. It is only when I try and send these messages one after the other that things get messed up.
To summarize the issues:
1. Changing device and mode only seems to work the first time on Leadtek cards. We can always switch pact to the winTV card, but we also always get the PAL image on the first try.
2. Changing directly to the leadtek devices after opening the patch results in a clean image everytime. Only the winTV card shows a distorted image on the first try and then works on the second send.
3. the winTV works at 640x480 but I can only get 320x240 out of the leadtek cards, even though these do support 640x480 and I can capture images at the resolution directly from the device using vgrabbj, mplayer and xawtv also show the video at proper 640x480 resolution.
For this project I don't need to change the device on the fly, but those bugs are really ugly and make it hard to tell what is going on.
The most important thing for me is to be able to get the leadtek's at 640x480 resolution. Setting the card to 640x480 gives sucks up the whole CPU and prints many "VIDEOCMCAPTURE1: invalid argument" and "VIDEOCMCAPTURE2: invalid argument" messages.
Help!.
b.
IOhannes m zmoelnig wrote:
B. Bogart wrote:
Hey all,
So my pthread crash was solved by changing to a self compiled 2.6.13 kernel with ck patches applied.
now that is weird again. i was pretty sure that it was not the threading that caused the problems after our session yesterday. (probably the cx88xx-driver has got some fixes in 2.6.13 ?)
anyhow, great it seems to finally work
mfg.asdr. IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev