2011/11/15 tim vets <[email protected]> > > > 2011/11/15 Matthias Kronlachner <[email protected]> > >> hi! >> >> Am 14.11.11 19:19, schrieb tim vets: >> >> >> >> 2011/11/14 Budi Prakosa <[email protected]> >> >>> 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? >> >> gem v0.93 is needed! >> but there is a binary available now anyway so you don't have to get >> yourself in trouble compiling it for osx on your own. >> >> there was a problem with the path settings in the dylibs. try it again, i >> hope it's working now. >> >> > Has the Linux version been updated as well? > trying the binary from > http://www.matthiaskronlachner.com/wp-content/uploads/2011/11/pix_freenect_0.03.zip > with the following setup now: > GEM ver: 0.93.3 > compiled: Nov 11 2011 > 0.43.1-extended-20111114 > Ubuntu 11.04 (so not 11.10, problem?) > > /usr/lib/pd-extended/extra/pix_freenect.pd_linux: can't load library > > gr, > Tim > > tried to roll my own, I now have: ./pix_freenect.pd_linux: ./pix_freenect.pd_linux: undefined symbol: freenect_stop_audio pix_freenect: can't load library /usr/lib/pd-extended/extra/pix_freenect.pd_linux: can't load library
> 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." >> >> yes, audio is being worked on by the libfreenect team, but in the latest >> version from git it is included and ready for use. >> i didn't have enough time to test audio under osx so it won't be included >> when building pix_freenect for osx. (it was quite unstable when i tried it) >> now it won't search for libfreenect-audio.h while compiling for osx. >> >> for audio i think i will divide the external into two anyway. >> one for video, one for audio. i will have to check it out if it's working >> simultaneously for one kinect then. >> >> matthias >> >> gr, >> Tim >> >> On Mon, Nov 14, 2011 at 10:53 PM, Mathieu Bouchard <[email protected]> >>> 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 >>> > _______________________________________________ >>> > [email protected] 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 >>> >> >> >> >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
