2011/11/14 Budi Prakosa <iy...@deadmediafm.org <mailto:iy...@deadmediafm.org>>

hi tim, have you try the latest version of pix_freenect by matthias?

Hi Budi and list, I tried pix_freenect.pd_linux, but unfortunately: "pix_freenect: can't load library" No idea why... I'm running GEM: ver: 0.92.3. Is v0.93 a requirement maybe?

I also tried compiling pix_freenect myself, but got stuck at: "In file included from pix_freenect.cc:23:0: pix_freenect.h:38:31: fatal error: libfreenect-audio.h: No such file or directory compilation terminated." pix_freenect readme says: "get and install latest libfreenect from https://github.com/OpenKinect/libfreenect (compile with Audio support!)" libfreenect readme says: "Audio is currently being worked on."

gr, Tim

On Mon, Nov 14, 2011 at 10:53 PM, Mathieu Bouchard <mat...@artengine.ca <mailto:mat...@artengine.ca>> wrote: > Le 2011-11-14 à 14:44:00, tim vets a écrit : > >> Attached is the output of "valgrind --leak-check=full pdextended" and >> opening fux_kinect-help.pd. > > I think that you better not add --leak-check when just looking for a crash. > But the only problem it does, is make the log file bigger. > > Here's what I found (summarising the important error messages) : > > Invalid write of size 1 at convert_bayer_to_rgb (in libfreenect) by [...] by > libusb_handle_events_timeout (in libusb). Address 0xa066360 is [between 0 > and 5] bytes after a block of size 307,200 alloc'd > > This means that when libusb gives libfreenect the RGGB buffer and > libfreenect is converting it to plain RGB, it makes a mistake and writes 6 > bytes more than just 640*480 pixels, as if there were 2 extra pixels at the > end. But I think that this is a bit misleading. It looks as if Valgrind was > skipping a lot of other errors (probably by not able to detect them). Read > on. > > Then there is invalid write of size 1 from the same place but « Address is > 749 bytes inside a block of size 12,800 free'd ». This doesn't look like any > malloc that we know about. The number of bytes does not ring a bell either. > But then it says that the memory was freed by request of > /usr/lib/nvidia-current/libGL.so.270.41.06, which is a part of your video > driver. (???) > > But I just looked at how convert_bayer_to_rgb is written, and it doesn't > look like it writes to more than one buffer. This function only writes 480 > rows of 640 columns. But note that it writes RGB values, three bytes per > pixel. That means you need a malloc(640*480*3) for each of the three RGB > buffers in fux_kinect. > > ______________________________________________________________________ > | Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 <tel:%2B1.514.383.3801> ----- Montréal, QC > _______________________________________________ > Pd-l...@iem.at <mailto:Pd-l...@iem.at> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > >

-- Budi Prakosa house of natural fiber (HONF) yogyakarta new media art laboratory wora wari A80/6 baciro yogyakarta indonesia http://www.natural-fiber.com

_______________________________________________ Pd-l...@iem.at <mailto:Pd-l...@iem.at> mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list