From owner-freebsd-multimedia Sun Jan 28 04:12:48 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA25207 for multimedia-outgoing; Sun, 28 Jan 1996 04:12:48 -0800 (PST) Received: from uw-isdl.ee.washington.edu (uw-isdl.ee.washington.edu [128.95.205.64]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id EAA25187 Sun, 28 Jan 1996 04:12:42 -0800 (PST) Received: from myosin.ee.washington.edu (myosin.ee.washington.edu [128.95.205.35]) by uw-isdl.ee.washington.edu (8.7.1/8.7.1) with ESMTP id EAA13654; Sun, 28 Jan 1996 04:12:32 -0800 (PST) From: ChingPing Chou Received: (from ccp@localhost) by myosin.ee.washington.edu (8.7.1/8.7.1) id EAA24373; Sun, 28 Jan 1996 04:12:31 -0800 (PST) Date: Sun, 28 Jan 1996 04:12:31 -0800 (PST) Message-Id: <199601281212.EAA24373@myosin.ee.washington.edu> To: questions@freebsd.org, multimedia@freebsd.org Subject: Problems to configure IDE cdrom and sound card drivers. X-Sun-Charset: US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk Hi there, I tried to reconfig my kernel to include IDE cdrom and sound card drivers. So I edited MYKERNEL and recompile it followed the instructions described in the /usr/share/doc/FAQ/*.html and handbook.*.html. For the sound card: After I reboot the system, it seemed to detect it and showed "sb0 at 0x220 irq 9 drq 1 on isa" "sb0: " However, after booting, I could not find it by running 'lsdev'. When I did "sh MAKEDEV sb0", it responded "sb0 - no such device name". For the IDE controller: I have to mention that I ahve only a SCSI hard drive, and the IDE stuff never worked before. My IDE is an onboard EIDE. I copy the port address and irq# from Windows95's device manager. When I reboot the system, it stucked about 30 second before and after probing IDE controller and only showed "wdc0 at 0x1f0-0x1f7 irq 14 on isa" No cdrom was probed at all. 'lsdev' shows "wdc0 Unknown ST506/ESDI/IDE disk controller" Another thing I have to mention is that my onboard EIDE is on PCI bus, but if I change "at isa?" to "at pci?" in MYKERNEL, the linking would be failed with showing something like "xxx_wdc_xxx symble not found refered in text". Can anyone tell me what do I miss here? Thanks in advance. Ching-Ping From owner-freebsd-multimedia Sun Jan 28 16:52:51 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA15539 for multimedia-outgoing; Sun, 28 Jan 1996 16:52:51 -0800 (PST) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id QAA15529 Sun, 28 Jan 1996 16:52:40 -0800 (PST) Received: from msmith@localhost by genesis.atrad.adelaide.edu.au (8.6.12/8.6.9) id LAA08742; Mon, 29 Jan 1996 11:34:48 +1030 From: Michael Smith Message-Id: <199601290104.LAA08742@genesis.atrad.adelaide.edu.au> Subject: Re: Problems to configure IDE cdrom and sound card drivers. To: ccp@uw-isdl.ee.washington.edu (ChingPing Chou) Date: Mon, 29 Jan 1996 11:34:48 +1030 (CST) Cc: questions@FreeBSD.org, multimedia@FreeBSD.org In-Reply-To: <199601281212.EAA24373@myosin.ee.washington.edu> from "ChingPing Chou" at Jan 28, 96 04:12:31 am MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multimedia@FreeBSD.org Precedence: bulk ChingPing Chou stands accused of saying: > > Hi there, > > I tried to reconfig my kernel to include IDE cdrom and sound card drivers. > So I edited MYKERNEL and recompile it followed the instructions described in > the /usr/share/doc/FAQ/*.html and handbook.*.html. > > For the sound card: > > After I reboot the system, it seemed to detect it and showed > "sb0 at 0x220 irq 9 drq 1 on isa" > "sb0: " > However, after booting, I could not find it by running 'lsdev'. When I did > "sh MAKEDEV sb0", it responded "sb0 - no such device name". sb0 is a controller, other devices hang off it. Look at the LINT file for more details. > Can anyone tell me what do I miss here? Thanks in advance. Sorry, can't tell you about ATAPI cdroms; I have religious objections there. > Ching-Ping -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "wherever you go, there you are" - Buckaroo Banzai [[ From owner-freebsd-multimedia Mon Jan 29 02:19:50 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA19189 for multimedia-outgoing; Mon, 29 Jan 1996 02:19:50 -0800 (PST) Received: from beeblebrox.pccc.jyu.fi (beeblebrox.pccc.jyu.fi [130.234.41.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA19183 for ; Mon, 29 Jan 1996 02:19:43 -0800 (PST) Received: (from kallio@localhost) by beeblebrox.pccc.jyu.fi (8.6.12/8.6.12) id MAA05404; Mon, 29 Jan 1996 12:19:05 +0200 Date: Mon, 29 Jan 1996 12:19:05 +0200 (EET) From: Seppo Kallio To: multimedia@freebsd.org cc: multimedia@rah.star-gate.com Subject: AI Tech Wave Watcher TV-II supportted by FreeBSD? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk Do you know, if WaveWatcher TV-II is supported by FreeBSD, nv + vat Seppo From owner-freebsd-multimedia Mon Jan 29 02:39:44 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA20291 for multimedia-outgoing; Mon, 29 Jan 1996 02:39:44 -0800 (PST) Received: from beeblebrox.pccc.jyu.fi (beeblebrox.pccc.jyu.fi [130.234.41.34]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA20286 for ; Mon, 29 Jan 1996 02:39:41 -0800 (PST) Received: (from kallio@localhost) by beeblebrox.pccc.jyu.fi (8.6.12/8.6.12) id MAA05428; Mon, 29 Jan 1996 12:39:12 +0200 Date: Mon, 29 Jan 1996 12:39:10 +0200 (EET) From: Seppo Kallio To: multimedia@freebsd.org cc: multimedia@rah.star-gate.com Subject: Which video in cards supported by FreeBSD nv vat ? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk Which video in card are suppoerted by FreeBSD nv vat ... I think Video Spigot card is supported and Amancio Hasty mentions Matrox Meteor PCI Video Capture Board. Are there other alternatves? Is this a FAQ and is the answear somewhere ;-) ? I did find only this from FreeBSD mail archives: >From owner-freebsd-questions Tue Jun 13 07:47:39 1995 From: Mark Tinguely Message-Id: <199506131447.JAA22323@plains.nodak.edu> To: hackers@freebsd.org, questions@freebsd.org, sakr@itp.ac.ru Subject: Re: Videoconferences in FreeBSD ? Content-Length: 1809 Sender: questions-owner@freebsd.org Precedence: bulk > What cards for video input (from videocamera) does FreeBSD support now > (in 2.0.5-RELEASE) or will support in the near future (in 2.1-RELEASE, > for example) ? supported video capture cards: CORTEX-I Frame Grabber (monochrome, though I think the card is capiable of color if the color lookup table was programed differently) Video Spigot (*help* someone fill in the details) Matrox Comet/Marvel II (these are excellent boards simular to the Jazz Jakarta in features. Since Matrox only licenses their specs to these boards, you will need to get a commerical software (X Inside Inc has a commerical X for Matrox boards). related, but not for conferencing: OmniMedia Talisman (MPEG viewer) Cards people are interested in writing drivers: Jazz Jakarta (Amancio Hasty has expressed interested in writting a driver. I believe this is also a video card. I also believe this is a MPEG board. This board should be excellent for "live" video viewing). Matrox Meteor (Jim Lowe and I are interested in writting the Matrox Meteor drivers. This driver offer 16/24 bit packed RGB and 4-2-2 planar YUV output for conferencing tools suchas nv/ivs. Right now I am trying to get a better understanding of the PCI bus). --- Seppo From owner-freebsd-multimedia Sat Feb 3 02:09:28 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA17118 for multimedia-outgoing; Sat, 3 Feb 1996 02:09:28 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA17112 for ; Sat, 3 Feb 1996 02:09:24 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id CAA00405; Sat, 3 Feb 1996 02:07:43 -0800 (PST) Message-Id: <199602031007.CAA00405@precipice.shockwave.com> To: Sujal Patel cc: Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: real-world experience with QuickCam in the kernel In-reply-to: Your message of "Fri, 02 Feb 1996 15:21:45 EST." Date: Sat, 03 Feb 1996 02:07:40 -0800 From: Paul Traina Sender: owner-multimedia@freebsd.org Precedence: bulk [For those unaware, I wrote a QuickCam driver for FreeBSD yesterday based upon work done by Scott and Tom.] Sujal, You're going to love this. :-( I hacked up a copy of xfqcam tonight to work with my kernel driver. I found a couple of small bugs in my driver (no big deal), but I'm now convinced that without some serious head-scratching, doing this in kernel mode is a big lose. In fact, due to the extra copies and syscall overhead, I'm at least 5% slower than xfqcam. It looks like the QuickCam has no serious way of generating interrupts, and the spin loop synchronization locks up the system during transfers of a frame. This is unnoticeable while doing single frame captures, but completely sucks when doing movies. At this point, I think it's best if we could concentrate on documenting the protocol and working out an _optimized_ library and standard API for tools. By optimized, I mean that xfqcam's bit-shifting operations run significantly faster than the standard ones everyone else is using. Paul's code seems to run significantly faster, which is strange given that his stuff is less unwound, and I see at least a few speed fixups I could make over his stuff without much effort. I'm really unhappy and upset about this because one of my goals through doing this with the kernel is we would not require special privs for accessing I/O memory. Unless we can figure out a way to handle this without kernel threads or interrupt support comming back from the QuickCam, I think this may spell death for all kernel drivers (at least for motion use...). I'm going to bail for tonight and sleep on this. If someone has a good idea for avoiding spin-loops while in the kernel, I'm all ears. Maybe I'll have a better idea in the morning. Paul p.s. I haven't figured out why I'm having the left-column out of sync and flare-up bits when doing full-motion video when xfqcam works fine. I'm doing the same operations as Paul and I removed most of the delay's in sendcommand per his suggestion (actually, I think he was getting bit by dismissing too long between the write to the data port and the sync-read. I think the trick may be to implement a handshake for starting unidirectional transfers similar to the waitfor_bi code. I may do that tomorrow just as for grins. p.p.s. Tonight's changes (not production quality at all, just hacks) are available in the usual place. You may want to note my comments about differences between my stuff and Paul Chinn's. From owner-freebsd-multimedia Sat Feb 3 02:18:25 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA17751 for multimedia-outgoing; Sat, 3 Feb 1996 02:18:25 -0800 (PST) Received: from xi.dorm.umd.edu (xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id CAA17743 for ; Sat, 3 Feb 1996 02:18:21 -0800 (PST) Received: from xi.dorm.umd.edu (localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.3/8.6.12) with SMTP id FAA01146; Sat, 3 Feb 1996 05:18:08 -0500 (EST) Date: Sat, 3 Feb 1996 05:18:08 -0500 (EST) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Paul Traina cc: Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel In-Reply-To: <199602031007.CAA00405@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk On Sat, 3 Feb 1996, Paul Traina wrote: > I found a couple of small bugs in my driver (no big deal), but I'm > now convinced that without some serious head-scratching, doing this > in kernel mode is a big lose. In fact, due to the extra copies and > syscall overhead, I'm at least 5% slower than xfqcam. I guess that means I should go to sleep now? :-) This seems almost *inconceivable* that the driver could be slower :( > It looks like the QuickCam has no serious way of generating interrupts, > and the spin loop synchronization locks up the system during transfers of > a frame. This is unnoticeable while doing single frame captures, but > completely sucks when doing movies. Yeah, this really bites. If only they wired up the ACK line, and sent an interrupt when it was ready to send some data. > At this point, I think it's best if we could concentrate on documenting > the protocol and working out an _optimized_ library and standard API > for tools. By optimized, I mean that xfqcam's bit-shifting operations > run significantly faster than the standard ones everyone else is using. > Paul's code seems to run significantly faster, which is strange given > that his stuff is less unwound, and I see at least a few speed fixups > I could make over his stuff without much effort. Why not just write those scan routines in assembly... Seriously, it's not that much work, and you'll be absolutely sure that they are efficent. > I'm really unhappy and upset about this because one of my goals through > doing this with the kernel is we would not require special privs for > accessing I/O memory. Unless we can figure out a way to handle this > without kernel threads or interrupt support comming back from the QuickCam, > I think this may spell death for all kernel drivers (at least for motion > use...). I dunno-- 5% speed loss vs a clean interface.... It's a though call. > I'm going to bail for tonight and sleep on this. If someone has a good > idea for avoiding spin-loops while in the kernel, I'm all ears. Maybe > I'll have a better idea in the morning. I can't think of anything to avoid the loops.. You need to read the data from the QuickCam the INSTANT it offers it. Also-- For everyone: I finally got around to testing Bi-dir; Bi-directional modes are not working in any way (my code, xfqcam, and pst's driver). Any ideas? If not, I'll figure it out tommorow. Sujal From owner-freebsd-multimedia Sat Feb 3 02:41:22 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id CAA19220 for multimedia-outgoing; Sat, 3 Feb 1996 02:41:22 -0800 (PST) Received: from sasami.jurai.net (root@sasami.jurai.net [205.218.122.51]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id CAA19214 for ; Sat, 3 Feb 1996 02:41:17 -0800 (PST) Received: (from winter@localhost) by sasami.jurai.net (8.6.12/8.6.9) id EAA06127; Sat, 3 Feb 1996 04:41:13 -0600 Date: Sat, 3 Feb 1996 04:41:13 -0600 (CST) From: "Matthew N. Dodd" X-Sender: winter@sasami To: Sujal Patel cc: Paul Traina , Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk On Sat, 3 Feb 1996, Sujal Patel wrote: > > a frame. This is unnoticeable while doing single frame captures, but > > completely sucks when doing movies. > Yeah, this really bites. If only they wired up the ACK line, and sent an > interrupt when it was ready to send some data. Hell, get a few of the people on hackers to look at this, maybe they would add a framebuffer for the QC to their "FreeBSD gadget". :) Conceptually, it would look to be a straightforward hardware device. Have fun. | Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter | | Technical Manager | mdodd@intersurf.net | http://www.intersurf.net | | InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"| From owner-freebsd-multimedia Sat Feb 3 04:06:50 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id EAA23530 for multimedia-outgoing; Sat, 3 Feb 1996 04:06:50 -0800 (PST) Received: from hda.com (hda.com [199.232.40.182]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id EAA23518 for ; Sat, 3 Feb 1996 04:06:32 -0800 (PST) Received: (from dufault@localhost) by hda.com (8.6.11/8.6.9) id HAA08042 for multimedia@freebsd.org; Sat, 3 Feb 1996 07:08:59 -0500 From: Peter Dufault Message-Id: <199602031208.HAA08042@hda.com> Subject: Stupid sound question To: multimedia@freebsd.org Date: Sat, 3 Feb 1996 07:08:58 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-multimedia@freebsd.org Precedence: bulk Can I ask some stupid sound question? I don't see the sound man pages, plus I'd like someone who knows the system to sketch the right way to do this as I suspect there are many ways to skin this cat (sorry Jordan). I have a heavily loaded system calibrating some equipment. It continuously uploads data from these systems at 115200 over serial ports, monitors them, and sends back new data while running the units through test sequences. I'd now like to add sound support for when a problem crops up (a thermocouple opens, for example) or for when operator action is required (out with the old unit, in with a new). I'd like to download a set of sequences (only about 16) to a sound card RAM at system start up, and then if I ever want to send out one of these sequences just send a byte or two to the card. Essentially I don't mind doing any amount of work at system initialization but want to do zero work at run time. I realize I probably don't have to do it this way but like the design as it doesn't change system loading, and we aren't losing any input yet. These sounds will be either loops (alarms) that run continuously until stopped by operator action or a single sound alarm that would get played out once (unit in bay 2 is shut down and can be taken out). This will be mono, driving a single external amplified speaker (with external volume control), and cheaper is good given the requirements of the application but I'm not price sensitive for quality. Do we have an out-of-the-box solution for this? What hardware is recommended and what software? -- Peter Dufault Real-Time Machine Control and Simulation HD Associates, Inc. Voice: 508 433 6936 dufault@hda.com Fax: 508 433 5267 From owner-freebsd-multimedia Sat Feb 3 11:22:44 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22206 for multimedia-outgoing; Sat, 3 Feb 1996 11:22:44 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA22193 for ; Sat, 3 Feb 1996 11:22:41 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id LAA02828; Sat, 3 Feb 1996 11:21:02 -0800 (PST) Message-Id: <199602031921.LAA02828@precipice.shockwave.com> To: Sujal Patel cc: Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel In-reply-to: Your message of "Sat, 03 Feb 1996 05:18:08 EST." Date: Sat, 03 Feb 1996 11:21:02 -0800 From: Paul Traina Sender: owner-multimedia@freebsd.org Precedence: bulk From: Sujal Patel Subject: Re: real-world experience with QuickCam in the kernel On Sat, 3 Feb 1996, Paul Traina wrote: > I found a couple of small bugs in my driver (no big deal), but I'm > now convinced that without some serious head-scratching, doing this > in kernel mode is a big lose. In fact, due to the extra copies and > syscall overhead, I'm at least 5% slower than xfqcam. I guess that means I should go to sleep now? :-) This seems almost *inconceivable* that the driver could be slower :( Think about it, same I/O operations need to be done, and when you open /dev/io, you're doing them directly from user-mode. > It looks like the QuickCam has no serious way of generating interrupts, > and the spin loop synchronization locks up the system during transfers of > a frame. This is unnoticeable while doing single frame captures, but > completely sucks when doing movies. Yeah, this really bites. If only they wired up the ACK line, and sent an interrupt when it was ready to send some data. Even then, taking an interrupt per nibble would be ugly. > At this point, I think it's best if we could concentrate on documenting > the protocol and working out an _optimized_ library and standard API > for tools. By optimized, I mean that xfqcam's bit-shifting operations > run significantly faster than the standard ones everyone else is using. > Paul's code seems to run significantly faster, which is strange given > that his stuff is less unwound, and I see at least a few speed fixups > I could make over his stuff without much effort. Why not just write those scan routines in assembly... Seriously, it's not that much work, and you'll be absolutely sure that they are efficent. I was thinking that too, but before I drifted off to sleep, I realized that there's no need to put more effort into it. We can use "free" time during the spin loop to do the slow stuff. I bet if we unwound stuff a bit more, we could do our calcuations as slowly as we want. Watch: current proposed ------- -------- command 1 command 1 sync/wait 1 sync/wait 1 conversion ops 1 command 2 command 2 conversion ops 1 sync/wait 2 sync/wait 2 conversion ops 2 command 3 command 3 conversion ops 2 sync/wait 3 sync/wait 3 ... ... Since we're gated by the speed of the spin loop anyway, we may as well hit the "go" button as soon as possible and then do the stuff that's slow on the processor. You could probably code the shifts in LISP and it would still complete before the sync/wait completed. :-) > I'm really unhappy and upset about this because one of my goals through > doing this with the kernel is we would not require special privs for > accessing I/O memory. Unless we can figure out a way to handle this > without kernel threads or interrupt support comming back from the QuickCam, > I think this may spell death for all kernel drivers (at least for motion > use...). I dunno-- 5% speed loss vs a clean interface.... It's a though call. If it was just that, I'd be fine, but the machine is pretty much unusable when my modified xfqcam is running since we're doing spin-waits in the kernel. The cursor moves in jerky-bits. At least in user mode, other threads of execution get to run. > I'm going to bail for tonight and sleep on this. If someone has a good > idea for avoiding spin-loops while in the kernel, I'm all ears. Maybe > I'll have a better idea in the morning. I can't think of anything to avoid the loops.. You need to read the data from the QuickCam the INSTANT it offers it. Are you sure it's instant? I think we have several tens of microseconds of slack here, don't we? If not, then my proposal for reordering the xfer routines won't fly. Also-- For everyone: I finally got around to testing Bi-dir; Bi-directional modes are not working in any way (my code, xfqcam, and pst's driver). Any ideas? If not, I'll figure it out tommorow. I found a bug in my code comparing it to xfqcam, but I still haven't fixed my hardware to do bidir. Sujal From owner-freebsd-multimedia Sat Feb 3 11:28:37 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA22926 for multimedia-outgoing; Sat, 3 Feb 1996 11:28:37 -0800 (PST) Received: from xi.dorm.umd.edu (xi.dorm.umd.edu [129.2.152.45]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA22912 for ; Sat, 3 Feb 1996 11:28:28 -0800 (PST) Received: from xi.dorm.umd.edu (localhost [127.0.0.1]) by xi.dorm.umd.edu (8.7.3/8.6.12) with SMTP id OAA02482; Sat, 3 Feb 1996 14:28:19 -0500 (EST) Date: Sat, 3 Feb 1996 14:28:18 -0500 (EST) From: Sujal Patel X-Sender: smpatel@xi.dorm.umd.edu To: Paul Traina cc: Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel In-Reply-To: <199602031921.LAA02828@precipice.shockwave.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org Precedence: bulk On Sat, 3 Feb 1996, Paul Traina wrote: > Think about it, same I/O operations need to be done, and when you open > /dev/io, you're doing them directly from user-mode. Yea, but in user-mode you have to deal with other processes taking away our time slice. In FreeBSD, we can use rtprio-- But I dunno about what the Linux folks can do about this. > Even then, taking an interrupt per nibble would be ugly. The QuickCam would also need an onboard frame-buffer. Maybe signal when the whole frame was ready. But! Enough wishing :) > Since we're gated by the speed of the spin loop anyway, we may as well hit > the "go" button as soon as possible and then do the stuff that's slow on > the processor. You could probably code the shifts in LISP and it would > still complete before the sync/wait completed. :-) I was thinking of something along the same lines. But of course coding it in assembly never hurts so I thought, I'd throw it out. > Are you sure it's instant? I think we have several tens of microseconds of > slack here, don't we? If not, then my proposal for reordering the xfer > routines won't fly. The way I understand the QuickCam's operation: You need to read it as fast as possible? Or am I wrong on this point? > I found a bug in my code comparing it to xfqcam, but I still haven't fixed > my hardware to do bidir. I need to fix this myself- I think it's a subtle bug which exists in all of the bi-directional code (or maybe I just have funky hardware). Sujal From owner-freebsd-multimedia Sat Feb 3 11:36:58 1996 Return-Path: owner-multimedia Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA23474 for multimedia-outgoing; Sat, 3 Feb 1996 11:36:58 -0800 (PST) Received: from precipice.shockwave.com (precipice.shockwave.com [171.69.108.33]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id LAA23464 for ; Sat, 3 Feb 1996 11:36:54 -0800 (PST) Received: from localhost.shockwave.com (localhost.shockwave.com [127.0.0.1]) by precipice.shockwave.com (8.7.3/8.7.3) with SMTP id LAA02882; Sat, 3 Feb 1996 11:35:17 -0800 (PST) Message-Id: <199602031935.LAA02882@precipice.shockwave.com> To: Sujal Patel cc: Thomas Davis , multimedia@freebsd.org, linux-connectix@crynwr.com Subject: Re: real-world experience with QuickCam in the kernel In-reply-to: Your message of "Sat, 03 Feb 1996 14:28:18 EST." Date: Sat, 03 Feb 1996 11:35:17 -0800 From: Paul Traina Sender: owner-multimedia@freebsd.org Precedence: bulk From: Sujal Patel Subject: Re: real-world experience with QuickCam in the kernel On Sat, 3 Feb 1996, Paul Traina wrote: > Think about it, same I/O operations need to be done, and when you open > /dev/io, you're doing them directly from user-mode. Yea, but in user-mode you have to deal with other processes taking away our time slice. In FreeBSD, we can use rtprio-- But I dunno about what the Linux folks can do about this. This is a win, not a lose. Actually, we want them to take away our time slice while we're in the sync/wait loop. > Even then, taking an interrupt per nibble would be ugly. The QuickCam would also need an onboard frame-buffer. Maybe signal when the whole frame was ready. But! Enough wishing :) Yep, in that case, spend $300 on a matrox meteor. ;-) > Since we're gated by the speed of the spin loop anyway, we may as well hit > the "go" button as soon as possible and then do the stuff that's slow on > the processor. You could probably code the shifts in LISP and it would > still complete before the sync/wait completed. :-) I was thinking of something along the same lines. But of course coding it in assembly never hurts so I thought, I'd throw it out. Sure. > Are you sure it's instant? I think we have several tens of microseconds of > slack here, don't we? If not, then my proposal for reordering the xfer > routines won't fly. The way I understand the QuickCam's operation: You need to read it as fast as possible? Or am I wrong on this point? Well, I have heard the CCD image fades, but that must be tenths of seconds after, not microseconds. We should have all of the time in the world is my _conjecture_. I haven't re-coded the routines yet, so I wouldn't know for sure. > I found a bug in my code comparing it to xfqcam, but I still haven't fixed > my hardware to do bidir. I need to fix this myself- I think it's a subtle bug which exists in all of the bi-directional code (or maybe I just have funky hardware).