Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
The only way I could find to free a device, that was in use by [pix_video] was to shut down Pd. Is there a more elegant way?
Roman
Roman Haefeli escribió:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
Doesn't a "close" message work? Which operating system are you testing with? It seems to work here in Windows.
However, I noticed that the 1/0 float message to enable and disable [pix_video], which works fine for me in Windows, doesn't work and isn't even recognized in Mac OS (gives a "no method for float" error), so the same may be true for the "open" and "close" messages... ¿?
On Fri, 2010-05-14 at 20:21 +0200, Matteo Sisti Sette wrote:
Roman Haefeli escribió:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
Doesn't a "close" message work? Which operating system are you testing with? It seems to work here in Windows.
Linux / Ubuntu 10.04. Unfortunately, this doesn't work here.
However, I noticed that the 1/0 float message to enable and disable [pix_video], which works fine for me in Windows, doesn't work and isn't even recognized in Mac OS (gives a "no method for float" error), so the same may be true for the "open" and "close" messages... ¿?
Neither of those work on Linux.
Roman
you'll probably have to unload the module from the terminal with modprobe -r .... or something similar.
what camera is this?
J
On Fri, May 14, 2010 at 11:31 AM, Roman Haefeli reduzierer@yahoo.de wrote:
On Fri, 2010-05-14 at 20:21 +0200, Matteo Sisti Sette wrote:
Roman Haefeli escribió:
Hi all
I couldn't find method to free a device, that is used by [pix_video].
Is
it really missing or just not documented?
Doesn't a "close" message work? Which operating system are you testing
with?
It seems to work here in Windows.
Linux / Ubuntu 10.04. Unfortunately, this doesn't work here.
However, I noticed that the 1/0 float message to enable and disable [pix_video], which works fine for me in Windows, doesn't work and isn't even recognized in Mac OS (gives a "no method for float" error), so the same may be true for the "open" and "close" messages... ¿?
Neither of those work on Linux.
Roman
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2010-05-14 19:48, Roman Haefeli wrote:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
The only way I could find to free a device, that was in use by [pix_video] was to shut down Pd. Is there a more elegant way?
they should be closed at least when you delete the object or when you switch to another backend / device. i agree that "close" would be good to have.
you are using the svn-trunk, are you? currently, things might be a bit broken there...i hope to sort most issues out this week.
fgasdmr IOhannes
On Mon, 2010-05-17 at 09:16 +0200, IOhannes m zmoelnig wrote:
On 2010-05-14 19:48, Roman Haefeli wrote:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
they should be closed at least when you delete the object or when you switch to another backend / device.
Don't know why I haven't tried to switch device, but it works indeed. Thanks!
Roman
On 2010-05-17 10:12, Roman Haefeli wrote:
On Mon, 2010-05-17 at 09:16 +0200, IOhannes m zmoelnig wrote:
On 2010-05-14 19:48, Roman Haefeli wrote:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
they should be closed at least when you delete the object or when you switch to another backend / device.
Don't know why I haven't tried to switch device, but it works indeed.
probably because it smells like the hack it is.
i have added open/close messages to [pix_video] now.
btw, fw-capture (with camcorders) is starting to work again (the old backend was broken with the new juju stack on linux; if somebody wants to try the new videoDV4L2 backend with the old stack and confirm that it works, i will happily replace the old one...)
iidc should be next (have to wait for a cam)
fgmasdr IOhannes
On Mon, 2010-05-17 at 11:07 +0200, IOhannes m zmoelnig wrote:
i have added open/close messages to [pix_video] now.
Thanks, but the situation is worse here with snv r3302. I still can access the USB camera and when I do so, the red light turns on. Also does the close message work (the red LED goes off and the pix becomes all white), but then I cannot access the camera anymore at all, even not with the same [pix_video], altough the camera indicates, that it is not busy. Neither switching devices nor using the 'open' message helps. When switching the device to 1 and back to 0 and I start rendering then, I get:
GEM: Start rendering start: 1 -> 0 v4l2: VIDIOC_REQBUFS: Device or resource busy
It seems like Pd is still keeping the file /dev/video0 open:
roman@yoyo2:~$ lsof | grep /dev/video0 pd 9419 roman mem CHR 81,0 12422 /dev/video0 pd 9419 roman 6u CHR 81,0 0t0 12422 /dev/video0
I have to quit Pd in order to regain access to the camera.
btw, fw-capture (with camcorders) is starting to work again (the old backend was broken with the new juju stack on linux; if somebody wants to try the new videoDV4L2 backend with the old stack and confirm that it works, i will happily replace the old one...)
Oh, I hopefully be able to happily test that soon.
Roman
On 2010-05-19 01:33, Roman Haefeli wrote:
On Mon, 2010-05-17 at 11:07 +0200, IOhannes m zmoelnig wrote:
i have added open/close messages to [pix_video] now.
Thanks, but the situation is worse here with snv r3302. I still can
it only seems to be worse :-) things are changing (not so) rapidly in this part of the code.
access the USB camera and when I do so, the red light turns on. Also does the close message work (the red LED goes off and the pix becomes all white), but then I cannot access the camera anymore at all, even not with the same [pix_video], altough the camera indicates, that it is not busy. >
the device is correctly opened. but streaming has not yet started.
Neither switching devices nor using the 'open' message helps. When switching the device to 1 and back to 0 and I start rendering then, I get:
GEM: Start rendering start: 1 -> 0 v4l2: VIDIOC_REQBUFS: Device or resource busy
It seems like Pd is still keeping the file /dev/video0 open:
roman@yoyo2:~$ lsof | grep /dev/video0 pd 9419 roman mem CHR 81,0 12422 /dev/video0 pd 9419 roman 6u CHR 81,0 0t0 12422 /dev/video0
I have to quit Pd in order to regain access to the camera.
or just restart the rendering ([0, 1(->[gemwin]) or wait till it get's properly fixed....
btw, fw-capture (with camcorders) is starting to work again (the old backend was broken with the new juju stack on linux; if somebody wants to try the new videoDV4L2 backend with the old stack and confirm that it works, i will happily replace the old one...)
Oh, I hopefully be able to happily test that soon.
and the IIDC backend (aks "for ieee1394 cameras readable by coriander") gives me pictures as well :-) lots of work to do though
fgmasdr IOhannes
What do you mean by switching device?
Roman Haefeli escribió:
On Mon, 2010-05-17 at 09:16 +0200, IOhannes m zmoelnig wrote:
On 2010-05-14 19:48, Roman Haefeli wrote:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
they should be closed at least when you delete the object or when you switch to another backend / device.
Don't know why I haven't tried to switch device, but it works indeed. Thanks!
Roman
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Mon, 2010-05-17 at 11:39 +0200, Matteo Sisti Sette wrote:
What do you mean by switching device?
Let's say I am currently using 'device 0', I switch to 'device 1' in order to free 'device 0'.
Roman
Roman Haefeli escribió:
On Mon, 2010-05-17 at 09:16 +0200, IOhannes m zmoelnig wrote:
On 2010-05-14 19:48, Roman Haefeli wrote:
Hi all
I couldn't find method to free a device, that is used by [pix_video]. Is it really missing or just not documented?
they should be closed at least when you delete the object or when you switch to another backend / device.
Don't know why I haven't tried to switch device, but it works indeed. Thanks!
Roman
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
IOhannes m zmoelnig escribió:
On 2010-05-17 11:39, Matteo Sisti Sette wrote:
What do you mean by switching device?
sending a [device( message to [pix_video]
Oh I see. This is not documented in the Windows (DS) version, but it does work.
It seems identical to a "close <currentdevice>" and "open <newdevice>" messages, which only work in Windows.
I think all these differences between the interfaces of different implementations should be eliminated...
On 2010-05-17 12:25, Matteo Sisti Sette wrote:
IOhannes m zmoelnig escribió:
On 2010-05-17 11:39, Matteo Sisti Sette wrote:
What do you mean by switching device?
sending a [device( message to [pix_video]
Oh I see. This is not documented in the Windows (DS) version, but it does work.
the pix_videoDS shall go away asap.
fgmadr IOhannes
PS. and be replaced by a videoDS backend, thus making all the interface the same on all platforms.
IOhannes m zmoelnig escribió:
the pix_videoDS shall go away asap.
PS. and be replaced by a videoDS backend, thus making all the interface the same on all platforms.
And the common interface should probably be the one currently adopted by pix_videoDS which is superior to the one currently adopted by pix_video on Mac and Linux in that:
1) "open <ndevice>" and "close <ndevice>" is better than "device <ndevice>" since it allows you to close a device without opening another one 2) it accepts a float (1/0) to enable/disable pix_video, i.e. turn it on/off which is not the same as opening/closing the device
On 2010-05-17 13:12, Matteo Sisti Sette wrote:
IOhannes m zmoelnig escribió:
the pix_videoDS shall go away asap.
PS. and be replaced by a videoDS backend, thus making all the interface the same on all platforms.
And the common interface should probably be the one currently adopted by pix_videoDS which is superior to the one currently adopted by pix_video on Mac and Linux in that:
i'm not so aware of superiorness.
- "open <ndevice>" and "close <ndevice>" is better than "device
<ndevice>" since it allows you to close a device without opening another one
otoh, "close <ndevice>" is clearly faulty, as it allows you to close a device that is not even open... as written in before "i have added an open/close" message now for the new [pix_video] implementation, neither of which (currently) takes any arguments.
- it accepts a float (1/0) to enable/disable pix_video, i.e. turn it
on/off which is not the same as opening/closing the device
nevertheless, the exact naming of the methods is the least of my worries now. it's way more important to get videoDS work at all...
rtmas IOhannes
IOhannes m zmoelnig escribió:
And the common interface should probably be the one currently adopted by pix_videoDS which is superior to the one currently adopted by pix_video on Mac and Linux in that:
i'm not so aware of superiorness.
Well I meant it's a better interface (in my opinion) because of the advantages I mentioned.
- "open <ndevice>" and "close <ndevice>" is better than "device
<ndevice>" since it allows you to close a device without opening another one
otoh, "close <ndevice>" is clearly faulty, as it allows you to close a device that is not even open...
Yeah sorry, it is not "close <ndevice>" but "close" without arguments: it closes the currently open device. Of course you could send the message when no device is open, but that shoud simply generate an error message: the fact that an error can be generated doesn't mean that the interface is faulty. Even "device <ndevice>" (which is just equivalent to a "close" [if a device is open] followed by "open <ndevice>") may generate an error if you try to open a device that is not available because in use by another application or because it just doesn't exist (like "open 999")
as written in before "i have added an open/close" message now for the new [pix_video] implementation, neither of which (currently) takes any arguments.
I don't understand: what does a "open" message without argument mean? Which device does it open? Or is it equivalent to pix_videoDS's float (enable/disable) method??
- it accepts a float (1/0) to enable/disable pix_video, i.e. turn it
on/off which is not the same as opening/closing the device
nevertheless, the exact naming of the methods is the least of my worries now.
Nor do I worry about names; the relevant thing is that pix_videoDS has (A) methods to open/close a device and (B) a method to turn the object on and off, i.e. start/stop generating the output. Whatever you call them, A and B are not the same thing and it's useful to have both.
-
IOhannes m zmoelnig -
Jaime Oliver -
Matteo Sisti Sette -
Roman Haefeli