[PD] fux_kinect

[tim vets]

2011/11/14 Budi Prakosa <iyok at 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 <matju at 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 ----- Montréal, QC
> > _______________________________________________
> > Pd-list at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111114/b29c6755/attachment.htm>