[PD] fux_kinect

[tim vets]

2011/11/15 tim vets <timvets at gmail.com>

>
>
> 2011/11/15 Matthias Kronlachner <m.kronlachner at student.tugraz.at>
>
>>  hi!
>>
>> Am 14.11.11 19:19, schrieb 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?
>>
>> 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 <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
>>>
>>
>>
>>
>> _______________________________________________Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111115/9090682a/attachment-0001.htm>