[libdc1394-devel] Re: HANG on dc1394_dma_multi_capture
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Andrew H. <ho...@cs...> - 2002-07-22 16:44:15
|
Hi again, Okay so it works now... the magic is the attempt_root=1 flag when insmod'ing the module... pfewwww.... :) I have another question though... what is the significance of the number of dma buffers that you initialize the camera with? I've noticed that if I change this number sometimes nothing works and then I increase it and it works but there is a huge delay... am I right to think that there is a buffer of images that you are storing somewhere of this size so you can get the most recent image? If so, where is it stored? Is it stored in main memory or on the hard disk... right now, I have a large delay occurring with 3 dma buffers but nothing works if I make this smaller... I've also noticed that the harddrive is thrashing around and it sounds like its paging quite a lot which will decrease the performance and thus the framerate... Thanks for all your help, -- Andrew On 21 Jul 2002, Dan Dennedy wrote: > On Sun, 2002-07-21 at 02:24, Andrew Hogue wrote: > > Hi Dan, > > > > > wrote a little program that displays multiple camera images in an Xv > > > window. I will committ it soon to the libdc1394 cvs. I have successfully > > > been testing 2 cameras on one card, and I have not seen any problem yet. > > > I have an extra card I will install this weekend and test multicapture > > > across multiple cameras on multiple cards too. > > > > Yeah on the 2.4.18 kernel, I had multiple cameras on one card but for some > > reason it didn't like multiple cards.... so I upgraded to 2.4.19-rc1 and > > nothing worked... so I patched it with the latest 2.4.19-rc2 patch and at > > least I could initialize all of the cameras on all of the cards... > > hmm.. was there an ieee1394 update between rc1 and rc2? would be good to > know for supporting users. > > > > So, you are saying you can't get any image from just one camera? > > > Are you using devfs or did you change /dev/video1394/x to use the new > > > major/minor numbers? > > > mknod /dev/video1394/0 c 171 16 > > > mknod /dev/video1394/1 c 171 17 > > > mknod /dev/video1394/2 c 171 18 > > > > Yup, I'm using the major/minor numbers and the proper devices to talk to > > the camera... like I said I am able to talk to all of the cameras, i.e. > > tell them to initialize the dma capturing and start the iso > > transmission... but the dma_multi_capture function just hangs.... > > The root node must be cycle master. I assume you have tried the > attempt_root=1 ohci1394 module param? > > > I can't get any images from even just one camera connected to the > > system... strange... I even use the code that I know works on the 2.4.18 > > kernel and tell it to initialize on the proper /dev/video1394/video[0,1,2] > > port and it initializes but hangs when trying to get an image from it... > > Make sure you specify dma_device_file correctly. Are you really naming > your device files as /dev/video1394/video[0,1,2]?? If so, then you MUST > supply the proper dma_device_file with each call to > dc1394_dma_setup_capture() because that is not the expected naming > convention. If you pass NULL for dma_device_file to > dc1394_dma_setup_capture(), then it assumes the standard, default > video1394 naming convention of simply /dev/video1394/[0,1,2]. Why is > this the standard? Because that is the name video1394 creates under > devfs. > > Finally, I have successfully tested 2 cameras on one port, and 2 cameras > on 2 ports (one cam per port). I wrote a test program that I committed > to CVS just now called examples/dc394_multiview. It requires Xv,and it > simply stacks each camera's image vertically. For as many cameras you > are using, it makes sense to tile the images, but then you need to > alternate each row of each image when going horizontal. I tried > initially using multiple Xv windows, each with a different chroma_key > color, but I could not get that to work smoothly. > > +-DRD-+ > > > |