Thread: [libdc1394-devel] dc1394_cleanup_iso_channels_and_bandwidth
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Rudi L. <r.l...@x-...> - 2006-11-29 12:18:16
|
This function works fine under linux, but under Mac OSX it just returns = an error. Looking into the implementation I discovered, that this function is = programmed to return DC1394_FAILURE regardless of the system condition. I would like to use this function (under linux and Mac OSX) in order so = solve=20 the following problem: - I have a program which captures a given number of frames - I interrupt this program with ^C - I can not restart the program because the ISO transfer is still active - In order to make this program start again in linux, I'd have to unplug = the camera or use dc1394_cleanup_iso_channels_and_bandwidth. - Using Mac OSX, the camera starts again without complaint One option would be of course to call this function and ignore the = result, but under linux this doesn't sound like a good idea ... Since the comments in the header file indicate general unhappiness with = this=20 function, I'm afraid it may disappear alltogether. Will there be an = alternative solution to my original problem ? Cheers Rudi |
From: Alvin <alv...@gm...> - 2006-12-20 16:58:24
|
Hello, I removed my call to dc1394_cleanup_iso_channels_and_bandwidth() as suggested by this list. But, now, every 3rd or 4th attempt to use the camera fails with a message similar to "unable to allocate bandwidth". The 3 or 4 times it takes for this to occur makes sense because my Basler A601f camera uses about 30% of the bandwidth. The only workaround is to disconnect the camera and plug it back in. After I do that, it takes another 3 or 4 times for that error message to appear. This error message occurs not because of a segfault, I cleaning exit the app. I have made sure that caputring is stopped, that transmittion has stopped (while-loop check as in the examples) and that dc1394_free_camera() is called. Is there something else I could do, using libdc1394 or libraw1394, to make sure that the resources have been released? Thanks, Alvin |
From: Jon S. <jon...@ho...> - 2006-12-20 17:08:32
|
Here's the cleanup function that I'm using and seems to work rather well: /* helper functions */ void cleanup(void) { raw1394handle_t handle = raw1394_new_handle (); logger(LOG_DEBUG, "CAMERA", "Cleaning up"); for (int i=0; i < numCameras; i++) { // cleanup the dc1394 resources dc1394_capture_stop(cameras[i]); dc1394_video_set_transmission(cameras[i], DC1394_OFF); // free up the raw1394 resources if (raw1394_set_port (handle, cameras[i]->port) < 0) { logger(LOG_ERROR, "CAMERA", "Failed to set port to %d", i); } else { for (int j = 0; j < 64; j++) { raw1394_channel_modify (handle, j, RAW1394_MODIFY_FREE); } raw1394_bandwidth_modify (handle, MAXIMUM_BANDWIDTH, RAW1394_MODIFY_FREE); } raw1394_destroy_handle (handle); } } On Wed, 2006-12-20 at 12:58 -0400, Alvin wrote: > Hello, > > I removed my call to dc1394_cleanup_iso_channels_and_bandwidth() as suggested > by this list. > > But, now, every 3rd or 4th attempt to use the camera fails with a message > similar to "unable to allocate bandwidth". The 3 or 4 times it takes for this > to occur makes sense because my Basler A601f camera uses about 30% of the > bandwidth. > > The only workaround is to disconnect the camera and plug it back in. After I > do that, it takes another 3 or 4 times for that error message to appear. > > This error message occurs not because of a segfault, I cleaning exit the app. > I have made sure that caputring is stopped, that transmittion has stopped > (while-loop check as in the examples) and that dc1394_free_camera() is > called. > > Is there something else I could do, using libdc1394 or libraw1394, to make > sure that the resources have been released? > > Thanks, > > Alvin > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel ________________________________________________________________________ http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers |
From: Alvin <alv...@gm...> - 2006-12-20 17:15:17
|
On Wednesday 20 December 2006 13:07, Jon Schewe wrote: > Here's the cleanup function that I'm using and seems to work rather > well: > /* helper functions */ > void cleanup(void) { > raw1394handle_t handle = raw1394_new_handle (); > logger(LOG_DEBUG, "CAMERA", "Cleaning up"); > for (int i=0; i < numCameras; i++) { > // cleanup the dc1394 resources > dc1394_capture_stop(cameras[i]); > dc1394_video_set_transmission(cameras[i], DC1394_OFF); > > // free up the raw1394 resources > if (raw1394_set_port (handle, cameras[i]->port) < 0) { > logger(LOG_ERROR, "CAMERA", "Failed to set port to %d", i); > } else { > for (int j = 0; j < 64; j++) { > raw1394_channel_modify (handle, j, RAW1394_MODIFY_FREE); > } > raw1394_bandwidth_modify (handle, MAXIMUM_BANDWIDTH, > RAW1394_MODIFY_FREE); > } > raw1394_destroy_handle (handle); > > } > } Thank you Jon. Do the raw1394_ calls effect the other devices on the firewire bus? Alvin |
From: Jon S. <jon...@ho...> - 2006-12-20 17:28:44
|
On Wed, 2006-12-20 at 13:15 -0400, Alvin wrote: > On Wednesday 20 December 2006 13:07, Jon Schewe wrote: > > Here's the cleanup function that I'm using and seems to work rather > > well: > > /* helper functions */ > > void cleanup(void) { > > raw1394handle_t handle = raw1394_new_handle (); > > logger(LOG_DEBUG, "CAMERA", "Cleaning up"); > > for (int i=0; i < numCameras; i++) { > > // cleanup the dc1394 resources > > dc1394_capture_stop(cameras[i]); > > dc1394_video_set_transmission(cameras[i], DC1394_OFF); > > > > // free up the raw1394 resources > > if (raw1394_set_port (handle, cameras[i]->port) < 0) { > > logger(LOG_ERROR, "CAMERA", "Failed to set port to %d", i); > > } else { > > for (int j = 0; j < 64; j++) { > > raw1394_channel_modify (handle, j, RAW1394_MODIFY_FREE); > > } > > raw1394_bandwidth_modify (handle, MAXIMUM_BANDWIDTH, > > RAW1394_MODIFY_FREE); > > } > > raw1394_destroy_handle (handle); > > > > } > > } > > Thank you Jon. Do the raw1394_ calls effect the other devices on the firewire > bus? > They shouldn't, I haven't tested it with much else on the bus. Note that I'm only calling the raw1394 methods with handles from the cameras, so nothing else should be bothered. ________________________________________________________________________ http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers |
From: Alvin <alv...@gm...> - 2006-12-20 17:42:22
|
On Wednesday 20 December 2006 13:07, Jon Schewe wrote: > Here's the cleanup function that I'm using and seems to work rather > well: > /* helper functions */ > void cleanup(void) { > raw1394handle_t handle = raw1394_new_handle (); > logger(LOG_DEBUG, "CAMERA", "Cleaning up"); > for (int i=0; i < numCameras; i++) { > // cleanup the dc1394 resources > dc1394_capture_stop(cameras[i]); > dc1394_video_set_transmission(cameras[i], DC1394_OFF); > > // free up the raw1394 resources > if (raw1394_set_port (handle, cameras[i]->port) < 0) { > logger(LOG_ERROR, "CAMERA", "Failed to set port to %d", i); > } else { > for (int j = 0; j < 64; j++) { > raw1394_channel_modify (handle, j, RAW1394_MODIFY_FREE); > } > raw1394_bandwidth_modify (handle, MAXIMUM_BANDWIDTH, > RAW1394_MODIFY_FREE); > } > raw1394_destroy_handle (handle); > > } > } > Hi Jon. I took a look at the source code for dc1394_cleanup_iso_channels_and_bandwidth() and it appears what you do above is the same thing? The only difference that I can see is that you create a new raw1394 handle from the camera's port. Does this mean that the raw1394_ function calls are directed at that camera only? Thanks, Alvin |
From: Jon S. <jon...@ho...> - 2006-12-20 19:14:33
|
On Wed, 2006-12-20 at 13:32 -0400, Alvin wrote: > On Wednesday 20 December 2006 13:07, Jon Schewe wrote: > > Here's the cleanup function that I'm using and seems to work rather > > well: > > /* helper functions */ > > void cleanup(void) { > > raw1394handle_t handle = raw1394_new_handle (); > > logger(LOG_DEBUG, "CAMERA", "Cleaning up"); > > for (int i=0; i < numCameras; i++) { > > // cleanup the dc1394 resources > > dc1394_capture_stop(cameras[i]); > > dc1394_video_set_transmission(cameras[i], DC1394_OFF); > > > > // free up the raw1394 resources > > if (raw1394_set_port (handle, cameras[i]->port) < 0) { > > logger(LOG_ERROR, "CAMERA", "Failed to set port to %d", i); > > } else { > > for (int j = 0; j < 64; j++) { > > raw1394_channel_modify (handle, j, RAW1394_MODIFY_FREE); > > } > > raw1394_bandwidth_modify (handle, MAXIMUM_BANDWIDTH, > > RAW1394_MODIFY_FREE); > > } > > raw1394_destroy_handle (handle); > > > > } > > } > > > > Hi Jon. I took a look at the source code for > dc1394_cleanup_iso_channels_and_bandwidth() and it appears what you do above > is the same thing? The only difference that I can see is that you create a > new raw1394 handle from the camera's port. Does this mean that the raw1394_ > function calls are directed at that camera only? This should be pretty much the same as the API function, however I'm only making the calls on the things on the bus that I want to talk to. If I remember correctly the API function resets everything on the bus. ________________________________________________________________________ http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers |
From: David M. <dcm@MIT.EDU> - 2006-12-20 23:33:16
|
A few things: 1. If you call dc1394_video_set_transmission(cameras[i], DC1394_OFF) before you call dc1394_capture_stop(), the bandwidth and channel should be freed automatically, and you should not need to call any raw1394_* functions. 2. The raw1394_* code you've got here will in fact free all iso bandwidth related to all devices on the bus, not just the one camera. In fact, it will do that numCameras times. This is because "Port" refers to the firewire controller on your machine, not a specific device. 3. Admittedly, this kind of code is difficult and error prone to write. libdc1394 should be producing ample warnings if functions are called in the wrong order. It shouldn't be this complicated. See my next email. -David On Wed, 2006-12-20 at 11:07 -0600, Jon Schewe wrote: > Here's the cleanup function that I'm using and seems to work rather > well: > /* helper functions */ > void cleanup(void) { > raw1394handle_t handle = raw1394_new_handle (); > logger(LOG_DEBUG, "CAMERA", "Cleaning up"); > for (int i=0; i < numCameras; i++) { > // cleanup the dc1394 resources > dc1394_capture_stop(cameras[i]); > dc1394_video_set_transmission(cameras[i], DC1394_OFF); > > // free up the raw1394 resources > if (raw1394_set_port (handle, cameras[i]->port) < 0) { > logger(LOG_ERROR, "CAMERA", "Failed to set port to %d", i); > } else { > for (int j = 0; j < 64; j++) { > raw1394_channel_modify (handle, j, RAW1394_MODIFY_FREE); > } > raw1394_bandwidth_modify (handle, MAXIMUM_BANDWIDTH, > RAW1394_MODIFY_FREE); > } > raw1394_destroy_handle (handle); > > } > } > > > On Wed, 2006-12-20 at 12:58 -0400, Alvin wrote: > > Hello, > > > > I removed my call to dc1394_cleanup_iso_channels_and_bandwidth() as suggested > > by this list. > > > > But, now, every 3rd or 4th attempt to use the camera fails with a message > > similar to "unable to allocate bandwidth". The 3 or 4 times it takes for this > > to occur makes sense because my Basler A601f camera uses about 30% of the > > bandwidth. > > > > The only workaround is to disconnect the camera and plug it back in. After I > > do that, it takes another 3 or 4 times for that error message to appear. > > > > This error message occurs not because of a segfault, I cleaning exit the app. > > I have made sure that caputring is stopped, that transmittion has stopped > > (while-loop check as in the examples) and that dc1394_free_camera() is > > called. > > > > Is there something else I could do, using libdc1394 or libraw1394, to make > > sure that the resources have been released? > > > > Thanks, > > > > Alvin > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Mailing list for libdc1394-devel > > lib...@li... > > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel > > ________________________________________________________________________ > http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] > *My views may not represent those of my employers > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: Alvin <alv...@gm...> - 2006-12-21 00:31:39
|
On Wednesday 20 December 2006 19:27, David Moore wrote: > 1. If you call dc1394_video_set_transmission(cameras[i], DC1394_OFF) > before you call dc1394_capture_stop(), the bandwidth and channel should > be freed automatically, and you should not need to call any raw1394_* > functions That's what I must be doing wrong then. I've been calling dc1394_capture_stop() before I call dc1394_video_set_transmission(camera, DC1394_OFF) as in the grab_gray_image_dna.c::cleanup_and_exit(). I don't have access to the camera right now, but I'll make the flip in the morning. Also, as with DC1394_ON, I do a while-loop around dc1394_video_set_transmission() to ensure that the camera has stopped transmitting. Is that necessary? Is it safe to assume that the camera will stop at the first call? Alvin |
From: David M. <dcm@MIT.EDU> - 2006-12-21 01:21:33
|
On Wed, 2006-12-20 at 20:31 -0400, Alvin wrote: > Also, as with DC1394_ON, I do a while-loop around > dc1394_video_set_transmission() to ensure that the camera has stopped > transmitting. Is that necessary? Is it safe to assume that the camera will > stop at the first call? > It should stop with only one call, but a few frames might still be captured between the call to stop transmission and the call to stop capture. Technically, it may not be safe to stop capture until these frames have flushed out. This is another thing that I think needs to be clarified/improved about the current API. I also want to thoroughly test the behavior when a device is unplugged from the bus, either the current camera, or any other device. I'm not sure that behavior is under control yet. -David |
From: Jon S. <jon...@ho...> - 2006-12-21 14:43:11
|
On Wed, 2006-12-20 at 18:27 -0500, David Moore wrote: > A few things: > > 1. If you call dc1394_video_set_transmission(cameras[i], DC1394_OFF) > before you call dc1394_capture_stop(), the bandwidth and channel should > be freed automatically, and you should not need to call any raw1394_* > functions. I started with just those two calls and found that didn't work, so I added the raw1394 functions and that worked. Perhaps that happened because I called them in the wrong order? I changed the order and removed the calls to the ra1394 routines and now it works! > 2. The raw1394_* code you've got here will in fact free all iso > bandwidth related to all devices on the bus, not just the one camera. > In fact, it will do that numCameras times. This is because "Port" > refers to the firewire controller on your machine, not a specific > device. Oh, that's not good then. So does each camera have a channel on a port then? If that's the case then just using the right channel should fix it. ________________________________________________________________________ http://lug.htc.honeywell.com/people/jschewe [Honeywell Intranet Only] *My views may not represent those of my employers |
From: Alvin <alv...@gm...> - 2006-12-21 14:51:27
|
On Thursday 21 December 2006 10:43, Jon Schewe wrote: > On Wed, 2006-12-20 at 18:27 -0500, David Moore wrote: > > A few things: > > > > 1. If you call dc1394_video_set_transmission(cameras[i], DC1394_OFF) > > before you call dc1394_capture_stop(), the bandwidth and channel should > > be freed automatically, and you should not need to call any raw1394_* > > functions. > > I started with just those two calls and found that didn't work, so I > added the raw1394 functions and that worked. Perhaps that happened > because I called them in the wrong order? I changed the order and > removed the calls to the ra1394 routines and now it works! Same here. I changed the order and now my recovery routine does not get called (which is a good thing ;) ). grab_gray_image_dma.c::cleanup_and_exit() should be updated to reflect this calling order. Alvin |
From: Damien D. <ddo...@is...> - 2007-02-01 08:06:20
|
On Thu, 2006-12-21 at 10:51 -0400, Alvin wrote: > On Thursday 21 December 2006 10:43, Jon Schewe wrote: > > On Wed, 2006-12-20 at 18:27 -0500, David Moore wrote: > > > A few things: > > > > > > 1. If you call dc1394_video_set_transmission(cameras[i], DC1394_OFF= ) > > > before you call dc1394_capture_stop(), the bandwidth and channel sh= ould > > > be freed automatically, and you should not need to call any raw1394= _* > > > functions. > > > > I started with just those two calls and found that didn't work, so I > > added the raw1394 functions and that worked. Perhaps that happened > > because I called them in the wrong order? I changed the order and > > removed the calls to the ra1394 routines and now it works! >=20 > Same here. I changed the order and now my recovery routine does not get= called=20 > (which is a good thing ;) ). grab_gray_image_dma.c::cleanup_and_exit() = should=20 > be updated to reflect this calling order. The examples have been updated (SVN 369). Damien --=20 _ Damien =E9=AB=98=E5=8E=9F Douxchamps, PhD ('- Post-doctoral investigator //\ Image Processing Group, NAIST V_/_ http://damien.douxchamps.net/ |
From: Damien D. <da...@do...> - 2007-02-01 09:35:58
|
On Thu, 2006-12-21 at 10:51 -0400, Alvin wrote: > On Thursday 21 December 2006 10:43, Jon Schewe wrote: > > On Wed, 2006-12-20 at 18:27 -0500, David Moore wrote: > > > A few things: > > > > > > 1. If you call dc1394_video_set_transmission(cameras[i], DC1394_OFF) > > > before you call dc1394_capture_stop(), the bandwidth and channel should > > > be freed automatically, and you should not need to call any raw1394_* > > > functions. > > > > I started with just those two calls and found that didn't work, so I > > added the raw1394 functions and that worked. Perhaps that happened > > because I called them in the wrong order? I changed the order and > > removed the calls to the ra1394 routines and now it works! > > Same here. I changed the order and now my recovery routine does not get called > (which is a good thing ;) ). grab_gray_image_dma.c::cleanup_and_exit() should > be updated to reflect this calling order. The examples have been updated (SVN 369). Damien -- _ Damien 高原 Douxchamps, PhD ('- Post-doctoral investigator //\ Image Processing Group, NAIST V_/_ http://damien.douxchamps.net/ |
From: Damien D. <da...@do...> - 2006-12-04 08:14:36
|
On Wed, 2006-11-29 at 13:18 +0100, Rudi Leitgeb wrote: > > This function works fine under linux, but under Mac OSX it just > returns an error. > Looking into the implementation I discovered, that this function is > programmed > to return DC1394_FAILURE regardless of the system condition. I may be wrong but I think it should return DC1394_SUCCESS instead. This function should normally NOT be called because everything is nicely taken care of by the guts of OSX. But calling it should not hurt either. David, what do you think? > I would like to use this function (under linux and Mac OSX) in order > so solve > the following problem: > > - I have a program which captures a given number of frames > - I interrupt this program with ^C > - I can not restart the program because the ISO transfer is still > active > - In order to make this program start again in linux, I'd have to > unplug the camera > or use dc1394_cleanup_iso_channels_and_bandwidth. > - Using Mac OSX, the camera starts again without complaint The proper solution is external to libdc1394: you should setup an event on the CTRL-C interrupt. You can then run any cleanup function you want after the user has CTRL-C'ed your program. Sorry, I forgot how to do this ;( Damien -- _ Damien 高原 Douxchamps, PhD ('- Post-doctoral investigator //\ Image Processing Group, NAIST V_/_ http://damien.douxchamps.net/ |
From: David M. <dcm@MIT.EDU> - 2006-12-05 01:34:01
|
On Mon, 2006-12-04 at 17:15 +0900, Damien Douxchamps wrote: > On Wed, 2006-11-29 at 13:18 +0100, Rudi Leitgeb wrote: > > > > This function works fine under linux, but under Mac OSX it just > > returns an error. > > Looking into the implementation I discovered, that this function is > > programmed > > to return DC1394_FAILURE regardless of the system condition. > > I may be wrong but I think it should return DC1394_SUCCESS instead. This > function should normally NOT be called because everything is nicely > taken care of by the guts of OSX. But calling it should not hurt either. > > David, what do you think? > If anything, I think this function should be no longer public at all. If you want to forcefully free bandwidth allocations, you can do it using libraw1394 directly, with the understanding that it's not a portable solution to the problem. On Mac OS X, the user must rely on the OS to handle allocation/deallocation on their behalf, and thus there is no portable way for us to expose the capability in libdc1394. I think forcing a bus reset might also cause everything to be freed, but I haven't tried that. -David |