On Mon, 4 Aug 2003, Gerd Knorr wrote: >That is a very bad. You have double-buffering implemented, but >instead of letting the applications control it via CAPTURE + SYNC >ioctls you hide it. If the cost is 396 kilobytes of wasted memory, I'll rather let the driver control double buffering itself than the applications. >What does trigger a frame capture within your driver? CAPTURE ioctl? Either VIDIOCSYNC or read(), whichever comes first. After that I'll keep the camera streaming constantly until close(). (not exactly good if application captures a frame only rarely, but I'll implement later a timeout that disables streaming if nobody is capturing frames). >It should work that way. But I suspect it doesn't, otherwise the >"internal double buffering" wouldn't work as described ... Correct, but it would be easy to start streaming at VIDIOCMCAPTURE instead of VIDIOCSYNC, but I don't see much point in that... so I haven't bothered. >The "waste of memory" argument isn't true too. With multiple buffers >applications can let the hardware fill buffers and process (other) >buffers in parallel. It works just fine with this single mmap-buffer too (remember that there are multiple invisible buffers that are filled by hardware...or actually by USB interrupt handler). > I guess xawtv works, but prints plenty of >"waiting for a free buffer" messages. That indicates xawtv would >perform better with more buffers. No, not at all. Works fine at full frame rate (15 fps) right now. No dropped frames. With a single mmap buffer.
