From owner-freebsd-multimedia Sun May 25 00:32:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA12953 for multimedia-outgoing; Sun, 25 May 1997 00:32:04 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA12948 for ; Sun, 25 May 1997 00:32:02 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id AAA01091; Sun, 25 May 1997 00:31:24 -0700 (PDT) Message-Id: <199705250731.AAA01091@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: multimedia@freebsd.org Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-reply-to: Your message of "Sun, 25 May 1997 00:49:39 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 00:31:24 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Tnks for the feeback! In order to determine which section of the driver has improved I need to know the application that you are running and if possible the resolution and pixel depth. Tnks! Amancio >From The Desk Of Bernie Doehner : > Hi: > > Just to let everyone know.. I picked up Amancio's modified bt848 driver > and recompiled it into my kernel. Have only tested it for about 10-15 > minutes so far, but my impression is that it's a definite improvement. > > I don't know if this was the intention, but the IDE timeouts that I was > frequently getting before seem to have been reduced in frequency and > duration. Now to look at the code and try to understand what the > difference between it and the committed is. > > Bernie > From owner-freebsd-multimedia Sun May 25 06:09:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA22002 for multimedia-outgoing; Sun, 25 May 1997 06:09:45 -0700 (PDT) Received: from uhf.wdc.net (uhf.wdc.net [198.147.74.44]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA21997 for ; Sun, 25 May 1997 06:09:41 -0700 (PDT) Received: from localhost (root@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id JAA00866; Sun, 25 May 1997 09:10:37 -0400 (EDT) Date: Sun, 25 May 1997 09:10:35 -0400 (EDT) From: To: multimedia@freebsd.org cc: hasty@rah.star-gate.com Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > Just to let everyone know.. I picked up Amancio's modified bt848 driver > and recompiled it into my kernel. Have only tested it for about 10-15 > minutes so far, but my impression is that it's a definite improvement. > > I don't know if this was the intention, but the IDE timeouts that I was > frequently getting before seem to have been reduced in frequency and > duration. Now to look at the code and try to understand what the > difference between it and the committed is. > > Bernie > Actualy, when I maxed the size of the fxtv window I got another nasty system lockup. I'll try again and see if maybe the problem is windows size. Bernie From owner-freebsd-multimedia Sun May 25 07:27:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA23798 for multimedia-outgoing; Sun, 25 May 1997 07:27:46 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA23793 for ; Sun, 25 May 1997 07:27:42 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id KAA00421; Sun, 25 May 1997 10:28:22 -0400 (EDT) Date: Sun, 25 May 1997 10:28:20 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: <199705250731.AAA01091@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > In order to determine which section of the driver has improved > I need to know the application that you are running and if possible > the resolution and pixel depth. > Sorry... XFree 3.2A set to 1024x768.. Stealth 3D 4000 clone fxtv When set to 328x297 it doesn't seem to lockup as badly/frequently, but with window size maxed to 640x5?? it locked up uhf pretty badly. In a little bit I'll try running fxtv at 328x297 for a little longer to see if maybe my problem is windows size related? Probably not, but we'll see. Bernie From owner-freebsd-multimedia Sun May 25 07:33:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24054 for multimedia-outgoing; Sun, 25 May 1997 07:33:45 -0700 (PDT) Received: from cosmos.kaist.ac.kr (maple.kaist.ac.kr [143.248.185.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA24045 for ; Sun, 25 May 1997 07:33:32 -0700 (PDT) Received: (from yichoi@localhost) by cosmos.kaist.ac.kr (8.6.12h2/8.6.12) id XAA24099 for freebsd-multimedia@FreeBSD.ORG; Sun, 25 May 1997 23:29:33 +0900 From: Youngil Choi Message-Id: <199705251429.XAA24099@cosmos.kaist.ac.kr> Subject: 16bit audio sampling & playing tools To: freebsd-multimedia@FreeBSD.ORG Date: Sun, 25 May 1997 23:29:32 +0900 (KST) X-Mailer: ELM [version 2.4 PL21-h4] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-kr Content-Transfer-Encoding: 7bit Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Greetings. I've been interested in audio editor which could directly sample, view, convert, edit and play. For this reason, I want to get some simple code or masterpiece for reference. :) If there is anybody could help me, please let me know. If this possble, I will continue to this work to implement MPEG codec in MMX PC. - yichoi From owner-freebsd-multimedia Sun May 25 07:40:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA24295 for multimedia-outgoing; Sun, 25 May 1997 07:40:06 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA24257 for ; Sun, 25 May 1997 07:40:01 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id KAA00458; Sun, 25 May 1997 10:40:41 -0400 (EDT) Date: Sun, 25 May 1997 10:40:40 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > the resolution and pixel depth. > > I am getting very forgetfull. Pixel depth=15 bpp. Bernie From owner-freebsd-multimedia Sun May 25 09:30:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA27694 for multimedia-outgoing; Sun, 25 May 1997 09:30:15 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA27686 for ; Sun, 25 May 1997 09:30:10 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id MAA00334; Sun, 25 May 1997 12:30:47 -0400 (EDT) Date: Sun, 25 May 1997 12:30:42 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just ran fxtv for over 30 minutes and didn't get ANY IDE timeouts, but I also killed inetd/sendmail and other programs that are likely to exercise the disk. However, as soon as I started heavy disk activity (concatenating several large files together), fxtv totaly froze and I had to reboot.. Not even IDE timeout messages, everything, but fxtv froze. If I don't kill inetd/sendmail, etc and run fxtv (in a small window) in doesn't fataly crash any more, just I do get ocassional IDE timeout errors. For those of you who "tuned in late", I must the only person trying to run a Wincast board on a 486/120 and it seems the DMA is taking too much time on the bus. Bernie From owner-freebsd-multimedia Sun May 25 09:53:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28456 for multimedia-outgoing; Sun, 25 May 1997 09:53:04 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA28451 for ; Sun, 25 May 1997 09:53:00 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id JAA05866; Sun, 25 May 1997 09:52:51 -0700 (PDT) Message-Id: <199705251652.JAA05866@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Youngil Choi cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: 16bit audio sampling & playing tools In-reply-to: Your message of "Sun, 25 May 1997 23:29:32 +0900." <199705251429.XAA24099@cosmos.kaist.ac.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 09:52:50 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk If you look into cdda or tosha both include a program called pcmplay which is capable of playing audio at 44khz 16bit. Cheers, Amancio >From The Desk Of Youngil Choi : > > Greetings. > > I've been interested in audio editor which could directly sample, view, > convert, edit and play. For this reason, I want to get some simple code > or masterpiece for reference. :) > If there is anybody could help me, please let me know. > > If this possble, I will continue to this work to implement MPEG codec > in MMX PC. > > - yichoi From owner-freebsd-multimedia Sun May 25 10:38:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA00268 for multimedia-outgoing; Sun, 25 May 1997 10:38:31 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA00263 for ; Sun, 25 May 1997 10:38:29 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id KAA00307; Sun, 25 May 1997 10:34:42 -0700 (PDT) Message-Id: <199705251734.KAA00307@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-reply-to: Your message of "Sun, 25 May 1997 12:30:42 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 10:34:42 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What do you have your PCI clock set to? Just browse in your PCI bios menu and it is probably there. Cheers, Amancio >From The Desk Of Bernie Doehner : > Just ran fxtv for over 30 minutes and didn't get ANY IDE timeouts, but I > also killed inetd/sendmail and other programs that are likely to exercise > the disk. > > However, as soon as I started heavy disk activity (concatenating several > large files together), fxtv totaly froze and I had to reboot.. Not even > IDE timeout messages, everything, but fxtv froze. > > If I don't kill inetd/sendmail, etc and run fxtv (in a small window) in > doesn't fataly crash any more, just I do get ocassional IDE timeout > errors. > > For those of you who "tuned in late", I must the only person trying to run > a Wincast board on a 486/120 and it seems the DMA is taking too much time > on the bus. > > Bernie > > From owner-freebsd-multimedia Sun May 25 12:05:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA04095 for multimedia-outgoing; Sun, 25 May 1997 12:05:52 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04081 for ; Sun, 25 May 1997 12:05:30 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id PAA00648; Sun, 25 May 1997 15:04:03 -0400 (EDT) Date: Sun, 25 May 1997 15:03:59 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: <199705251734.KAA00307@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What do you have your PCI clock set to? > > Just browse in your PCI bios menu and it is probably there. > > Cheers, > Amancio I must really be in the hardware "dark ages". No PCI clock setting or PCI wait state setting on the Acer AP43 motherboard or its Ami WinBIOS. System Clock speed is 40 Mhz., and the ISA bus is running at 7.1 MHz, but that's all I can see, but I supposed I could take out my scope or frequency counter and check. Bernie From owner-freebsd-multimedia Sun May 25 12:18:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA04653 for multimedia-outgoing; Sun, 25 May 1997 12:18:34 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04644 for ; Sun, 25 May 1997 12:18:31 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id MAA01057; Sun, 25 May 1997 12:12:22 -0700 (PDT) Message-Id: <199705251912.MAA01057@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-reply-to: Your message of "Sun, 25 May 1997 15:03:59 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 12:12:22 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am glad that we finally found the long lost missing link 8) Try to read the motherboard's manual which hopefully mentions the PCI clock . Cheers, Amancio >From The Desk Of Bernie Doehner : > > What do you have your PCI clock set to? > > > > Just browse in your PCI bios menu and it is probably there. > > > > Cheers, > > Amancio > > I must really be in the hardware "dark ages". No PCI clock setting or PCI > wait state setting on the Acer AP43 motherboard or its Ami WinBIOS. > > System Clock speed is 40 Mhz., and the ISA bus is running at 7.1 MHz, but > that's all I can see, but I supposed I could take out my scope or > frequency counter and check. > > Bernie > From owner-freebsd-multimedia Sun May 25 12:28:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05019 for multimedia-outgoing; Sun, 25 May 1997 12:28:46 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05008 for ; Sun, 25 May 1997 12:28:27 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id PAA00720; Sun, 25 May 1997 15:27:20 -0400 (EDT) Date: Sun, 25 May 1997 15:27:17 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: <199705251912.MAA01057@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I am glad that we finally found the long lost missing link 8) Well.. It seems like an improvement.., > Try to read the motherboard's manual which hopefully mentions the PCI > clock . > Cheers, > Amancio > Been through it from A-Z and nothing. I do however notice the load average shoot up to approx. 1.1 when fxtv is running. Should fxtv be so CPU intensive? Maybe there is some truth to the Pentium 90 minimum warning on the box. Bernie From owner-freebsd-multimedia Sun May 25 12:33:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05227 for multimedia-outgoing; Sun, 25 May 1997 12:33:04 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05221 for ; Sun, 25 May 1997 12:33:01 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id MAA01246 for ; Sun, 25 May 1997 12:33:00 -0700 (PDT) Message-Id: <199705251933.MAA01246@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: multimedia@freebsd.org Subject: about vic MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <1241.864588780.0@rah.star-gate.com> Date: Sun, 25 May 1997 12:33:00 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1241.864588780.1@rah.star-gate.com> Background: Brad Karp is complaining about the artifacts that vic is generating using vic's nornmal resolution. This simple issue hits two important areas the driver and why does H.261 require 352x288 which is probably 1/2 of PAL resolution. To say the least I don't see why we have to be restricted to resolutions which are evenly divisible of PAL resolution: 177x144, 352x288. On the driver say we may be able to improve the NTSC artifacts by way of storing frames in a round robin fashion which means that every time that vic wants a frame it will get a valid frame and not a frame which is currently being updated, or starting to capture the next frame. Cheers, Amancio ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Replied: Sun, 25 May 1997 11:40:54 -0700 Replied: Van Jacobson Return-Path: van@ee.lbl.gov Received: from rx7.ee.lbl.gov (rx7.ee.lbl.gov [131.243.1.54]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id LAA00699 for ; Sun, 25 May 1997 11:06:07 -0700 (PDT) Received: by rx7.ee.lbl.gov (8.8.2/1.43r) id LAA29062; Sun, 25 May 1997 11:06:26 -0700 (PDT) Message-Id: <199705251806.LAA29062@rx7.ee.lbl.gov> To: Amancio Hasty cc: rem-conf@es.net Subject: Re: h.261 : 320x240 vs 352x288 In-reply-to: Your message of Sat, 24 May 97 22:40:50 PDT. Date: Sun, 25 May 97 11:06:26 PDT From: Van Jacobson Amancio, the vic h261 encoder code, like the precept h261 encoder, will embed a 320x240 ntsc image in a 352x288 cif rectangle so decoders see no change. Almost all the vic grabbers work this way. The major exception was the meteor grabber but I've rewritten part of it for the upcoming vic 2.8.1 release to grab 320x240 fields rather than scaling 640x480 frames. This gets rid of the interlace artifacts & also some geometric distortion introduced by the scaling. I also changed it to grab YUV_PACKED rather than YUV_422. The combination of this change & the single field grab now means the stock meteor works reliably even with the broken Natoma PCI chips on Intel's Pentium-Pro motherboards. The grabber was also changed to remove two extra memory-memory copies of each frame so it sped up more than a factor of two (our 200mhz ppro systems will now grab & h261 cif encode 30fps of high motion video while simultaneously decoding & rendering 2 30fps cif streams at 640x480 -- we don't have any other box that can come close to this). I've put the current working version of the modified meteor driver at ftp://ftp.ee.lbl.gov/grabber-meteor.cc if you want to play with it. It should work with vic-2.8 & I'd welcome any bug reports or changes that could make it in before the 2.8.1 release. Thanks. - Van ------- =_aaaaaaaaaa0-- From owner-freebsd-multimedia Sun May 25 12:33:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05254 for multimedia-outgoing; Sun, 25 May 1997 12:33:17 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA05222 for ; Sun, 25 May 1997 12:33:02 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id PAA00738; Sun, 25 May 1997 15:32:23 -0400 (EDT) Date: Sun, 25 May 1997 15:32:18 -0400 (EDT) From: Bernie Doehner To: hasty@rah.star-gate.com cc: multimedia@freebsd.org Subject: fxtv lockups Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Something else I didn't mention.. I am running fxtv version 0.42 (unmodified). Also, a significant number of my lockups seem to occur when I am making adjustments (ie. moving sliders for contrast). I have also had one lockup occur when I moved the fxtv window from one virtual desktop to another.. Only thing I haven't tried yet is to go back to XFree 3.2, but I didn't want to do that because 16 bpp support under 3.2A is a lot better. Bernie From owner-freebsd-multimedia Sun May 25 13:55:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA09054 for multimedia-outgoing; Sun, 25 May 1997 13:55:56 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA09046 for ; Sun, 25 May 1997 13:55:53 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id WAA13405; Sun, 25 May 1997 22:19:16 +0200 From: Luigi Rizzo Message-Id: <199705252019.WAA13405@labinfo.iet.unipi.it> Subject: Re: about vic To: hasty@rah.star-gate.com (Amancio Hasty), van@ee.lbl.gov Date: Sun, 25 May 1997 22:19:16 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199705251933.MAA01246@rah.star-gate.com> from "Amancio Hasty" at May 25, 97 12:32:41 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Amancio, > > the vic h261 encoder code, like the precept h261 encoder, will > embed a 320x240 ntsc image in a 352x288 cif rectangle so > decoders see no change. Almost all the vic grabbers work this ... > rather than YUV_422. The combination of this change & the > single field grab now means the stock meteor works reliably even > with the broken Natoma PCI chips on Intel's Pentium-Pro I think the conclusion of various investigations was that it was the Philips 7116 (the PCI interface on the meteor), not the Natoma, which caused problems. > motherboards. The grabber was also changed to remove two extra > memory-memory copies of each frame so it sped up more than a speaking of performance, since the Bt848 chip (for which Amancio has written a driver) is highly programmable, is there a preferred output format for the grabber to supply data ready for the encoder without need for copies (or does YUV_PACKED already suffice ?) Thanks Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Sun May 25 14:26:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09864 for multimedia-outgoing; Sun, 25 May 1997 14:26:51 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA09840; Sun, 25 May 1997 14:26:45 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id OAA00516; Sun, 25 May 1997 14:26:33 -0700 (PDT) Message-Id: <199705252126.OAA00516@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Luigi Rizzo cc: van@ee.lbl.gov, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: about vic In-reply-to: Your message of "Sun, 25 May 1997 22:19:16 +0200." <199705252019.WAA13405@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 14:26:33 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Luigi Rizzo : > > Amancio, > > > > the vic h261 encoder code, like the precept h261 encoder, will > > embed a 320x240 ntsc image in a 352x288 cif rectangle so > > decoders see no change. Almost all the vic grabbers work this > ... > > rather than YUV_422. The combination of this change & the > > single field grab now means the stock meteor works reliably even > > with the broken Natoma PCI chips on Intel's Pentium-Pro > > I think the conclusion of various investigations was that it was > the Philips 7116 (the PCI interface on the meteor), not the Natoma, > which caused problems. We are not sure about that mostly due to Intel and Matrox never explaining the real cause of the problem. I just CC hackers and hopefully one of the Intel CPU or PCI designers will shed some light into this problem. My educated is that Intel is not going to tell us what is the real problem. On the lighter side of things, Philips is supposed to have a new chipset, SAA 7146, which is not supposed to have this nasty dma bug or incur the nasty dma bug in the Natoma chipset. > > motherboards. The grabber was also changed to remove two extra > > memory-memory copies of each frame so it sped up more than a > > speaking of performance, since the Bt848 chip (for which Amancio has > written a driver) is highly programmable, is there a preferred output > format for the grabber to supply data ready for the encoder without > need for copies (or does YUV_PACKED already suffice ?) > We should be able to provide whatever format vic wants and also prepare the buffer to whatever vic wants to eliminate copying buffers altogether. What I am thinking about doing is providing a ring buffers such that when vic wants a buffer all I should do is provide the buffer pointer to the new buffer thus eliminating all buffers on the side of the video grabber. The next stage in way of performance improvement could be to provide MMX support and to provide support to dump YUV on the X server. The latter is a bit more difficult given that it requires X server modifications however many popular cards now days do provide yuv to rgb conversion. And the last phase will be to provide a mechanism to activate WC combining for PCI display card's linear frame buffer which can speed up display rates by a 400 percent or so. For those interested in trying out Van's grabber-meteor.cc and own a Bt848 based card, please download : ftp://rah.star-gate.com/pub/bt848.tar.gz The driver includes Van's grabber-meteor.cc with some slight modifications to detect both a meteor and a Bt848 based card. Enjoy, Amancio From owner-freebsd-multimedia Sun May 25 16:18:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA14528 for multimedia-outgoing; Sun, 25 May 1997 16:18:43 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA14517 for ; Sun, 25 May 1997 16:18:35 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id QAA24400; Sun, 25 May 1997 16:18:05 -0700 (PDT) Message-ID: <19970525161804.37676@hydrogen.nike.efn.org> Date: Sun, 25 May 1997 16:18:04 -0700 From: John-Mark Gurney To: Bernie Doehner Cc: Amancio Hasty , multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: ; from Bernie Doehner on Sun, May 25, 1997 at 12:30:42PM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bernie Doehner scribbled this message on May 25: > Just ran fxtv for over 30 minutes and didn't get ANY IDE timeouts, but I > also killed inetd/sendmail and other programs that are likely to exercise > the disk. > > However, as soon as I started heavy disk activity (concatenating several > large files together), fxtv totaly froze and I had to reboot.. Not even > IDE timeout messages, everything, but fxtv froze. hmm... maybe this is similar to my problems that I have... as one of the crashes that I had caused ed0: device timeout's... i.e. intrupts stop working... major different is that I'm running SCSI... and it might be a conflict between the two... once I was able to manipulate windows and such.. but the windows were swapped out, so they were never updated... > If I don't kill inetd/sendmail, etc and run fxtv (in a small window) in > doesn't fataly crash any more, just I do get ocassional IDE timeout > errors. > > For those of you who "tuned in late", I must the only person trying to run > a Wincast board on a 486/120 and it seems the DMA is taking too much time > on the bus. I don't know... I think there is something else wrong... as you can see, my system is a 486 bases system too... have you check to make sure your mb is pci2.1 compliant? I haven't gotten around to check mine out... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-multimedia Sun May 25 16:33:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA15013 for multimedia-outgoing; Sun, 25 May 1997 16:33:42 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA15008 for ; Sun, 25 May 1997 16:33:40 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id QAA00368; Sun, 25 May 1997 16:27:22 -0700 (PDT) Message-Id: <199705252327.QAA00368@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: John-Mark Gurney cc: Bernie Doehner , multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-reply-to: Your message of "Sun, 25 May 1997 16:18:04 PDT." <19970525161804.37676@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 16:27:21 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just go the intel web site and check out their video capture newsgroup Ask them if there are known problems with the ISVR III and SiS or VIA chipsets. ISVR III is intel's version of the Bt848 card and the card does not have a tuner. Amancio >From The Desk Of John-Mark Gurney : > Bernie Doehner scribbled this message on May 25: > > Just ran fxtv for over 30 minutes and didn't get ANY IDE timeouts, but I > > also killed inetd/sendmail and other programs that are likely to exercise > > the disk. > > > > However, as soon as I started heavy disk activity (concatenating several > > large files together), fxtv totaly froze and I had to reboot.. Not even > > IDE timeout messages, everything, but fxtv froze. > > hmm... maybe this is similar to my problems that I have... as one of the > crashes that I had caused ed0: device timeout's... i.e. intrupts stop > working... > > major different is that I'm running SCSI... and it might be a conflict > between the two... once I was able to manipulate windows and such.. but > the windows were swapped out, so they were never updated... > > > If I don't kill inetd/sendmail, etc and run fxtv (in a small window) in > > doesn't fataly crash any more, just I do get ocassional IDE timeout > > errors. > > > > For those of you who "tuned in late", I must the only person trying to run > > a Wincast board on a 486/120 and it seems the DMA is taking too much time > > on the bus. > > I don't know... I think there is something else wrong... as you can see, > my system is a 486 bases system too... have you check to make sure your > mb is pci2.1 compliant? I haven't gotten around to check mine out... > > -- > John-Mark Gurney Modem/FAX: +1 541 683 6954 > Cu Networking > > Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-multimedia Sun May 25 18:22:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA19975 for multimedia-outgoing; Sun, 25 May 1997 18:22:43 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA19969 for ; Sun, 25 May 1997 18:22:41 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id SAA00876 for ; Sun, 25 May 1997 18:22:40 -0700 (PDT) Message-Id: <199705260122.SAA00876@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: multimedia@freebsd.org Subject: bt848 driver, again... Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 18:22:40 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk With the help of Brad Karp , we managed to sort the problem of vic's dynamically setting the frame rate. If you use Van's grabber-meteor.cc you shall experience nearly flawless behavior. With the old grabber-meteor.cc the card still misses some frames so there is still some work to do in this area. In the mean time vic users please use Van's grabber-meteor.cc which you can find in the latest bt848 driver upgrade: ftp://rah.star-gate.com/pub/bt848.tar.gz We are still not done with vic given that as Luigi alluded there is ample room for improvement. If anyone is interested in working with me on this one just email me. Enjoy, Amancio From owner-freebsd-multimedia Sun May 25 19:08:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA21859 for multimedia-outgoing; Sun, 25 May 1997 19:08:48 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA21854 for ; Sun, 25 May 1997 19:08:46 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id TAA01244 for ; Sun, 25 May 1997 19:08:45 -0700 (PDT) Message-Id: <199705260208.TAA01244@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: multimedia@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 25 May 1997 19:08:45 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk http://cs.intel.com/Intel/other_products/video_capture/threads.htm If anyone is interested in finding out compatibility of the Bt848 card with a strange PCI chipset: SiS or Via feel free to post to that newsgroup. Ask if the ISVRIII (Thats Intel's crippled Bt848 card) works with your system. Enjoy, Amancio From owner-freebsd-multimedia Mon May 26 06:40:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA17867 for multimedia-outgoing; Mon, 26 May 1997 06:40:12 -0700 (PDT) Received: from prova.iet.unipi.it (prova.iet.unipi.it [131.114.9.236]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA17841 for ; Mon, 26 May 1997 06:40:03 -0700 (PDT) Received: (from root@localhost) by prova.iet.unipi.it (8.8.5/8.8.5) id PAA00407; Mon, 26 May 1997 15:44:09 +0200 (CEST) Date: Mon, 26 May 1997 15:44:09 +0200 (CEST) From: Luigi Rizzo Message-Id: <199705261344.PAA00407@prova.iet.unipi.it> To: multimedia@freebsd.org, van@ee.lbl.gov Subject: some vic-2.8 patches to support PAL Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, vic 2.8 does not allow one to set the input signal type (NTSC/PAL/SECAM) from the control panel, although support is almost there. The attached patch works for me with the grabber-meteor driver when used with PAL input. Perhaps a similar thing could go into vic-2.8.1 if it is not already there. Cheers Luigi --- ui-ctrlmenu.tcl.orig Thu Jun 27 03:27:48 1996 +++ ui-ctrlmenu.tcl Tue May 6 20:07:12 1997 @@ -564,7 +564,7 @@ proc select_device device { global transmitButton sizeButtons portButton formatButtons \ videoFormat defaultFormat lastDevice defaultPort inputPort \ - transmitButtonState + transmitButtonState typeButton # # Remember settings of various controls for previous device @@ -607,6 +607,11 @@ } else { $portButton configure -state disabled } + if [device_supports $device type *] { + $typeButton configure -state normal + } else { + $typeButton configure -state disabled + } insert_grabber_panel [$device nickname] @@ -757,9 +762,9 @@ menu $m $m add radiobutton -label "auto" -command restart \ -value auto -variable inputType -font $f - $m add radiobutton -label "NTSC" -command restart \ + $m add radiobutton -label "NTSC" -command "grabber type ntsc" \ -value ntsc -variable inputType -font $f - $m add radiobutton -label "PAL" -command restart \ + $m add radiobutton -label "PAL" -command "grabber type pal" \ -value pal -variable inputType -font $f $m add radiobutton -label "SECAM" -command restart \ -value secam -variable inputType -font $f @@ -774,7 +779,8 @@ build.encoder_options $w.options build.device $w.device build.port $w.port - pack $w.device $w.port $w.options -fill x + build.type $w.type + pack $w.device $w.port $w.type $w.options -fill x } proc build.encoder_options w { @@ -1172,6 +1178,9 @@ global inputPort inputType portButton typeButton if { [$portButton cget -state] == "normal" } { $grabber port $inputPort + } + if { [$typeButton cget -state] == "normal" } { + $grabber type $inputType } setFillRate update From owner-freebsd-multimedia Mon May 26 08:25:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA23861 for multimedia-outgoing; Mon, 26 May 1997 08:25:47 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA23855 for ; Mon, 26 May 1997 08:25:42 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id LAA01099; Mon, 26 May 1997 11:26:20 -0400 (EDT) Date: Mon, 26 May 1997 11:26:17 -0400 (EDT) From: Bernie Doehner To: hasty@rah.star-gate.com cc: multimedia@FreeBSD.ORG Subject: Re: fxtv lockups In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Only thing I haven't tried yet is to go back to XFree 3.2, but I didn't > want to do that because 16 bpp support under 3.2A is a lot better. > Well.. Sorry to report, but late yesterday afternoon I was composing a mail message with pine and watching fxtv at the same time (small window), and with Amancio's mods, and everything just froze, resulting in more filesystem damage, so at least to me things seem better, but not a lot more. It appears that if I am going to watch tv, I have to kill the internet connection and all programs that could possibly write to disk and then dedicate to watching tv. Well at least till we find the problem (or I can upgrade to a dual Pentium box). In the meantime, I have gone back to XFree 3.2, in an effort to see if maybe the version 3.2A X server is causing the problems (it's beta after all). Bernie From owner-freebsd-multimedia Mon May 26 08:45:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA24746 for multimedia-outgoing; Mon, 26 May 1997 08:45:24 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA24738 for ; Mon, 26 May 1997 08:45:18 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id LAA01155; Mon, 26 May 1997 11:45:54 -0400 (EDT) Date: Mon, 26 May 1997 11:45:52 -0400 (EDT) From: Bernie Doehner To: John-Mark Gurney cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) In-Reply-To: <19970525161804.37676@hydrogen.nike.efn.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > hmm... maybe this is similar to my problems that I have... as one of the > crashes that I had caused ed0: device timeout's... i.e. intrupts stop > working... Hmmm. Can I trade your ed0: timeouts for my wd0 timeouts? :) > major different is that I'm running SCSI... and it might be a conflict > between the two... once I was able to manipulate windows and such.. but > the windows were swapped out, so they were never updated... That reminds me. Something else I'd like to try is running fxtv without DMA. Where is the list of arguments that fxtv takes? > my system is a 486 bases system too... have you check to make sure your > mb is pci2.1 compliant? I haven't gotten around to check mine out... Well the box does say Pentium 90 minimum... No I haven't.. How does one check pci2.1 compliance? Is there a program that does this? Bernie From owner-freebsd-multimedia Mon May 26 09:05:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA25611 for multimedia-outgoing; Mon, 26 May 1997 09:05:10 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA25606 for ; Mon, 26 May 1997 09:05:08 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 26 May 1997 12:04:00 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA16788; Mon, 26 May 97 12:03:58 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id MAA08669; Mon, 26 May 1997 12:02:57 -0400 Message-Id: <19970526120257.54104@ct.picker.com> Date: Mon, 26 May 1997 12:02:57 -0400 From: Randall Hopper To: Bernie Doehner Cc: multimedia@FreeBSD.ORG Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) References: <199705250731.AAA01091@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Bernie Doehner on Sun, May 25, 1997 at 10:28:20AM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bernie Doehner: |However, as soon as I started heavy disk activity (concatenating several |large files together), fxtv totaly froze and I had to reboot.. Not even |IDE timeout messages, everything, but fxtv froze. | |If I don't kill inetd/sendmail, etc and run fxtv (in a small window) in |doesn't fataly crash any more, just I do get ocassional IDE timeout |errors. | |For those of you who "tuned in late", I must the only person trying to run |a Wincast board on a 486/120 and it seems the DMA is taking too much time |on the bus. Two things you might try. See if your BIOS will let you take your system clock down to 33Mhz or less (something to pull the PCI speed down to spec, assuming it is being overclocked to 40 now). Maybe something other than your Wincast on your PCI bus can't hack 40Mhz when the bus gets busy. Also, see if you BIOS supports locking your IDE channels down to Mode 3, 2, or 1. Another thing just popped into my brain. I remember big stinks about the RZ-1000 and CMD640 IDE chips. You might browse the URLs at the bottom of the message for making sure you don't have a problem board. Randall ------------------------------------------------------------------- http://www.wi.leidenuniv.nl/ata http://warp.eecs.berkeley.edu/os2/workbench/work.htm o the CMD640x, a dual-channel PCI to EIDE interface used on many mainboards (Intel!) and interface boards, has a number of dangerous bugs you need to be aware of. o The PC-Tech RZ-1000, used on AT&T, Dell, Gateway and Intel boards, also has two data-corrupting bugs. See also . In both cases, the corruption occurs only in specific software environments and is very subtle; you can go on working for months without suspecting anything more than buggy software. The damage can be immense. For all the details, look at Roedy Green's roedy@bix.com "PCI EIDE controller flaws" FAQ included with his EIDE test program which will test your system for the bugs. From owner-freebsd-multimedia Mon May 26 09:29:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26963 for multimedia-outgoing; Mon, 26 May 1997 09:29:26 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id JAA26958 for ; Mon, 26 May 1997 09:29:24 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 26 May 1997 12:28:15 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA17069; Mon, 26 May 97 12:28:13 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id MAA08695; Mon, 26 May 1997 12:27:14 -0400 Message-Id: <19970526122714.40844@ct.picker.com> Date: Mon, 26 May 1997 12:27:14 -0400 From: Randall Hopper To: Bernie Doehner Cc: multimedia@FreeBSD.ORG Subject: High CPU utiliz w/ fxtv (was Re: Amancio's latest mods...) References: <199705250731.AAA01091@rah.star-gate.com> <19970526120257.54104@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970526120257.54104@ct.picker.com>; from Randall Hopper on Mon, May 26, 1997 at 12:02:57PM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bernie Doehner: |I do however notice the load average shoot up to approx. 1.1 when fxtv is |running. Should fxtv be so CPU intensive? Maybe there is some truth to |the Pentium 90 minimum warning on the box. Louis (louie@TransSys.COM) & I noticed this a month or so ago, and I've got it on my ToDo list to look deeper into this. When doing direct video, it should need very little CPU. I dug into it briefly before: the fxtv main X event loop isn't spinning (so the fxtv code proper isn't burning cycles), but down in the bowels of NextEvent, it appears the Xlib code is spinning hard checking for data on the X socket. Attaching fxtv in the debugger to stop it of course gets rid of the CPU overhead, the system load goes down, and the video keeps going as it should (what you'd expect with fxtv _actually running_). Just took a closer look. xscope says no X protocol is being sent between the client and X server when direct video is running, or when the video is paused, so that's not it. ktrace/lsof/netstat say that the kulprit is file descriptor #3, which is the UNIX X server socket: /tmp/.X11-unix/X0 Down in XtAppNextEvent, Xlib internally is doing this over-and-over: 256 of these: 2520 fxtv CALL ioctl(0x3,FIONREAD,0xefbfcaf4) 2520 fxtv RET ioctl 0 and then 1 of these: 2520 fxtv CALL select(0x4,0xefbfcad4,0,0,0x815b79c) 2520 fxtv RET select 0 (Any data yet? No. Any data yet? No...) Now why the timeout for the select is so short, I have no idea. On a hunch, I tried bumping the timeouts used in fxtv to 1 second -- no difference. #0 0x82168e1 in ioctl () #1 0x813a82b in _X11TransSocketBytesReadable () #2 0x813b57f in _X11TransBytesReadable () #3 0x811f876 in _XEventsQueued () #4 0x810edd8 in XEventsQueued () #5 0x80d2e6f in XtAppNextEvent () #6 0x7920 in main (argc=1, argv=0xefbfd3e4) at tv.c:391 dtv I notice doesn't have this CPU overhead, so the different might be related to the delta of X server features used by the two programs. I'll flip a question to the XFree folks about this, now that I've accumulated some data. Of course, if anybody has any clues, please let me know. Randall From owner-freebsd-multimedia Mon May 26 10:36:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA00927 for multimedia-outgoing; Mon, 26 May 1997 10:36:27 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA00887 for ; Mon, 26 May 1997 10:35:45 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id NAA00335; Mon, 26 May 1997 13:36:16 -0400 (EDT) Date: Mon, 26 May 1997 13:36:15 -0400 (EDT) From: Bernie Doehner To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: High CPU utiliz w/ fxtv (was Re: Amancio's latest mods...) In-Reply-To: <19970526122714.40844@ct.picker.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Great detective work Randall: Also, for what it's worth.... My picture "quality" under XFree 3.2 S3V as opposed to version 3.2A is a bit better. And ever since I backgraded to version 3.2, most of my timeouts have been during multi-sector transfers on wd0. As as work around, I'll try recompiling kernel without multisector on wd0 and see if that puts a stop to my problem. Btw, I downloaded the RZ1000/CD640 test program, but it relies on the test disk being msdos format which mine is not, so I can't test it. But I have looked all over the board and not found these two chips Bernie From owner-freebsd-multimedia Mon May 26 12:40:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA07025 for multimedia-outgoing; Mon, 26 May 1997 12:40:16 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA07018 for ; Mon, 26 May 1997 12:40:11 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id PAA00303; Mon, 26 May 1997 15:41:01 -0400 (EDT) Date: Mon, 26 May 1997 15:40:56 -0400 (EDT) From: Bernie Doehner To: multimedia@freebsd.org cc: rhh@ct.picker.com Subject: bt848 hangups on 486's Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi: I just tried rebooting with multi-sector disk I/O turned off on wd0 and it locked up even quicker than before.. Previously I also tried IDE mode 3, but to no avail.. Still locks up. This time, all it took to lock up instantly was to resize the window to max size, and type "su" on a xterm. >From Randall's comments it sure seems like fxtv is eating up too much CPU time. Unfortunately second to last crash took out today's mail spool file. Randall mentioned a program he used called xs* to look at X protocol activity. Could someone please fill in the blank? I can confortably say that I have tried everything now in terms of configuration changes. Time to start look at why fxtv is spinning in circles. Bernie From owner-freebsd-multimedia Mon May 26 13:20:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA09070 for multimedia-outgoing; Mon, 26 May 1997 13:20:06 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09042 for ; Mon, 26 May 1997 13:20:02 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id NAA07535; Mon, 26 May 1997 13:19:55 -0700 (PDT) Message-Id: <199705262019.NAA07535@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: bt848 hangups on 486's In-reply-to: Your message of "Mon, 26 May 1997 15:40:56 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 1997 13:19:55 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Run dtv and see if it hangs your system. Amancio >From The Desk Of Bernie Doehner : > Hi: > > I just tried rebooting with multi-sector disk I/O turned off on wd0 and it > locked up even quicker than before.. > > Previously I also tried IDE mode 3, but to no avail.. Still locks up. > > This time, all it took to lock up instantly was to resize the window to > max size, and type "su" on a xterm. > > From Randall's comments it sure seems like fxtv is eating up too much CPU > time. Unfortunately second to last crash took out today's mail spool > file. Randall mentioned a program he used called xs* to look at X protocol > activity. Could someone please fill in the blank? > > I can confortably say that I have tried everything now in terms of > configuration changes. Time to start look at why fxtv is spinning in > circles. > > Bernie > From owner-freebsd-multimedia Mon May 26 13:30:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA09467 for multimedia-outgoing; Mon, 26 May 1997 13:30:02 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09432 for ; Mon, 26 May 1997 13:29:57 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id QAA00361; Mon, 26 May 1997 16:30:29 -0400 (EDT) Date: Mon, 26 May 1997 16:30:28 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: bt848 hangups on 486's In-Reply-To: <199705262019.NAA07535@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Run dtv and see if it hangs your system. > > Amancio No it doesn't. However, it also pushes the load average up to slightly above 1. Also, under dtv, the picture is very dark, I get no audio, and I am losing a lot of frames. This is with 15 bpp (which is the only depth I can do that matches dtv). Bernie From owner-freebsd-multimedia Mon May 26 13:40:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA09982 for multimedia-outgoing; Mon, 26 May 1997 13:40:56 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA09977 for ; Mon, 26 May 1997 13:40:54 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id NAA07838; Mon, 26 May 1997 13:40:43 -0700 (PDT) Message-Id: <199705262040.NAA07838@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: bt848 hangups on 486's In-reply-to: Your message of "Mon, 26 May 1997 16:30:28 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 1997 13:40:42 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You are probably losing a "lot" of frames because your PCI chipset can't keep up with the video stream or your video card. Amancio >From The Desk Of Bernie Doehner : > > Run dtv and see if it hangs your system. > > > > Amancio > > No it doesn't. However, it also pushes the load average up to slightly > above 1. > > Also, under dtv, the picture is very dark, I get no audio, and I am losing > a lot of frames. > > This is with 15 bpp (which is the only depth I can do that matches dtv). > > Bernie > From owner-freebsd-multimedia Mon May 26 13:43:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10029 for multimedia-outgoing; Mon, 26 May 1997 13:43:19 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10023 for ; Mon, 26 May 1997 13:43:13 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id QAA01109; Mon, 26 May 1997 16:43:52 -0400 (EDT) Date: Mon, 26 May 1997 16:43:51 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: bt848 hangups on 486's In-Reply-To: <199705262040.NAA07838@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 26 May 1997, Amancio Hasty wrote: > You are probably losing a "lot" of frames because your PCI chipset can't > keep up with the video stream or your video card. > > Amancio I'd agree, BUT fxtv doesn't have this problem (of losing frames). Bernie From owner-freebsd-multimedia Mon May 26 13:50:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10260 for multimedia-outgoing; Mon, 26 May 1997 13:50:06 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10253 for ; Mon, 26 May 1997 13:50:03 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id NAA07967; Mon, 26 May 1997 13:49:57 -0700 (PDT) Message-Id: <199705262049.NAA07967@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: bt848 hangups on 486's In-reply-to: Your message of "Mon, 26 May 1997 16:43:51 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 1997 13:49:56 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk What resolution is dtv using? Amancio >From The Desk Of Bernie Doehner : > > On Mon, 26 May 1997, Amancio Hasty wrote: > > > You are probably losing a "lot" of frames because your PCI chipset can't > > keep up with the video stream or your video card. > > > > Amancio > > I'd agree, BUT fxtv doesn't have this problem (of losing frames). > > Bernie > From owner-freebsd-multimedia Mon May 26 13:54:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA10449 for multimedia-outgoing; Mon, 26 May 1997 13:54:43 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA10441 for ; Mon, 26 May 1997 13:54:38 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id QAA01336; Mon, 26 May 1997 16:55:21 -0400 (EDT) Date: Mon, 26 May 1997 16:55:15 -0400 (EDT) From: Bernie Doehner To: Amancio Hasty cc: multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: bt848 hangups on 486's In-Reply-To: <199705262049.NAA07967@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > What resolution is dtv using? > > Amancio > 320x240.. First second is perfect. After that the flicker starts. Bernie From owner-freebsd-multimedia Mon May 26 15:07:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA14029 for multimedia-outgoing; Mon, 26 May 1997 15:07:49 -0700 (PDT) Received: from nscfw.iafrica.com (GMsjDAj83pfZgPlJZIui3mLr2mRPAKN/@nscfw.iafrica.com [196.31.1.121]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA14019 for ; Mon, 26 May 1997 15:07:42 -0700 (PDT) Received: from bradh by nscfw.iafrica.com with smtp (Exim 1.60 #2) id 0wW7vN-0006pe-00; Tue, 27 May 1997 00:07:29 +0200 Date: Tue, 27 May 1997 00:07:29 +0200 (SAT) From: Brad Hendrickse To: freebsd-multimedia@freebsd.org Subject: TV-Card (Aims Lab Video Highway - VTR525) problems... Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi there, I just bought the above TV card and was wondering if there is any support under FreeBSD for it. As far as I can tell, it isn't the BT848 (fairly certain, in fact) Has anyone had this card working? TIA, Brad From owner-freebsd-multimedia Mon May 26 16:15:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA16344 for multimedia-outgoing; Mon, 26 May 1997 16:15:11 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16339 for ; Mon, 26 May 1997 16:15:07 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id QAA00634; Mon, 26 May 1997 16:12:17 -0700 (PDT) Message-Id: <199705262312.QAA00634@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Bernie Doehner cc: freebsd-multimedia@FreeBSD.ORG Subject: Non-Intel PCI chipset owners and Bt848 based cards In-reply-to: Your message of "Mon, 26 May 1997 17:51:23 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 1997 16:12:16 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Okay, people listen up. If you are having problems like system crashes when fxtv starts up or a few seconds there after, most likely the problem is due to your PCI chipset. If you are not sure , post or e-mail to your Bt848 card manufacturer and specifically ask if there are any known issues with your card and your CPU /PCI setup. Just went to www.stb.com and it seems that they are having problems with VIA chipsets and it appears that for some motherboards Hauppauge may have a hardware work around . So take it up with your manufacturer. Please include this warning in the Bt848 Web Page. Amancio From owner-freebsd-multimedia Tue May 27 07:04:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA14926 for multimedia-outgoing; Tue, 27 May 1997 07:04:52 -0700 (PDT) Received: from info.iet.unipi.it (info.iet.unipi.it [131.114.9.184]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA14858 for ; Tue, 27 May 1997 07:03:08 -0700 (PDT) Received: (from root@localhost) by info.iet.unipi.it (8.8.5/8.8.5) id QAA00791 for multimedia@freebsd.org; Tue, 27 May 1997 16:00:27 GMT Date: Tue, 27 May 1997 16:00:27 GMT From: Luigi Rizzo Message-Id: <199705271600.QAA00791@info.iet.unipi.it> To: multimedia@freebsd.org Subject: bt848 status, comments and diffs Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Guys, I was looking at solving my problems (missing odd frames etc.) with the YUV* modes, and I noticed that there are some inconsistencies in the handling of SYNC instructions at the end of each frame etc, especially for what regards IRQ generation. This would explain why continuous capture modes work whereas single capture mode dont (and perhaps signals would not work either, although tv does not use them). To clean up things, and before investigating further on the problem, I defined a few macros (OP_IRQ, OP_RESYNC) for commands which are generally used in instructions. I also defined a macro, I2(a,b) which I used for all occurrence of 2-word instructions. This makes the code shorter and especially risc instructions easier to read. Before going on I would like to know (from Amancio perhaps): - what is the meaning of the 'interlace' variable ? What corresponds to the various values (1,2,3) which it can assume ? - is it ok to generate an IRQ on every SYNC instruction, and let the handler ignore it if not required ? This seems to me the safest option (and, even if for continuous capture to the frame buffer it might not be necessary to generate 60 irq/s, the overhead should not be so terrible considering the amount of bus traffic this capture generates). - why, in some SYNC instructions, you use 0xC << 24 ? Those are reserved bits, but probably are SOL/EOL. Are you following some application note, or trying to circumvent problems, or what ? - in modes which require full frames, I think it would be worthwile to make frames always start on the same field (probably odd), i.e. include an OP_SYNC | BKTR_VRO instruction at the beginning. This would make the output more predictable and probably also remove some artifacts which people are seeing and which might be related to some frames starting with the odd field, some with the even field. In the current code you start with OP_SYNC | BKTR_FM1 (or FM3) which does not let you know which frame are you starting with. I could derive the above info from the sources, but because of some inconsistencies I would prefer a word on how things should be, rather than look at what they are. Once the above things have been sorted out, it will probably be relatively easy to fix the driver (and maybe also make it shorter). The diffs follow (relative to today's version from amancio). Cheers Luigi --- brooktree848.c.amancio Tue May 27 14:05:03 1997 +++ brooktree848.c Tue May 27 15:38:43 1997 @@ -2179,7 +2179,7 @@ #define BKTR_FM3 0xe #define BKTR_VRE 0x4 #define BKTR_VRO 0xC -#define BKTR_PXV 0x0 +#define BKTR_PXV 0x0 /* never used */ #define BKTR_EOL 0x1 #define BKTR_SOL 0x2 @@ -2193,6 +2193,11 @@ #define OP_SOL (1 << 27) #define OP_EOL (1 << 26) +#define OP_IRQ (1 << 24) +#define OP_RESYNC (1 << 15) + +#define I2(a, b) { *dma_prog++ = a ; *dma_prog++ = b ; } + bool_t notclipped (bktr_reg_t * bktr, int x, int width) { int i; bktr_clip_t * clip_node; @@ -2369,11 +2374,9 @@ buffer = target_buffer; if (interlace == 2 && rows < 320 ) target_buffer += pitch; - /* contruct sync : for video packet format */ - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM1; + /* contruct sync : for video packed format */ + I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); - /* sync, mode indicator packed data */ - *dma_prog++ = 0; /* NULL WORD */ width = cols; for (i = 0; i < (rows/interlace); i++) { target = target_buffer; @@ -2406,28 +2409,20 @@ switch (i_flag) { case 1: /* sync vre */ - *dma_prog++ = OP_SYNC | 0xC << 24 | 1 << 24 | BKTR_VRE; - *dma_prog++ = 0; /* NULL WORD */ - - *dma_prog++ = OP_JUMP | 0xC << 24; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | 0xC << 24 | OP_IRQ | BKTR_VRE, 0 ); + I2( OP_JUMP | 0xC << 24, (u_long ) vtophys(bktr->dma_prog) ); return; case 2: /* sync vro */ - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 20 | BKTR_VRO; - *dma_prog++ = 0; /* NULL WORD */ - - *dma_prog++ = OP_JUMP; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | OP_IRQ | 1 << 20 | BKTR_VRO, 0 ); + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); return; case 3: /* sync vro */ - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 15 | BKTR_VRO; - *dma_prog++ = 0; /* NULL WORD */ - *dma_prog++ = OP_JUMP | 0xc << 24 ; - *dma_prog = (u_long ) vtophys(bktr->odd_dma_prog); + I2(OP_SYNC | OP_IRQ | OP_RESYNC | BKTR_VRO, 0 ); + I2(OP_JUMP | 0xc << 24, (u_long) vtophys(bktr->odd_dma_prog)); break; } @@ -2441,8 +2436,7 @@ /* sync vre IRQ bit */ - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM1; - *dma_prog++ = 0; /* NULL WORD */ + I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); width = cols; for (i = 0; i < (rows/interlace); i++) { target = target_buffer; @@ -2474,10 +2468,8 @@ } /* sync vre IRQ bit */ - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 15 | BKTR_VRE; - *dma_prog++ = 0; /* NULL WORD */ - *dma_prog++ = OP_JUMP ; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog) ; + I2( OP_SYNC | OP_IRQ | OP_RESYNC | BKTR_VRE, 0 ); + I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ); *dma_prog++ = 0; /* NULL WORD */ } @@ -2531,43 +2523,34 @@ /* contruct sync : for video packet format */ /* sync, mode indicator packed data */ - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM1; - *dma_prog++ = 0; /* NULL WORD */ + I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); b = cols; for (i = 0; i < (rows/interlace); i++) { - *dma_prog++ = inst; - *dma_prog++ = target_buffer; - *dma_prog++ = inst3; - *dma_prog++ = target_buffer + b; + /* XXX I don't understand why 2 instructions since b = cols */ + I2( inst, target_buffer ); + I2( inst3, target_buffer + b ); target_buffer += interlace*(cols * 2); } switch (i_flag) { case 1: /* sync vre */ - *dma_prog++ = OP_SYNC | 0xC << 24 | BKTR_VRE; - *dma_prog++ = 0; /* NULL WORD */ - - *dma_prog++ = OP_JUMP; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | 0xC << 24 | BKTR_VRE, 0 ); + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); return; case 2: /* sync vro */ - *dma_prog++ = OP_SYNC | 0xC << 24 | BKTR_VRO; - *dma_prog++ = 0; /* NULL WORD */ - *dma_prog++ = OP_JUMP; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | 0xC << 24 | BKTR_VRO, 0 ); + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); return; case 3: /* sync vre */ - *dma_prog++ = OP_SYNC | BKTR_VRE; - *dma_prog++ = 0; /* NULL WORD */ - *dma_prog++ = OP_JUMP ; - *dma_prog = (u_long ) vtophys(bktr->odd_dma_prog); + I2( OP_SYNC | BKTR_VRE, 0 ); + I2( OP_JUMP,(u_long ) vtophys(bktr->odd_dma_prog) ); break; } @@ -2578,26 +2561,20 @@ dma_prog = (u_long * ) bktr->odd_dma_prog; /* sync vre */ - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 15 | BKTR_FM1; - *dma_prog++ = 0; /* NULL WORD */ + I2( OP_SYNC | OP_IRQ | OP_RESYNC | BKTR_FM1, 0 ); for (i = 0; i < (rows/interlace) ; i++) { - *dma_prog++ = inst; - *dma_prog++ = target_buffer; - *dma_prog++ = inst3; - *dma_prog++ = target_buffer + b; + I2( inst, target_buffer ); + I2( inst3, target_buffer + b ); target_buffer += interlace * ( cols*2); } } /* sync vro IRQ bit */ - *dma_prog++ = OP_SYNC | 1 << 24 | BKTR_VRE; - *dma_prog++ = 0; /* NULL WORD */ - *dma_prog++ = OP_JUMP ; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | OP_IRQ | BKTR_VRE, 0 ); + I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ); - *dma_prog++ = OP_JUMP; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); /* XXX ??? */ *dma_prog++ = 0; /* NULL WORD */ } @@ -2655,8 +2632,7 @@ t1 = target_buffer; /* contruct sync : for video packet format */ - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM3; /*sync, mode indicator packed data*/ - *dma_prog++ = 0; /* NULL WORD */ + I2( OP_SYNC | OP_RESYNC | BKTR_FM3, 0 ); for (i = 0; i < (rows/interlace ) - 1; i++) { *dma_prog++ = inst; @@ -2669,27 +2645,18 @@ switch (i_flag) { case 1: - *dma_prog++ = OP_SYNC | 0xC << 24 | 1 << 24 | BKTR_VRE; /*sync vre*/ - *dma_prog++ = 0; /* NULL WORD */ - - *dma_prog++ = OP_JUMP | 0xc << 24; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | 0xC << 24 | OP_IRQ | BKTR_VRE, 0); /*sync vre*/ + I2( OP_JUMP | 0xc << 24, (u_long ) vtophys(bktr->dma_prog) ); return; case 2: - *dma_prog++ = OP_SYNC | 0xC << 24 | 1 << 24 | BKTR_VRO; /*sync vre*/ - *dma_prog++ = 0; /* NULL WORD */ - - *dma_prog++ = OP_JUMP; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); + I2( OP_SYNC | 0xC << 24 | OP_IRQ | BKTR_VRO, 0); /*sync vre*/ + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); return; case 3: - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_VRO; - *dma_prog++ = 0; /* NULL WORD */ - - *dma_prog++ = OP_JUMP ; - *dma_prog = (u_long ) vtophys(bktr->odd_dma_prog); + I2( OP_SYNC | OP_RESYNC | BKTR_VRO, 0 ); + I2( OP_JUMP, (u_long ) vtophys(bktr->odd_dma_prog) ); break; } @@ -2699,8 +2666,7 @@ target_buffer = (u_long) buffer + cols; t1 = target_buffer + cols/2; - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM3; - *dma_prog++ = 0; /* NULL WORD */ + I2( OP_SYNC | OP_RESYNC | BKTR_FM3, 0 ); for (i = 0; i < (rows/interlace ) - 1; i++) { *dma_prog++ = inst; @@ -2712,10 +2678,8 @@ } } - *dma_prog++ = OP_SYNC | 1 << 24 | BKTR_VRE; - *dma_prog++ = 0; /* NULL WORD */ - *dma_prog++ = OP_JUMP ; - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog) ; + I2( OP_SYNC | OP_IRQ | BKTR_VRE, 0 ); + I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ) ; *dma_prog++ = 0; /* NULL WORD */ } From owner-freebsd-multimedia Tue May 27 07:32:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA15748 for multimedia-outgoing; Tue, 27 May 1997 07:32:35 -0700 (PDT) Received: from stevenson.cogsci.ed.ac.uk (stevenson144.cogsci.ed.ac.uk [129.215.144.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA15739 for ; Tue, 27 May 1997 07:32:30 -0700 (PDT) Received: (from richard@localhost) by stevenson.cogsci.ed.ac.uk (8.8.5/8.8.5) id PAA18281; Tue, 27 May 1997 15:28:05 +0100 (BST) Date: Tue, 27 May 1997 15:28:05 +0100 (BST) Message-Id: <199705271428.PAA18281@stevenson.cogsci.ed.ac.uk> From: Richard Tobin Subject: Re: Amancio's latest mods to bt848 driver (removal of floating point) To: Bernie Doehner In-Reply-To: Bernie Doehner's message of Sun, 25 May 1997 15:03:59 -0400 (EDT) Organization: just say no Cc: multimedia@FreeBSD.ORG Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > What do you have your PCI clock set to? > I must really be in the hardware "dark ages". No PCI clock setting or PCI > wait state setting on the Acer AP43 motherboard or its Ami WinBIOS. With a 40MHz cpu clock, you almost certainly can't run the PCI bus at 33MHz; I have one that gives a choice of 20MHz and 40MHz. Is there nothing on the board or the BIOS that selects between CPUCLOCK and CPUCLOCK/2 or something like that? Most likely it would work at 40MHz even though its out of spec. I suppose you could try configuring the board for a DX4-100, which would run the CPU slower but give you a 33MHz PCI bus. -- Richard From owner-freebsd-multimedia Tue May 27 08:51:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA18853 for multimedia-outgoing; Tue, 27 May 1997 08:51:21 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA18842 for ; Tue, 27 May 1997 08:51:14 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id IAA13533; Tue, 27 May 1997 08:48:07 -0700 (PDT) Message-Id: <199705271548.IAA13533@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: bt848 status, comments and diffs In-reply-to: Your message of "Tue, 27 May 1997 16:00:27 GMT." <199705271600.QAA00791@info.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 1997 08:48:07 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Luigi, interlace is for ntsc interlace frames see the bt848 databook for a brief description . In your case, modifiy the driver so interlace is always equal to 1. I think that there is a variable which you can use to find out if your are running NTSC or PAL . The data structured is used in set_fps. Tonite, I will review the mods on a quick qlance they look great! Cheers, Amancio >From The Desk Of Luigi Rizzo : > Guys, > > I was looking at solving my problems (missing odd frames etc.) with > the YUV* modes, and I noticed that there are some inconsistencies > in the handling of SYNC instructions at the end of each frame etc, > especially for what regards IRQ generation. This would explain why > continuous capture modes work whereas single capture mode dont (and > perhaps signals would not work either, although tv does not use > them). > > To clean up things, and before investigating further on the problem, > I defined a few macros (OP_IRQ, OP_RESYNC) for commands which are > generally used in instructions. I also defined a macro, I2(a,b) > which I used for all occurrence of 2-word instructions. This makes > the code shorter and especially risc instructions easier to read. > > Before going on I would like to know (from Amancio perhaps): > > - what is the meaning of the 'interlace' variable ? What corresponds > to the various values (1,2,3) which it can assume ? > > - is it ok to generate an IRQ on every SYNC instruction, > and let the handler ignore it if not required ? This seems to me > the safest option (and, even if for continuous capture to the frame > buffer it might not be necessary to generate 60 irq/s, the overhead > should not be so terrible considering the amount of bus traffic > this capture generates). > > - why, in some SYNC instructions, you use 0xC << 24 ? Those > are reserved bits, but probably are SOL/EOL. Are you following > some application note, or trying to circumvent problems, or what ? > > - in modes which require full frames, I think it would be worthwile > to make frames always start on the same field (probably odd), i.e. > include an OP_SYNC | BKTR_VRO instruction at the beginning. This > would make the output more predictable and probably also remove > some artifacts which people are seeing and which might be related to > some frames starting with the odd field, some with the even field. > > In the current code you start with OP_SYNC | BKTR_FM1 (or FM3) which > does not let you know which frame are you starting with. > > I could derive the above info from the sources, but because of some > inconsistencies I would prefer a word on how things should be, rather > than look at what they are. > > Once the above things have been sorted out, it will probably be > relatively easy to fix the driver (and maybe also make it shorter). > > The diffs follow (relative to today's version from amancio). > > Cheers > Luigi > > > --- brooktree848.c.amancio Tue May 27 14:05:03 1997 > +++ brooktree848.c Tue May 27 15:38:43 1997 > @@ -2179,7 +2179,7 @@ > #define BKTR_FM3 0xe > #define BKTR_VRE 0x4 > #define BKTR_VRO 0xC > -#define BKTR_PXV 0x0 > +#define BKTR_PXV 0x0 /* never used */ > #define BKTR_EOL 0x1 > #define BKTR_SOL 0x2 > > @@ -2193,6 +2193,11 @@ > #define OP_SOL (1 << 27) > #define OP_EOL (1 << 26) > > +#define OP_IRQ (1 << 24) > +#define OP_RESYNC (1 << 15) > + > +#define I2(a, b) { *dma_prog++ = a ; *dma_prog++ = b ; } > + > bool_t notclipped (bktr_reg_t * bktr, int x, int width) { > int i; > bktr_clip_t * clip_node; > @@ -2369,11 +2374,9 @@ > buffer = target_buffer; > if (interlace == 2 && rows < 320 ) target_buffer += pitch; > > - /* contruct sync : for video packet format */ > - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM1; > + /* contruct sync : for video packed format */ > + I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); > > - /* sync, mode indicator packed data */ > - *dma_prog++ = 0; /* NULL WORD */ > width = cols; > for (i = 0; i < (rows/interlace); i++) { > target = target_buffer; > @@ -2406,28 +2409,20 @@ > switch (i_flag) { > case 1: > /* sync vre */ > - *dma_prog++ = OP_SYNC | 0xC << 24 | 1 << 24 | BKTR_VRE; > - *dma_prog++ = 0; /* NULL WORD */ > - > - *dma_prog++ = OP_JUMP | 0xC << 24; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | 0xC << 24 | OP_IRQ | BKTR_VRE, 0 ); > + I2( OP_JUMP | 0xC << 24, (u_long ) vtophys(bktr->dma_prog) ); > return; > > case 2: > /* sync vro */ > - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 20 | BKTR_VRO; > - *dma_prog++ = 0; /* NULL WORD */ > - > - *dma_prog++ = OP_JUMP; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | OP_IRQ | 1 << 20 | BKTR_VRO, 0 ); > + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); > return; > > case 3: > /* sync vro */ > - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 15 | BKTR_VRO; > - *dma_prog++ = 0; /* NULL WORD */ > - *dma_prog++ = OP_JUMP | 0xc << 24 ; > - *dma_prog = (u_long ) vtophys(bktr->odd_dma_prog); > + I2(OP_SYNC | OP_IRQ | OP_RESYNC | BKTR_VRO, 0 ); > + I2(OP_JUMP | 0xc << 24, (u_long) vtophys(bktr->odd_dma_prog)); > break; > } > > @@ -2441,8 +2436,7 @@ > > > /* sync vre IRQ bit */ > - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM1; > - *dma_prog++ = 0; /* NULL WORD */ > + I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); > width = cols; > for (i = 0; i < (rows/interlace); i++) { > target = target_buffer; > @@ -2474,10 +2468,8 @@ > } > > /* sync vre IRQ bit */ > - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 15 | BKTR_VRE; > - *dma_prog++ = 0; /* NULL WORD */ > - *dma_prog++ = OP_JUMP ; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog) ; > + I2( OP_SYNC | OP_IRQ | OP_RESYNC | BKTR_VRE, 0 ); > + I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ); > *dma_prog++ = 0; /* NULL WORD */ > } > > @@ -2531,43 +2523,34 @@ > > /* contruct sync : for video packet format */ > /* sync, mode indicator packed data */ > - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM1; > - *dma_prog++ = 0; /* NULL WORD */ > + I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); > > b = cols; > > for (i = 0; i < (rows/interlace); i++) { > - *dma_prog++ = inst; > - *dma_prog++ = target_buffer; > - *dma_prog++ = inst3; > - *dma_prog++ = target_buffer + b; > + /* XXX I don't understand why 2 instructions since b = cols */ > + I2( inst, target_buffer ); > + I2( inst3, target_buffer + b ); > target_buffer += interlace*(cols * 2); > } > > switch (i_flag) { > case 1: > /* sync vre */ > - *dma_prog++ = OP_SYNC | 0xC << 24 | BKTR_VRE; > - *dma_prog++ = 0; /* NULL WORD */ > - > - *dma_prog++ = OP_JUMP; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | 0xC << 24 | BKTR_VRE, 0 ); > + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); > return; > > case 2: > /* sync vro */ > - *dma_prog++ = OP_SYNC | 0xC << 24 | BKTR_VRO; > - *dma_prog++ = 0; /* NULL WORD */ > - *dma_prog++ = OP_JUMP; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | 0xC << 24 | BKTR_VRO, 0 ); > + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); > return; > > case 3: > /* sync vre */ > - *dma_prog++ = OP_SYNC | BKTR_VRE; > - *dma_prog++ = 0; /* NULL WORD */ > - *dma_prog++ = OP_JUMP ; > - *dma_prog = (u_long ) vtophys(bktr->odd_dma_prog); > + I2( OP_SYNC | BKTR_VRE, 0 ); > + I2( OP_JUMP,(u_long ) vtophys(bktr->odd_dma_prog) ); > break; > } > > @@ -2578,26 +2561,20 @@ > dma_prog = (u_long * ) bktr->odd_dma_prog; > > /* sync vre */ > - *dma_prog++ = OP_SYNC | 1 << 24 | 1 << 15 | BKTR_FM1; > - *dma_prog++ = 0; /* NULL WORD */ > + I2( OP_SYNC | OP_IRQ | OP_RESYNC | BKTR_FM1, 0 ); > > for (i = 0; i < (rows/interlace) ; i++) { > - *dma_prog++ = inst; > - *dma_prog++ = target_buffer; > - *dma_prog++ = inst3; > - *dma_prog++ = target_buffer + b; > + I2( inst, target_buffer ); > + I2( inst3, target_buffer + b ); > target_buffer += interlace * ( cols*2); > } > } > > /* sync vro IRQ bit */ > - *dma_prog++ = OP_SYNC | 1 << 24 | BKTR_VRE; > - *dma_prog++ = 0; /* NULL WORD */ > - *dma_prog++ = OP_JUMP ; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | OP_IRQ | BKTR_VRE, 0 ); > + I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ); > > - *dma_prog++ = OP_JUMP; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); /* XXX ??? */ > *dma_prog++ = 0; /* NULL WORD */ > } > > @@ -2655,8 +2632,7 @@ > t1 = target_buffer; > > /* contruct sync : for video packet format */ > - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM3; /*sync, mode indicato r packed data*/ > - *dma_prog++ = 0; /* NULL WORD */ > + I2( OP_SYNC | OP_RESYNC | BKTR_FM3, 0 ); > > for (i = 0; i < (rows/interlace ) - 1; i++) { > *dma_prog++ = inst; > @@ -2669,27 +2645,18 @@ > > switch (i_flag) { > case 1: > - *dma_prog++ = OP_SYNC | 0xC << 24 | 1 << 24 | BKTR_VRE; /*sy nc vre*/ > - *dma_prog++ = 0; /* NULL WORD */ > - > - *dma_prog++ = OP_JUMP | 0xc << 24; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | 0xC << 24 | OP_IRQ | BKTR_VRE, 0); /*sync vre*/ > + I2( OP_JUMP | 0xc << 24, (u_long ) vtophys(bktr->dma_prog) ); > return; > > case 2: > - *dma_prog++ = OP_SYNC | 0xC << 24 | 1 << 24 | BKTR_VRO; /*sy nc vre*/ > - *dma_prog++ = 0; /* NULL WORD */ > - > - *dma_prog++ = OP_JUMP; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog); > + I2( OP_SYNC | 0xC << 24 | OP_IRQ | BKTR_VRO, 0); /*sync vre*/ > + I2( OP_JUMP, (u_long ) vtophys(bktr->dma_prog) ); > return; > > case 3: > - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_VRO; > - *dma_prog++ = 0; /* NULL WORD */ > - > - *dma_prog++ = OP_JUMP ; > - *dma_prog = (u_long ) vtophys(bktr->odd_dma_prog); > + I2( OP_SYNC | OP_RESYNC | BKTR_VRO, 0 ); > + I2( OP_JUMP, (u_long ) vtophys(bktr->odd_dma_prog) ); > break; > } > > @@ -2699,8 +2666,7 @@ > > target_buffer = (u_long) buffer + cols; > t1 = target_buffer + cols/2; > - *dma_prog++ = OP_SYNC | 1 << 15 | BKTR_FM3; > - *dma_prog++ = 0; /* NULL WORD */ > + I2( OP_SYNC | OP_RESYNC | BKTR_FM3, 0 ); > > for (i = 0; i < (rows/interlace ) - 1; i++) { > *dma_prog++ = inst; > @@ -2712,10 +2678,8 @@ > } > } > > - *dma_prog++ = OP_SYNC | 1 << 24 | BKTR_VRE; > - *dma_prog++ = 0; /* NULL WORD */ > - *dma_prog++ = OP_JUMP ; > - *dma_prog++ = (u_long ) vtophys(bktr->dma_prog) ; > + I2( OP_SYNC | OP_IRQ | BKTR_VRE, 0 ); > + I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ) ; > *dma_prog++ = 0; /* NULL WORD */ > } > From owner-freebsd-multimedia Tue May 27 15:33:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA07616 for multimedia-outgoing; Tue, 27 May 1997 15:33:34 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id PAA07609 for ; Tue, 27 May 1997 15:33:23 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 27 May 1997 18:32:12 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA24679; Tue, 27 May 97 18:32:10 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA22545; Tue, 27 May 1997 18:31:09 -0400 Message-Id: <19970527183109.54402@ct.picker.com> Date: Tue, 27 May 1997 18:31:09 -0400 From: Randall Hopper To: Bernie Doehner Cc: multimedia@FreeBSD.ORG Subject: Re: bt848 hangups on 486's References: <19970525161804.37676@hydrogen.nike.efn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Bernie Doehner on Mon, May 26, 1997 at 11:45:52AM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bernie Doehner: |That reminds me. Something else I'd like to try is running fxtv without |DMA. Where is the list of arguments that fxtv takes? Thanks for reminding me. A "-help" option would be a good add :-) The option you want is "-disableDirectV". To get all the options (for now), do "strings fxtv | grep ^-". Basically every provided X resource (documented in the sample Fxtv app-default file) is also a command-line option. |Btw, I downloaded the RZ1000/CD640 test program, but it relies on the test |disk being msdos format which mine is not, so I can't test it. But I have |looked all over the board and not found these two chips Glad to hear it! |From Randall's comments it sure seems like fxtv is eating up too much CPU |time. Unfortunately second to last crash took out today's mail spool |file. Randall mentioned a program he used called xs* to look at X protocol |activity. Could someone please fill in the blank? XScope. Here's the URL I have saved of where where I got it: ftp://www.hds.com/hds/contrib/xscope.tar.Z By default, it sets up a virtual display on your XServer (e.g. :1.0) and channels all the X protocol to the "real" display, so it's hooked in like a protocol analyzer. Has options to let you setup other configurations. Randall From owner-freebsd-multimedia Tue May 27 16:11:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA09246 for multimedia-outgoing; Tue, 27 May 1997 16:11:59 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id QAA09237 for ; Tue, 27 May 1997 16:11:50 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id AAA16301; Wed, 28 May 1997 00:36:57 +0200 From: Luigi Rizzo Message-Id: <199705272236.AAA16301@labinfo.iet.unipi.it> Subject: Re: bt848 status, comments and diffs To: hasty@rah.star-gate.com (Amancio Hasty) Date: Wed, 28 May 1997 00:36:56 +0200 (MET DST) Cc: luigi@iet.unipi.it, multimedia@FreeBSD.ORG In-Reply-To: <199705271548.IAA13533@rah.star-gate.com> from "Amancio Hasty" at May 27, 97 08:47:48 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi Luigi, > > interlace is for ntsc interlace frames see the bt848 databook for > a brief description . In your case, modifiy the driver so interlace ok, I think I have got it. you have several different options 1. odd only; 2. even only 3. odd or even as separate fields 4. odd + even, interlaced > Tonite, I will review the mods on a quick qlance they look great! I have given a first shot at the yuvpacked code (the simpler one). I would write it as follows: yuvpacked(...) { ... init stuff ... inst = OP_WRITE | OP_SOL | OP_EOL | bt_enable_cnt << 12 | (cols*2); if (i_flag == 1 /* want even only */) I2( OP_SYNC | OP_RESYNC | BKTR_VRE, 0 ); else /* odd or full frame start with an odd field */ I2( OP_SYNC | OP_RESYNC | BKTR_VRO, 0 ); I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); for (i = 0; i < (rows/interlace) - 1; i++) { I2( inst, target_buffer ); target_buffer += interlace*cols*2; } if (interlace == 1) { /* last row, generate interrupt */ I2( inst | OP_IRQ, target_buffer ); } else { /* last row of odd field, no interrupt */ I2( inst, target_buffer ); /* want BOTH: odd done, wait even */ I2( OP_SYNC | OP_RESYNC | BKTR_VRE, 0 ); target_buffer = (u_long) buffer + cols*2; I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); for (i = 0; i < (rows/interlace) - 1 ; i++) { I2( inst, target_buffer ); target_buffer += interlace * ( cols*2); } /* generate IRQ on last row */ I2( inst | OP_IRQ, target_buffer ); } I2( OP_JUMP , (u_long ) vtophys(bktr->dma_prog) ); *dma_prog++ = 0; /* NULL WORD */ } The above code is based on the assumption that the IRQ is generated at the end of the instruction. The manual does not mention this, but I don't think it would make sense the other way round. Also, the way it is structured, it does not permit to capture both fields non interlaced (case 3 above), but that should be easy to fix. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Tue May 27 16:57:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA10624 for multimedia-outgoing; Tue, 27 May 1997 16:57:59 -0700 (PDT) Received: from uhf.wdc.net (uhf.4d.net [207.137.157.140]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA10617 for ; Tue, 27 May 1997 16:57:51 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id TAA01299; Tue, 27 May 1997 19:58:50 -0400 (EDT) Date: Tue, 27 May 1997 19:58:49 -0400 (EDT) From: Bernie Doehner To: multimedia@freebsd.org, rhh@ct.picker.com, hasty@rah.star-gate.com Subject: DMA and fxtv. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Gang: FINALLY getting somewhere. I just ran fxtv with the -noDirectV switch and it was rock solid. Interactive response time was horrible, but I didn't lose any frames, picture was sharp, and NO CRASHES. At least I can live with this for the time being. Bernie From owner-freebsd-multimedia Tue May 27 20:20:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA19612 for multimedia-outgoing; Tue, 27 May 1997 20:20:13 -0700 (PDT) Received: from www.ina.com (root@ina.com [207.88.163.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA19601 for ; Tue, 27 May 1997 20:20:10 -0700 (PDT) Received: from www.ina.com (al@ina.com [207.88.163.18]) by www.ina.com (8.8.5/8.6.9) with SMTP id UAA04874 for ; Tue, 27 May 1997 20:41:29 -0700 (PDT) Date: Tue, 27 May 1997 20:41:29 -0700 (PDT) From: Alfredo Lusa To: multimedia@freebsd.org Subject: subscribe Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk subscribe al@ina.com From owner-freebsd-multimedia Wed May 28 03:30:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA05288 for multimedia-outgoing; Wed, 28 May 1997 03:30:20 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id DAA05283 for ; Wed, 28 May 1997 03:30:18 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Wed, 28 May 1997 6:26:45 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA04330; Wed, 28 May 97 06:26:44 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id GAA22891; Wed, 28 May 1997 06:25:41 -0400 Message-Id: <19970528062541.49315@ct.picker.com> Date: Wed, 28 May 1997 06:25:41 -0400 From: Randall Hopper To: Bernie Doehner Cc: multimedia@FreeBSD.ORG Subject: Re: DMA and fxtv. References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Bernie Doehner on Tue, May 27, 1997 at 07:58:49PM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bernie Doehner: |FINALLY getting somewhere. I just ran fxtv with the -noDirectV switch and |it was rock solid. Interactive response time was horrible, but I didn't |lose any frames, picture was sharp, and NO CRASHES. | |At least I can live with this for the time being. Good deal! If it's eating too much CPU, bump up the FRAME_TIMER_DELAY_MS setting (#define at the top of tvcapture.c). This'll slow down the rate at which the frames are grabbed from the driver buffer. Now as far as analyzing why this doesn't crash you...hmmm. It's interesting. 30fps are still being kicked out by your TV card. However, it's not remaining only on the PCI bus, blasting onto your video card directly; it's being forced into the memory bus and dumped in the driver's capture buffer. This is then being sampled periodically by fxtv, coaxed into an XImage, and tossed to the XServer that then blits it to the frame buffer. What's interesting is it seems there'd be just as much PCI traffic in both cases--even a bit more in the non-direct-video case because the occasional upstream ximage blit has to compete with the downstream video from the TV card. Something just strange about PCI-to-PCI DMA on your MB chipset or your Stealth 3D 2000 I guess. Randall From owner-freebsd-multimedia Wed May 28 05:00:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA08229 for multimedia-outgoing; Wed, 28 May 1997 05:00:25 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id FAA08224 for ; Wed, 28 May 1997 05:00:21 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA17044; Wed, 28 May 1997 13:24:46 +0200 From: Luigi Rizzo Message-Id: <199705281124.NAA17044@labinfo.iet.unipi.it> Subject: Re: bt848 status, comments and diffs To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 28 May 1997 13:24:46 +0200 (MET DST) Cc: hasty@rah.star-gate.com, luigi@iet.unipi.it, multimedia@FreeBSD.ORG In-Reply-To: <199705272236.AAA16301@labinfo.iet.unipi.it> from "Luigi Rizzo" at May 28, 97 00:36:37 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Yet another version of brooktree848.c with the cleanups I was mentioning in my previous postings. The code is available at http://www.iet.unipi.it/~luigi/brooktree848.c I have tested it and it seems to work in both packed and planar mode, with single frame capture. It works with the old and the new grabber-meteor.cc Try it if you can, and send feedback. I have left the rgb_ code untouched, since amancio is probably working on that. In passing, I noticed that the clipping features of the Bt848 are quite powerful. A better way to exploit them would be, probably, to let the application program pass the clipping shape in raster format, rather than pass it as a set of rectangles. This would allow complex figures (e.g. clipping into circles, ovals etc. which are not possible now, and do not require time-consuming computations from the kernel like sorting rectangles etc. Basically, I would describe a clipping shape as a sequence of lines BEGIN (skip n1 write n2) * (one per row in the output) and let the driver just translate this into Bt848 instructions. The above description can be as small as 32 bit/row. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Wed May 28 08:09:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA15061 for multimedia-outgoing; Wed, 28 May 1997 08:09:35 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA15053 for ; Wed, 28 May 1997 08:09:29 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id IAA24013; Wed, 28 May 1997 08:03:20 -0700 (PDT) Message-Id: <199705281503.IAA24013@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Luigi Rizzo cc: luigi@iet.unipi.it, multimedia@FreeBSD.ORG Subject: Re: bt848 status, comments and diffs In-reply-to: Your message of "Wed, 28 May 1997 13:24:46 +0200." <199705281124.NAA17044@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 1997 08:03:19 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Luigi, I am going to work on your mods is just that I am on my regular work schedule. As for your clipping idea , the existing clipping algorithm was designed for ease of programmability specially with respect to X. I decided to leave the smarts to the driver rather than to the programmer. As it is today no one is using the clipping code even though is pretty easy to use. The good thing about the existing scenario is that no one is using the clipping code;hence, we can provide both methods . Last but not least lets shoot for a checking by Monday . Not that interested in having various versions of the Bt848 driver floating around. I was planning to checking the existing code at my ftp site by this Friday however given that your mods are useful and not that hard to implement is best to attempt to test them now . Regards, Amancio >From The Desk Of Luigi Rizzo : > Yet another version of brooktree848.c with the cleanups I was > mentioning in my previous postings. The code is available at > > http://www.iet.unipi.it/~luigi/brooktree848.c > > I have tested it and it seems to work in both packed and planar mode, > with single frame capture. It works with the old and the new > grabber-meteor.cc > > Try it if you can, and send feedback. > > I have left the rgb_ code untouched, since amancio is probably working > on that. In passing, I noticed that the clipping features of the Bt848 > are quite powerful. A better way to exploit them would be, probably, to > let the application program pass the clipping shape in raster format, > rather than pass it as a set of rectangles. This would allow complex > figures (e.g. clipping into circles, ovals etc. which are not possible > now, and do not require time-consuming computations from the kernel like > sorting rectangles etc. > > Basically, I would describe a clipping shape as a sequence of lines > > BEGIN (skip n1 write n2) * > > (one per row in the output) and let the driver just translate this into > Bt848 instructions. The above description can be as small as 32 bit/row. > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ From owner-freebsd-multimedia Wed May 28 08:39:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA16380 for multimedia-outgoing; Wed, 28 May 1997 08:39:42 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA16375 for ; Wed, 28 May 1997 08:39:40 -0700 (PDT) Received: from gaia.coppe.ufrj.br (root@[146.164.5.200]) by agora.rdrop.com (8.8.5/8.8.5) with ESMTP id IAA03295 for ; Wed, 28 May 1997 08:39:31 -0700 (PDT) Received: (from jonny@localhost) by gaia.coppe.ufrj.br (8.8.5/8.7.3) id MAA13437; Wed, 28 May 1997 12:38:02 -0300 (EST) From: Joao Carlos Mendes Luis Message-Id: <199705281538.MAA13437@gaia.coppe.ufrj.br> Subject: ATI-TV Chipset To: multimedia@freebsd.org Date: Wed, 28 May 1997 12:38:02 -0300 (EST) X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, We finally received our ATI All-In-Wonder, a combo of 3D Expression (Rage II) and ATI TV in just one slot. For those (Amancio) who asked about the chipset here's the info I could get from the diagnostic program: Tuner: Philips FI1236 NTSC M/N Decoder: Bt829 This board can decode NTSC, PAL/M (Brasil's TV system, yeah !!!) and PAL/N. It can receive TV and cable broadcasts, composite video and S-Video. Now the questions: how "compatible" is Bt829 with Bt848 ??? :) Also, how important is the glue logic to the operation of the system as a whole ? Jonny -- Joao Carlos Mendes Luis jonny@gta.ufrj.br +55 21 290-4698 ( Job ) jonny@cisi.coppe.ufrj.br Network Manager UFRJ/COPPE/CISI Universidade Federal do Rio de Janeiro From owner-freebsd-multimedia Wed May 28 13:57:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA02414 for multimedia-outgoing; Wed, 28 May 1997 13:57:41 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA02409 for ; Wed, 28 May 1997 13:57:38 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id WAA17660 for multimedia@FreeBSD.ORG; Wed, 28 May 1997 22:23:16 +0200 From: Luigi Rizzo Message-Id: <199705282023.WAA17660@labinfo.iet.unipi.it> Subject: Re: bt848 status, comments and diffs To: multimedia@FreeBSD.ORG Date: Wed, 28 May 1997 22:23:15 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi Luigi, > > I am going to work on your mods is just that I am on my regular > work schedule. great. I'll leave my latest source at http://www.iet.unipi.it/~luigi/bt848.tgz they include sys/pci/brktree_reg.h sys/pci/brooktree848.c sys/i386/include/ioctl_bt848.h just get it when you are ready to work on them. They have kind of stabilized now, since I have reliable yuv packed and planar mode in single frame capture, plus working support to decode Teletext in software (I had to disable the various lowpass filters on the Y component), so I will not make intrusive changes to the code anymore. > As for your clipping idea , the existing clipping algorithm was > designed for ease of programmability specially with respect to > X. I decided to leave the smarts to the driver rather than > to the programmer. As it is today no one is using the clipping code > even though is pretty easy to use. > > The good thing about the existing scenario is that no one is using > the clipping code;hence, we can provide both methods . and I am not going to use it either, at least for the time being. Now that I am becoming familiar with the Bt848 code I might try to write some code to support the native VIC format (whatever it is). > Last but not least lets shoot for a checking by Monday . Not that interested > in having various versions of the Bt848 driver floating around. agreed. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Wed May 28 14:28:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA04088 for multimedia-outgoing; Wed, 28 May 1997 14:28:45 -0700 (PDT) Received: from mail.jax.bellsouth.net (mail.jax.bellsouth.net [205.152.64.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA04075 for ; Wed, 28 May 1997 14:28:34 -0700 (PDT) Received: from kbpwrsys.bellsouth.com (host-207-53-88-83.jax.bellsouth.net [207.53.88.83]) by mail.jax.bellsouth.net (8.8.5/8.8.5) with SMTP id RAA14635 for ; Wed, 28 May 1997 17:28:54 -0400 (EDT) Message-ID: <338CA3BF.41C67EA6@ix.netcom.com> Date: Wed, 28 May 1997 17:29:35 -0400 From: Ted Knight Organization: AbFabInc X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: multimedia@FreeBSD.ORG Subject: NAS with an original GUS card Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I need some help getting NAS running on FBSD 2.2.1R with an original UltraSound card. I have tried everything I can get fromn the "docs" to start the server with no success. If anyone has NAS running with the UltraSound (original), I'd appreciate seeing your AUVoxConfig file and hearing what you did to get NAS running. Can someone help? the following is my error message: au :0& [2] 445 kbpwrsys# Fatal server error: could not create audio connection block info Thanks, Ted Knight From owner-freebsd-multimedia Wed May 28 14:35:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA04523 for multimedia-outgoing; Wed, 28 May 1997 14:35:16 -0700 (PDT) Received: from hydrogen.nike.efn.org (resnet.uoregon.edu [128.223.170.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA04513 for ; Wed, 28 May 1997 14:35:10 -0700 (PDT) Received: (from jmg@localhost) by hydrogen.nike.efn.org (8.8.5/8.8.5) id OAA02544; Wed, 28 May 1997 14:37:27 -0700 (PDT) Message-ID: <19970528143727.32928@hydrogen.nike.efn.org> Date: Wed, 28 May 1997 14:37:27 -0700 From: John-Mark Gurney To: Randall Hopper Cc: Bernie Doehner , multimedia@FreeBSD.ORG Subject: Re: DMA and fxtv. References: <19970528062541.49315@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.69 In-Reply-To: <19970528062541.49315@ct.picker.com>; from Randall Hopper on Wed, May 28, 1997 at 06:25:41AM -0400 Reply-To: John-Mark Gurney Organization: Cu Networking X-Operating-System: FreeBSD 2.2.1-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Randall Hopper scribbled this message on May 28: > Bernie Doehner: > |FINALLY getting somewhere. I just ran fxtv with the -noDirectV switch and > |it was rock solid. Interactive response time was horrible, but I didn't > |lose any frames, picture was sharp, and NO CRASHES. > | > |At least I can live with this for the time being. > > Good deal! If it's eating too much CPU, bump up the FRAME_TIMER_DELAY_MS > setting (#define at the top of tvcapture.c). This'll slow down the rate at > which the frames are grabbed from the driver buffer. actually... this doesn't seem to help.. and it's probably the same reason fxtv doesn't go to sleep when the Bt848 is writing directly to video memory... > Now as far as analyzing why this doesn't crash you...hmmm. It's > interesting. 30fps are still being kicked out by your TV card. However, > it's not remaining only on the PCI bus, blasting onto your video card > directly; it's being forced into the memory bus and dumped in the driver's > capture buffer. This is then being sampled periodically by fxtv, coaxed > into an XImage, and tossed to the XServer that then blits it to the frame > buffer. this is interesting to as XImage mode works for me too... maybe it's the video card that isn't handling the stream well or being out of spec then messing up the bus... hmm... don't somebody on hackers/current have a pci bus analyzer? > What's interesting is it seems there'd be just as much PCI traffic in both > cases--even a bit more in the non-direct-video case because the occasional > upstream ximage blit has to compete with the downstream video from the TV > card. Something just strange about PCI-to-PCI DMA on your MB chipset or > your Stealth 3D 2000 I guess. hmm.. guess this points more to the video card if we can watch Ximage video fine... -- John-Mark Gurney Modem/FAX: +1 541 683 6954 Cu Networking Live in Peace, destroy Micro$oft, support free software, run FreeBSD From owner-freebsd-multimedia Thu May 29 04:59:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA08969 for multimedia-outgoing; Thu, 29 May 1997 04:59:57 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA08960 for ; Thu, 29 May 1997 04:59:49 -0700 (PDT) Received: from bagpuss.visint.co.uk (bagpuss.vis.net.uk [194.207.134.1]) by bagpuss.visint.co.uk (8.7.5/8.7.3) with SMTP id NAA08329 for ; Thu, 29 May 1997 13:01:36 +0100 (BST) Date: Thu, 29 May 1997 13:01:36 +0100 (BST) From: Stephen Roome To: multimedia@freebsd.org Subject: CDI development/authoring. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I want to do some CDI development and authoring. I know that FreeBSD doesn't have much (anything) in this dept. but I thought some of you might be able to point me in the right direction as to what I need. Basically, I've got a dead Sun SS1+ attached to a phillips CDI emulator. The Sun runs some proprietry software which talks to the emulator and cdi player through serial ports (I think?) and SCSI. We can't afford a new Sun (and I'd like to bin the SS1+ !) and I don't think I can get the source to port this either. =( I have the CDI specs and most of the specs on the emulator so in theory *could* write this for FreeBSD. So, I either need a SunOS 4.1.1 emulator ?? (doubtful) or someone who knows more than me to suggest some way of going about this. Any hints or pointers ? I'd like to be able to do this on FreeBSD, but I haven't got the faintest idea how difficult it would be to write CDI's from FreeBSD.. If it's possible, then how long would it take to write this and has anyone started this sort of thing before ? Steve (stressed) -- Steve Roome - Vision Interactive Ltd. E: steve@visint.co.uk M: +44 (0) 976 241 342 T: +44 (0) 117 973 0597 F: +44 (0) 117 923 8522 He who has a dog to worship him should have a cat to ignore him From owner-freebsd-multimedia Thu May 29 06:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA12423 for multimedia-outgoing; Thu, 29 May 1997 06:21:23 -0700 (PDT) Received: from x14.boston.juno.com (x14.boston.juno.com [205.231.101.27]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA12416 for ; Thu, 29 May 1997 06:21:21 -0700 (PDT) Received: (from n9ogk@juno.com) by x14.boston.juno.com (queuemail) id JsH22984; Thu, 29 May 1997 09:20:26 EDT To: freebsd-multimedia@freebsd.org Subject: audio-related (audio CD loudness, rtprio au) Message-ID: <19970529.081153.11854.0.N9OGK@juno.com> X-Mailer: Juno 1.15 X-Juno-Line-Breaks: 0-1,6-7,10-11,17-18,20-26 From: n9ogk@juno.com (Jack W Doyle) Date: Thu, 29 May 1997 09:20:26 EDT Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a few questions: 1) In Lose95, the audio CD output is quite loud and scratchy (scratchiness is from the driver in Lose95 -- I'm not worried about it), but in FreeBSD 2.1.7, I have to turn up the volume so I can hear it. Is it due to my SB16 card, or is there a way to tell it what MIN_VOL value to use in relation to MAX_VOL? I am using xcdplayer. 2) This is somewhat related to above question, but not entirely. Is it possible to use 'rtprio 3 au -audio :0' and then have the audio server look up user-defined settings for the audio server? 3) How do I get sound output to work on games like xboing, xgalaga, and other X games? Currently, I've been able to get the sound to work on xboing only once and that's it. I did this by using the -debug option, but was not able to repeat the effect. Otherwise it says it has problems writing to sound device and being unable to flush sound device (yes the soundcard is configured properly). 4) Is there a better approach to having sound than using NAS for a single-user machine? I appreciate having my questions answered. Thanks in advance. Jack The faster your computer is, the slower your life becomes. From owner-freebsd-multimedia Thu May 29 19:29:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23629 for multimedia-outgoing; Thu, 29 May 1997 19:29:49 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23624 for ; Thu, 29 May 1997 19:29:46 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id TAA00452; Thu, 29 May 1997 19:29:26 -0700 (PDT) Message-Id: <199705300229.TAA00452@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Luigi Rizzo cc: luigi@iet.unipi.it, multimedia@FreeBSD.ORG Subject: Re: bt848 status, comments and diffs In-reply-to: Your message of "Wed, 28 May 1997 13:24:46 +0200." <199705281124.NAA17044@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 1997 19:29:26 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Tnks Luigi! Your mods look really good. How is vic with Van Jacobson's version of grabber-meteor.cc running over there? I will prepare patches against -current tomorrow. Got a little bug with yuv422 to chase over here. The plan is to post the patches tomorrow and Monday nite if all goes well submit the patches to -current and to linux . Cheers, Amancio >From The Desk Of Luigi Rizzo : > Yet another version of brooktree848.c with the cleanups I was > mentioning in my previous postings. The code is available at > > http://www.iet.unipi.it/~luigi/brooktree848.c > > I have tested it and it seems to work in both packed and planar mode, > with single frame capture. It works with the old and the new > grabber-meteor.cc > > Try it if you can, and send feedback. > > I have left the rgb_ code untouched, since amancio is probably working > on that. In passing, I noticed that the clipping features of the Bt848 > are quite powerful. A better way to exploit them would be, probably, to > let the application program pass the clipping shape in raster format, > rather than pass it as a set of rectangles. This would allow complex > figures (e.g. clipping into circles, ovals etc. which are not possible > now, and do not require time-consuming computations from the kernel like > sorting rectangles etc. > > Basically, I would describe a clipping shape as a sequence of lines > > BEGIN (skip n1 write n2) * > > (one per row in the output) and let the driver just translate this into > Bt848 instructions. The above description can be as small as 32 bit/row. > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ From owner-freebsd-multimedia Fri May 30 00:41:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA04859 for multimedia-outgoing; Fri, 30 May 1997 00:41:15 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA04854 for ; Fri, 30 May 1997 00:41:11 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id AAA00894; Fri, 30 May 1997 00:36:12 -0700 (PDT) Message-Id: <199705300736.AAA00894@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: bt848 status, comments and diffs In-reply-to: Your message of "Wed, 28 May 1997 13:24:46 +0200." <199705281124.NAA17044@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 1997 00:36:12 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Luigi, Video capture starts by first waiting on a mode change FM1 or FM3 . It took me a while to spot that error. BT848 data book page 46: "The first field begins with a synchronization instruction (SYNC) indicating PACKED or PLANAR data from the FIFO...." You have : printf("bktr: yuvpack_prog, i_flag %d, interlace %d, rows %d, cols %d\n", i_flag, interlace, rows, cols); /* first: wait for start of even/odd field */ if (i_flag == 1 /* want even only */) { I2( OP_SYNC | OP_RESYNC | BKTR_VRE, 0 ); } else { I2( OP_SYNC | OP_RESYNC | BKTR_VRO, 0 ); } /* sync, wait for packed data */ I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); ---- It should be : /* sync, wait for packed data */ I2( OP_SYNC | OP_RESYNC | BKTR_FM1, 0 ); for (i = 0; i < (rows/interlace) - 1; i++) { I2( inst, target_buffer ); target_buffer += b ; } if (i_flag == 1 /* want even only */) { I2( OP_SYNC | OP_RESYNC | BKTR_VRE, 0 ); } if { i_flag == 2 /* want odd only */ ) { I2( OP_SYNC | OP_RESYNC | BKTR_VRO, 0 ); } if { i_flag == 3 /* even field follows */ ) { I2( OP_SYNC | OP_RESYNC | BKTR_VRO, 0 ); } I think this was my yuv422 bug and it applies to the yuv pack mode Will post the patches tomorrow. Enjoy, Amancio >From The Desk Of Luigi Rizzo : > Yet another version of brooktree848.c with the cleanups I was > mentioning in my previous postings. The code is available at > > http://www.iet.unipi.it/~luigi/brooktree848.c > > I have tested it and it seems to work in both packed and planar mode, > with single frame capture. It works with the old and the new > grabber-meteor.cc > > Try it if you can, and send feedback. > > I have left the rgb_ code untouched, since amancio is probably working > on that. In passing, I noticed that the clipping features of the Bt848 > are quite powerful. A better way to exploit them would be, probably, to > let the application program pass the clipping shape in raster format, > rather than pass it as a set of rectangles. This would allow complex > figures (e.g. clipping into circles, ovals etc. which are not possible > now, and do not require time-consuming computations from the kernel like > sorting rectangles etc. > > Basically, I would describe a clipping shape as a sequence of lines > > BEGIN (skip n1 write n2) * > > (one per row in the output) and let the driver just translate this into > Bt848 instructions. The above description can be as small as 32 bit/row. > > Cheers > Luigi > -----------------------------+-------------------------------------- > Luigi Rizzo | Dip. di Ingegneria dell'Informazione > email: luigi@iet.unipi.it | Universita' di Pisa > tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) > fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ > _____________________________|______________________________________ From owner-freebsd-multimedia Fri May 30 00:49:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05065 for multimedia-outgoing; Fri, 30 May 1997 00:49:25 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA05060 for ; Fri, 30 May 1997 00:49:12 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id JAA19997; Fri, 30 May 1997 09:06:42 +0200 From: Luigi Rizzo Message-Id: <199705300706.JAA19997@labinfo.iet.unipi.it> Subject: Re: bt848 status, comments and diffs To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 30 May 1997 09:06:41 +0200 (MET DST) Cc: luigi@iet.unipi.it, multimedia@FreeBSD.ORG In-Reply-To: <199705300229.TAA00452@rah.star-gate.com> from "Amancio Hasty" at May 29, 97 07:29:07 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > Tnks Luigi! > > Your mods look really good. > > How is vic with Van Jacobson's version of grabber-meteor.cc running > over there? Both the old one (planar ?) and the new one (packed ?) work well. Two minor things with the new driver: - I think it still uses continuous capture, not really single frame capture, despite the message from Van Jacobson said differently. - the latest grabber-meteor.cc somehow truncates the left&right edges of the image when in PAL mode. It seems to grab at 288x352, and then possibly shrinks the image to 320 pixels. I have not investigated further on the problem though. One more difficulty I had with video stuff in general is that NTSC is the default everywhere, and at times in the form of hidden constants (e.g. in bktr you bzero a 640x480 area somewhere), so occasionally there are some mismatches, especially when applications start. In the driver, perhaps it would be nice to have a "DEFAULT_SETTING" macro which can be instantiated to either NTSC or PAL and do the right thing on initialization and open. I was even wondering if it was the case to have a sysctl variable (kern.video.defaultformat) to specify this, since it affects all grabbers. > I will prepare patches against -current tomorrow. Got a little > bug with yuv422 to chase over here. I tried to post you in the past days but messages bouced back... the latest version of my sources, with some additional (minor) cleanups wrt the version you grabbed, is at http://www.iet.unipi.it/~luigi/bt848.tgz Before working on the code yourself to fix yuv422 you might try to get that one -- I will not make any more changes on that code. I have added a couple of ioctls to get/set the luma lowpass filters, which I needed for extracting teletext data. > The plan is to post the patches tomorrow and Monday nite if all goes well > submit the patches to -current and to linux . while you are at it, and if it is not too much wourk, could you try to write a minimal manpage and (perhaps) implement read() ? This would make it possible to import the sources in the -stable branch, which IMHO would be a good idea since we could have more feedback, especially from people here in Europe. I am running the code on a 2.2.1 system and have not experienced a single hangup of the machine (the yuv_packed code did even work right at the first shot, something which impressed me!) Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Fri May 30 04:14:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA11237 for multimedia-outgoing; Fri, 30 May 1997 04:14:36 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA11231 for ; Fri, 30 May 1997 04:14:33 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 30 May 1997 7:13:26 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA04770; Fri, 30 May 97 07:13:23 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA08626; Fri, 30 May 1997 07:12:19 -0400 Message-Id: <19970530071218.17682@ct.picker.com> Date: Fri, 30 May 1997 07:12:18 -0400 From: Randall Hopper To: Jack W Doyle Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: audio-related (audio CD loudness, rtprio au) References: <19970529.081153.11854.0.N9OGK@juno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <19970529.081153.11854.0.N9OGK@juno.com>; from Jack W Doyle on Thu, May 29, 1997 at 09:20:26AM -0500 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Jack W Doyle: |but in FreeBSD 2.1.7, I have to turn up the volume so I can hear it. Is |it due to my SB16 card, or is there a way to tell it what MIN_VOL value |to use in relation to MAX_VOL? I am using xcdplayer. On some soundcards like yours and mine (as I recall), Voxware doesn't default the volume too high for the CD input. If you want it to default higher, try putting an invocation of /usr/sbin/mixer in your /etc/rc.local. I'm not sitting at my PC right now, but usage is pretty straightforward: mixer vol 50 to adjust the global card volume mixer pcm 50 to be selective and just affect PCM. But you want the CD input volume. I'd guess that's "cd", but do a "man mixer" to be sure. |2) This is somewhat related to above question, but not entirely. Is it |possible to use 'rtprio 3 au -audio :0' and then have the audio |server look up user-defined settings for the audio server? | |3) How do I get sound output to work on games like xboing, xgalaga, and |other X games? Currently, I've been able to get the sound to work on |xboing only once and that's it. I did this by using the -debug option, |but was not able to repeat the effect. Otherwise it says it has problems |writing to sound device and being unable to flush sound device (yes the |soundcard is configured properly). Don't know #2, but it gives a clue about #3. If you run some type of sound server, you either have to kill it before running games that directly access the sound devices, or you have to make the server close the audio device when its not using it, and just open it on an as-needed basis. Otherwise, other sound apps just get an EBUSY when trying to open it. rplayd has options to support this, but some other servers (e.g. NAS last time I checked) don't by default so either killing that server or patching its source is required to get it to let go of the audio device. (I recall somebody posting said patches for NAS a while back; might grep the mail archives at www.freebsd.org/search.html if they're not in the default NAS package yet). |4) Is there a better approach to having sound than using NAS for a |single-user machine? Might check out rplayd. It'll let go of the audio device and works reasonably well (for my uses anyway). Randall From owner-freebsd-multimedia Fri May 30 04:35:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA11990 for multimedia-outgoing; Fri, 30 May 1997 04:35:36 -0700 (PDT) Received: from Campino.Informatik.RWTH-Aachen.DE (campino.Informatik.RWTH-Aachen.DE [137.226.116.240]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA11985 for ; Fri, 30 May 1997 04:35:33 -0700 (PDT) Received: from gil.physik.rwth-aachen.de (gilberto.physik.rwth-aachen.de [137.226.31.2]) by Campino.Informatik.RWTH-Aachen.DE (RBI-Z-5/8.6.12) with ESMTP id NAA05451 for ; Fri, 30 May 1997 13:35:32 +0200 (MET DST) Received: (from kuku@localhost) by gil.physik.rwth-aachen.de (8.8.5/8.6.9) id NAA17800 for multimedia@freebsd.org; Fri, 30 May 1997 13:38:50 +0200 (MEST) Date: Fri, 30 May 1997 13:38:50 +0200 (MEST) From: Christoph Kukulies Message-Id: <199705301138.NAA17800@gil.physik.rwth-aachen.de> To: multimedia@freebsd.org Subject: QSeeMee Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Just for those who are interested: http://www.pangea.org/~mavilar/qseeme/qseeme.html I downloaded the binary (no sources seem to be available) and at least it pops up fine under FreeBSD 3.0-current with linux emu. Though strange error messages occur and it doesn't seem to function properly. -- Chris Christoph P. U. Kukulies kuku@gil.physik.rwth-aachen.de From owner-freebsd-multimedia Fri May 30 08:09:37 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA19916 for multimedia-outgoing; Fri, 30 May 1997 08:09:37 -0700 (PDT) Received: from mail.jax.bellsouth.net (mail.jax.bellsouth.net [205.152.64.21]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA19907 for ; Fri, 30 May 1997 08:09:31 -0700 (PDT) Received: from kbpwrsys.bellsouth.com (host-207-53-88-25.jax.bellsouth.net [207.53.88.25]) by mail.jax.bellsouth.net (8.8.5/8.8.5) with SMTP id LAA02318; Fri, 30 May 1997 11:09:49 -0400 (EDT) Message-ID: <338EEDE8.41C67EA6@ix.netcom.com> Date: Fri, 30 May 1997 11:10:32 -0400 From: Ted Knight Organization: AbFabInc X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: multimedia@FreeBSD.ORG CC: Amancio Hasty Subject: NAS voxware gravis ultrasound card Content-Type: multipart/mixed; boundary="------------446B9B3D2781E494167EB0E7" Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------446B9B3D2781E494167EB0E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Amancio, rah.star-gate.com seems not to be connected to the world. I want to usae Festival with NAS so I can get some fairly decent sound. I am having trouble getting the NAS server started. I have attached the output of cat /dev/sndstat and kdump of ktrace of au -aa The kdump indicates that /dev/audio is busy. I cant see how this is so. Can you help me get the NAS server running. I am running FBSD 2.2.1 and an original Ultrasound card which is forking fine on other application. I am sure this is not as gee whiz as the bt848 to you, however, I need some help here. Thanks, Ted Knight --------------446B9B3D2781E494167EB0E7 Content-Type: text/plain; charset=us-ascii; name="sndstat.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="sndstat.out" VoxWare Sound Driver:3.0-beta-950506 (Sun Feb 5 14:38:12 EST 1995 freebsd-hackers@freefall.cdrom.com) Config options: ffffffff Installed drivers: Type 4: Gravis Ultrasound Card config: Gravis Ultrasound at 0x220 irq 12 drq 1 Audio devices: 0: Gravis UltraSound Synth devices: 0: Gravis UltraSound 3.7 (1024k) Midi devices: 0: Gravis UltraSound Midi Timers: 0: System Timer 1: OPL-3/GUS Timer Mixers: 0: ICS2101 Multimedia Mixer --------------446B9B3D2781E494167EB0E7 Content-Type: text/plain; charset=iso-8859-1; name="kdump.out" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="kdump.out" 256 ktrace RET ktrace 0 256 ktrace CALL readlink(0x8066eaa,0xefbfd388,0x3f) 256 ktrace NAMI "/etc/malloc.conf" 256 ktrace RET readlink -1 errno 2 No such file or directory 256 ktrace CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) 256 ktrace RET mmap 134324224/0x801a000 256 ktrace CALL break(0x5000) 256 ktrace RET break 0 256 ktrace CALL break(0x6000) 256 ktrace RET break 0 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/sbin/au" 256 ktrace RET execve -1 errno 2 No such file or directory 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/usr/sbin/au" 256 ktrace RET execve -1 errno 2 No such file or directory 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/usr/local/sbin/au" 256 ktrace RET execve -1 errno 2 No such file or directory 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/bin/au" 256 ktrace RET execve -1 errno 2 No such file or directory 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/usr/bin/au" 256 ktrace RET execve -1 errno 2 No such file or directory 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/usr/local/bin/au" 256 ktrace RET execve -1 errno 2 No such file or directory 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) 256 ktrace NAMI "/usr/X11R6/bin/au" 256 auvoxware RET execve 0 256 auvoxware CALL open(0x109c,0,0) 256 auvoxware NAMI "/usr/libexec/ld.so" 256 auvoxware RET open 3 256 auvoxware CALL read(0x3,0xefbfd8b8,0x20) 256 auvoxware GIO fd 3 read 32 bytes "=CC\0\M^F=C0\0=D0\0\0\0 \0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0= \0" 256 auvoxware RET read 32/0x20 256 auvoxware CALL mmap(0,0xd000,0x5,0x2,0x3,0,0,0) 256 auvoxware RET mmap 134311936/0x8017000 256 auvoxware CALL mmap(0x8024000,0x2000,0x3,0x12,0x3,0,0xd000,0) 256 auvoxware RET mmap 134365184/0x8024000 256 auvoxware CALL getuid 256 auvoxware RET getuid 0 256 auvoxware CALL geteuid 256 auvoxware RET geteuid 0 256 auvoxware CALL getgid 256 auvoxware RET getgid 0 256 auvoxware CALL getegid 256 auvoxware RET getegid 0 256 auvoxware CALL __sysctl(0xefbfd80c,0x2,0x80258bc,0xefbfd814,0,0) 256 auvoxware RET __sysctl 0 256 auvoxware CALL mmap(0,0x8000,0x3,0x1002,0xffffffff,0,0,0) 256 auvoxware RET mmap 134373376/0x8026000 256 auvoxware CALL open(0x8018a82,0,0) 256 auvoxware NAMI "/var/run/ld.so.hints" 256 auvoxware RET open 4 256 auvoxware CALL read(0x4,0xefbfd7f8,0x20) 256 auvoxware GIO fd 4 read 32 bytes "iHDL\^B\0\0\0 \0\0\0007\0\0\0p \0\0\^N\a\0\0~\^Q\0\0=D7\^F\0\0" 256 auvoxware RET read 32/0x20 256 auvoxware CALL mmap(0,0x117e,0x1,0x1,0x4,0,0,0) 256 auvoxware RET mmap 134406144/0x802e000 256 auvoxware CALL close(0x4) 256 auvoxware RET close 0 256 auvoxware CALL stat(0x802ea72,0xefbfd7ac) 256 auvoxware NAMI "/usr/lib/libc.so.3.0" 256 auvoxware RET stat 0 256 auvoxware CALL stat(0x80290a0,0xefbfd7d4) 256 auvoxware NAMI "/usr/lib/libc.so.3.0" 256 auvoxware RET stat 0 256 auvoxware CALL open(0x80290a0,0,0) 256 auvoxware NAMI "/usr/lib/libc.so.3.0" 256 auvoxware RET open 4 256 auvoxware CALL read(0x4,0xefbfd7b4,0x20) 256 auvoxware GIO fd 4 read 32 bytes "=CC\0\M^F=C0\0\M^P\^E\0\0@\0\0\^P=C7\0\0\^D2\0\0 \0\0\0\0\0\0\0\0= \0\0\0" 256 auvoxware RET read 32/0x20 256 auvoxware CALL mmap(0,0x69710,0x5,0x2,0x4,0,0,0) 256 auvoxware RET mmap 134414336/0x8030000 256 auvoxware CALL close(0x4) 256 auvoxware RET close 0 256 auvoxware CALL mprotect(0x8089000,0x4000,0x7) 256 auvoxware RET mprotect 0 256 auvoxware CALL mmap(0x808d000,0xc710,0x7,0x1012,0xffffffff,0,0,0)= 256 auvoxware RET mmap 134795264/0x808d000 256 auvoxware CALL mmap(0,0xa000,0x3,0x1002,0xffffffff,0,0,0) 256 auvoxware RET mmap 134848512/0x809a000 256 auvoxware CALL munmap(0x802e000,0x117e) 256 auvoxware RET munmap 0 256 auvoxware CALL close(0x3) 256 auvoxware RET close 0 256 auvoxware CALL close(0) 256 auvoxware RET close 0 256 auvoxware CALL close(0x1) 256 auvoxware RET close 0 256 auvoxware CALL write(0x2,0xefbfd4e0,0) 256 auvoxware GIO fd 2 wrote 0 bytes "" 256 auvoxware RET write 0 256 auvoxware CALL getpgrp 256 auvoxware RET getpgrp 256/0x100 256 auvoxware CALL getdtablesize 256 auvoxware RET getdtablesize 64/0x40 256 auvoxware CALL socket(0x2,0x1,0) 256 auvoxware RET socket 0 256 auvoxware CALL setsockopt(0,0xffff,0x4,0xefbfd8c4,0x4) 256 auvoxware RET setsockopt 0 256 auvoxware CALL bind(0,0xefbfd8c8,0x10) 256 auvoxware RET bind 0 256 auvoxware CALL setsockopt(0,0xffff,0x80,0x18c1c,0x8) 256 auvoxware RET setsockopt 0 256 auvoxware CALL listen(0,0x5) 256 auvoxware RET listen 0 256 auvoxware CALL ioctl(0,SIOCGIFCONF,0xefbfd0cc) 256 auvoxware RET ioctl 0 256 auvoxware CALL readlink(0x807aeaa,0xefbfd018,0x3f) 256 auvoxware NAMI "/etc/malloc.conf" 256 auvoxware RET readlink -1 errno 2 No such file or directory 256 auvoxware CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) 256 auvoxware RET mmap 134406144/0x802e000 256 auvoxware CALL break(0x1d000) 256 auvoxware RET break 0 256 auvoxware CALL break(0x1e000) 256 auvoxware RET break 0 256 auvoxware CALL umask(0) 256 auvoxware RET umask 18/0x12 256 auvoxware CALL mkdir(0xafef,0x1ff) 256 auvoxware NAMI "/tmp/.sockets" 256 auvoxware RET mkdir -1 errno 17 File exists 256 auvoxware CALL unlink(0x18e36) 256 auvoxware NAMI "/tmp/.sockets/audio0" 256 auvoxware RET unlink 0 256 auvoxware CALL socket(0x1,0x1,0) 256 auvoxware RET socket 1 256 auvoxware CALL bind(0x1,0x18e34,0x16) 256 auvoxware NAMI "/tmp/.sockets/audio0" 256 auvoxware RET bind 0 256 auvoxware CALL listen(0x1,0x5) 256 auvoxware RET listen 0 256 auvoxware CALL umask(0x12) 256 auvoxware RET umask 0 256 auvoxware CALL sigaction(0xd,0xefbfd8c4,0xefbfd8b8) 256 auvoxware RET sigaction 0 256 auvoxware CALL sigaction(0x1,0xefbfd8bc,0xefbfd8b0) 256 auvoxware RET sigaction 0 256 auvoxware CALL sigaction(0x2,0xefbfd8b4,0xefbfd8a8) 256 auvoxware RET sigaction 0 256 auvoxware CALL sigaction(0xf,0xefbfd8ac,0xefbfd8a0) 256 auvoxware RET sigaction 0 256 auvoxware CALL open(0xefbfd83c,0,0x1b6) 256 auvoxware NAMI "/etc/X0.hosts" 256 auvoxware RET open -1 errno 2 No such file or directory 256 auvoxware CALL sigaction(0x1e,0xefbfd8c0,0xefbfd8b4) 256 auvoxware RET sigaction 0 256 auvoxware CALL getppid 256 auvoxware RET getppid 206/0xce 256 auvoxware CALL break(0x1f000) 256 auvoxware RET break 0 256 auvoxware CALL break(0x20000) 256 auvoxware RET break 0 256 auvoxware CALL break(0x21000) 256 auvoxware RET break 0 256 auvoxware CALL open(0x18eb0,0,0x1b6) 256 auvoxware NAMI "/usr/X11R6/lib/AUVoxConfig" 256 auvoxware RET open 3 256 auvoxware CALL break(0x22000) 256 auvoxware RET break 0 256 auvoxware CALL break(0x27000) 256 auvoxware RET break 0 256 auvoxware CALL ioctl(0x3,TIOCGETA,0xefbfd758) 256 auvoxware RET ioctl -1 errno 25 Inappropriate ioctl for device 256 auvoxware CALL fstat(0x3,0xefbfd6d4) 256 auvoxware RET fstat 0 256 auvoxware CALL break(0x29000) 256 auvoxware RET break 0 256 auvoxware CALL read(0x3,0x27000,0x2000) 256 auvoxware GIO fd 3 read 1038 bytes "# # A sample config file for the VOXware nas server # # $NCDId: @(#)AUVoxConfig.eg,v 1.1 1996/04/24 17:00:06 greg Exp $ verbose #inputsection # device "/dev/dsp" # the SB emulation on my\ PAS16 # maxrate 11025 # minrate 4000 # Kind of redundant # maxfrags 3 # We want really low lat\ ency # minfrags 2 # the default # fragsize 256 # Again, for low latency # wordsize 8 # It only handles 8 bits\ anyway # numchans 1 # Glorious living mono #end # outputsection device "/dev/audio0" # the full 16 bit interf\ ace! maxrate 22000 # is flakey on my OPTi m\ b at 44 minrate 5000 # Redundant again maxfrags 3 # Low latency (for doom!\ ) minfrags 2 # redundant really. fragsize 256 # Low latency again.. wordsize 8 # Yes! numchans 1 # HiFi Stereo! end = # # An el cheapo full duplex setup could have the following output # section with the above inputsection, assuming that all they had # was an 8 bit SB and the PC speaker. # #outputsection # device "/dev/pcaudio" # maxrate 8000 # minrate 8000 # wordsize 8 #end " 256 auvoxware RET read 1038/0x40e 256 auvoxware CALL read(0x3,0x27000,0x2000) 256 auvoxware GIO fd 3 read 0 bytes "" 256 auvoxware RET read 0 256 auvoxware CALL write(0x2,0xefbfd0c0,0x16) 256 auvoxware GIO fd 2 wrote 22 bytes "+++ Maxfrags set to 3 " 256 auvoxware RET write 22/0x16 256 auvoxware CALL write(0x2,0xefbfd0c0,0x16) 256 auvoxware GIO fd 2 wrote 22 bytes "+++ Minfrags set to 2 " 256 auvoxware RET write 22/0x16 256 auvoxware CALL write(0x2,0xefbfd0c0,0x14) 256 auvoxware GIO fd 2 wrote 20 bytes "Fragsize set to 256 " 256 auvoxware RET write 20/0x14 256 auvoxware CALL ioctl(0x3,TIOCGETA,0xefbfd74c) 256 auvoxware RET ioctl -1 errno 25 Inappropriate ioctl for device 256 auvoxware CALL open(0x1d060,0x2,0) 256 auvoxware NAMI "/dev/audio0" 256 auvoxware RET open -1 errno 16 Device busy 256 auvoxware CALL write(0x2,0xefbfd178,0x15) 256 auvoxware GIO fd 2 wrote 21 bytes " Fatal server error: " 256 auvoxware RET write 21/0x15 256 auvoxware CALL write(0x2,0xefbfd14c,0x2c) 256 auvoxware GIO fd 2 wrote 44 bytes "could not create audio connection block info" 256 auvoxware RET write 44/0x2c 256 auvoxware CALL write(0x2,0xefbfd178,0x1) 256 auvoxware GIO fd 2 wrote 1 bytes " " 256 auvoxware RET write 1 256 auvoxware CALL exit(0x1) --------------446B9B3D2781E494167EB0E7-- From owner-freebsd-multimedia Fri May 30 08:14:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA20210 for multimedia-outgoing; Fri, 30 May 1997 08:14:25 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA20195 for ; Fri, 30 May 1997 08:14:15 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id IAA04929; Fri, 30 May 1997 08:14:12 -0700 (PDT) Message-Id: <199705301514.IAA04929@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Ted Knight cc: multimedia@FreeBSD.ORG Subject: Re: NAS voxware gravis ultrasound card In-reply-to: Your message of "Fri, 30 May 1997 11:10:32 EDT." <338EEDE8.41C67EA6@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 1997 08:14:12 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Try the sound driver : ftp://rah.star-gate.com:/pub/guspnp7.tar.gz And let us know if it works out for you. As for NAS it works great over here and I use every day to play back my telephone messages . rah is now back up had dns problems early on this week. Regards, Amancio >From The Desk Of Ted Knight : > This is a multi-part message in MIME format. > > --------------446B9B3D2781E494167EB0E7 > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > Hi Amancio, > > rah.star-gate.com seems not to be connected to the world. > > I want to usae Festival with NAS so I can get some fairly decent sound. > > I am having trouble getting the NAS server started. I have attached the > output of cat /dev/sndstat and kdump of ktrace of au -aa > > The kdump indicates that /dev/audio is busy. I cant see how this is so. > > Can you help me get the NAS server running. I am running FBSD 2.2.1 > and an original Ultrasound card which is forking fine on other > application. > > I am sure this is not as gee whiz as the bt848 to you, however, I need > some help here. > > Thanks, > Ted Knight > > --------------446B9B3D2781E494167EB0E7 > Content-Type: text/plain; charset=us-ascii; name="sndstat.out" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; filename="sndstat.out" > > VoxWare Sound Driver:3.0-beta-950506 (Sun Feb 5 14:38:12 EST 1995 freebsd-hac kers@freefall.cdrom.com) > Config options: ffffffff > > Installed drivers: > Type 4: Gravis Ultrasound > > > Card config: > Gravis Ultrasound at 0x220 irq 12 drq 1 > > Audio devices: > 0: Gravis UltraSound > > Synth devices: > 0: Gravis UltraSound 3.7 (1024k) > > Midi devices: > 0: Gravis UltraSound Midi > > Timers: > 0: System Timer > 1: OPL-3/GUS Timer > > Mixers: > 0: ICS2101 Multimedia Mixer > > --------------446B9B3D2781E494167EB0E7 > Content-Type: text/plain; charset=iso-8859-1; name="kdump.out" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: inline; filename="kdump.out" > > 256 ktrace RET ktrace 0 > 256 ktrace CALL readlink(0x8066eaa,0xefbfd388,0x3f) > 256 ktrace NAMI "/etc/malloc.conf" > 256 ktrace RET readlink -1 errno 2 No such file or directory > 256 ktrace CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) > 256 ktrace RET mmap 134324224/0x801a000 > 256 ktrace CALL break(0x5000) > 256 ktrace RET break 0 > 256 ktrace CALL break(0x6000) > 256 ktrace RET break 0 > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/sbin/au" > 256 ktrace RET execve -1 errno 2 No such file or directory > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/usr/sbin/au" > 256 ktrace RET execve -1 errno 2 No such file or directory > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/usr/local/sbin/au" > 256 ktrace RET execve -1 errno 2 No such file or directory > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/bin/au" > 256 ktrace RET execve -1 errno 2 No such file or directory > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/usr/bin/au" > 256 ktrace RET execve -1 errno 2 No such file or directory > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/usr/local/bin/au" > 256 ktrace RET execve -1 errno 2 No such file or directory > 256 ktrace CALL execve(0xefbfd450,0xefbfd910,0xefbfd91c) > 256 ktrace NAMI "/usr/X11R6/bin/au" > 256 auvoxware RET execve 0 > 256 auvoxware CALL open(0x109c,0,0) > 256 auvoxware NAMI "/usr/libexec/ld.so" > 256 auvoxware RET open 3 > 256 auvoxware CALL read(0x3,0xefbfd8b8,0x20) > 256 auvoxware GIO fd 3 read 32 bytes > "=CC\0\M^F=C0\0=D0\0\0\0 \0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0= > \0" > 256 auvoxware RET read 32/0x20 > 256 auvoxware CALL mmap(0,0xd000,0x5,0x2,0x3,0,0,0) > 256 auvoxware RET mmap 134311936/0x8017000 > 256 auvoxware CALL mmap(0x8024000,0x2000,0x3,0x12,0x3,0,0xd000,0) > 256 auvoxware RET mmap 134365184/0x8024000 > 256 auvoxware CALL getuid > 256 auvoxware RET getuid 0 > 256 auvoxware CALL geteuid > 256 auvoxware RET geteuid 0 > 256 auvoxware CALL getgid > 256 auvoxware RET getgid 0 > 256 auvoxware CALL getegid > 256 auvoxware RET getegid 0 > 256 auvoxware CALL __sysctl(0xefbfd80c,0x2,0x80258bc,0xefbfd814,0,0) > 256 auvoxware RET __sysctl 0 > 256 auvoxware CALL mmap(0,0x8000,0x3,0x1002,0xffffffff,0,0,0) > 256 auvoxware RET mmap 134373376/0x8026000 > 256 auvoxware CALL open(0x8018a82,0,0) > 256 auvoxware NAMI "/var/run/ld.so.hints" > 256 auvoxware RET open 4 > 256 auvoxware CALL read(0x4,0xefbfd7f8,0x20) > 256 auvoxware GIO fd 4 read 32 bytes > "iHDL\^B\0\0\0 \0\0\0007\0\0\0p > \0\0\^N\a\0\0~\^Q\0\0=D7\^F\0\0" > 256 auvoxware RET read 32/0x20 > 256 auvoxware CALL mmap(0,0x117e,0x1,0x1,0x4,0,0,0) > 256 auvoxware RET mmap 134406144/0x802e000 > 256 auvoxware CALL close(0x4) > 256 auvoxware RET close 0 > 256 auvoxware CALL stat(0x802ea72,0xefbfd7ac) > 256 auvoxware NAMI "/usr/lib/libc.so.3.0" > 256 auvoxware RET stat 0 > 256 auvoxware CALL stat(0x80290a0,0xefbfd7d4) > 256 auvoxware NAMI "/usr/lib/libc.so.3.0" > 256 auvoxware RET stat 0 > 256 auvoxware CALL open(0x80290a0,0,0) > 256 auvoxware NAMI "/usr/lib/libc.so.3.0" > 256 auvoxware RET open 4 > 256 auvoxware CALL read(0x4,0xefbfd7b4,0x20) > 256 auvoxware GIO fd 4 read 32 bytes > "=CC\0\M^F=C0\0\M^P\^E\0\0@\0\0\^P=C7\0\0\^D2\0\0 \0\0\0\0\0\0\0\0= > \0\0\0" > 256 auvoxware RET read 32/0x20 > 256 auvoxware CALL mmap(0,0x69710,0x5,0x2,0x4,0,0,0) > 256 auvoxware RET mmap 134414336/0x8030000 > 256 auvoxware CALL close(0x4) > 256 auvoxware RET close 0 > 256 auvoxware CALL mprotect(0x8089000,0x4000,0x7) > 256 auvoxware RET mprotect 0 > 256 auvoxware CALL mmap(0x808d000,0xc710,0x7,0x1012,0xffffffff,0,0,0)= > > 256 auvoxware RET mmap 134795264/0x808d000 > 256 auvoxware CALL mmap(0,0xa000,0x3,0x1002,0xffffffff,0,0,0) > 256 auvoxware RET mmap 134848512/0x809a000 > 256 auvoxware CALL munmap(0x802e000,0x117e) > 256 auvoxware RET munmap 0 > 256 auvoxware CALL close(0x3) > 256 auvoxware RET close 0 > 256 auvoxware CALL close(0) > 256 auvoxware RET close 0 > 256 auvoxware CALL close(0x1) > 256 auvoxware RET close 0 > 256 auvoxware CALL write(0x2,0xefbfd4e0,0) > 256 auvoxware GIO fd 2 wrote 0 bytes > "" > 256 auvoxware RET write 0 > 256 auvoxware CALL getpgrp > 256 auvoxware RET getpgrp 256/0x100 > 256 auvoxware CALL getdtablesize > 256 auvoxware RET getdtablesize 64/0x40 > 256 auvoxware CALL socket(0x2,0x1,0) > 256 auvoxware RET socket 0 > 256 auvoxware CALL setsockopt(0,0xffff,0x4,0xefbfd8c4,0x4) > 256 auvoxware RET setsockopt 0 > 256 auvoxware CALL bind(0,0xefbfd8c8,0x10) > 256 auvoxware RET bind 0 > 256 auvoxware CALL setsockopt(0,0xffff,0x80,0x18c1c,0x8) > 256 auvoxware RET setsockopt 0 > 256 auvoxware CALL listen(0,0x5) > 256 auvoxware RET listen 0 > 256 auvoxware CALL ioctl(0,SIOCGIFCONF,0xefbfd0cc) > 256 auvoxware RET ioctl 0 > 256 auvoxware CALL readlink(0x807aeaa,0xefbfd018,0x3f) > 256 auvoxware NAMI "/etc/malloc.conf" > 256 auvoxware RET readlink -1 errno 2 No such file or directory > 256 auvoxware CALL mmap(0,0x1000,0x3,0x1002,0xffffffff,0,0,0) > 256 auvoxware RET mmap 134406144/0x802e000 > 256 auvoxware CALL break(0x1d000) > 256 auvoxware RET break 0 > 256 auvoxware CALL break(0x1e000) > 256 auvoxware RET break 0 > 256 auvoxware CALL umask(0) > 256 auvoxware RET umask 18/0x12 > 256 auvoxware CALL mkdir(0xafef,0x1ff) > 256 auvoxware NAMI "/tmp/.sockets" > 256 auvoxware RET mkdir -1 errno 17 File exists > 256 auvoxware CALL unlink(0x18e36) > 256 auvoxware NAMI "/tmp/.sockets/audio0" > 256 auvoxware RET unlink 0 > 256 auvoxware CALL socket(0x1,0x1,0) > 256 auvoxware RET socket 1 > 256 auvoxware CALL bind(0x1,0x18e34,0x16) > 256 auvoxware NAMI "/tmp/.sockets/audio0" > 256 auvoxware RET bind 0 > 256 auvoxware CALL listen(0x1,0x5) > 256 auvoxware RET listen 0 > 256 auvoxware CALL umask(0x12) > 256 auvoxware RET umask 0 > 256 auvoxware CALL sigaction(0xd,0xefbfd8c4,0xefbfd8b8) > 256 auvoxware RET sigaction 0 > 256 auvoxware CALL sigaction(0x1,0xefbfd8bc,0xefbfd8b0) > 256 auvoxware RET sigaction 0 > 256 auvoxware CALL sigaction(0x2,0xefbfd8b4,0xefbfd8a8) > 256 auvoxware RET sigaction 0 > 256 auvoxware CALL sigaction(0xf,0xefbfd8ac,0xefbfd8a0) > 256 auvoxware RET sigaction 0 > 256 auvoxware CALL open(0xefbfd83c,0,0x1b6) > 256 auvoxware NAMI "/etc/X0.hosts" > 256 auvoxware RET open -1 errno 2 No such file or directory > 256 auvoxware CALL sigaction(0x1e,0xefbfd8c0,0xefbfd8b4) > 256 auvoxware RET sigaction 0 > 256 auvoxware CALL getppid > 256 auvoxware RET getppid 206/0xce > 256 auvoxware CALL break(0x1f000) > 256 auvoxware RET break 0 > 256 auvoxware CALL break(0x20000) > 256 auvoxware RET break 0 > 256 auvoxware CALL break(0x21000) > 256 auvoxware RET break 0 > 256 auvoxware CALL open(0x18eb0,0,0x1b6) > 256 auvoxware NAMI "/usr/X11R6/lib/AUVoxConfig" > 256 auvoxware RET open 3 > 256 auvoxware CALL break(0x22000) > 256 auvoxware RET break 0 > 256 auvoxware CALL break(0x27000) > 256 auvoxware RET break 0 > 256 auvoxware CALL ioctl(0x3,TIOCGETA,0xefbfd758) > 256 auvoxware RET ioctl -1 errno 25 Inappropriate ioctl for device > 256 auvoxware CALL fstat(0x3,0xefbfd6d4) > 256 auvoxware RET fstat 0 > 256 auvoxware CALL break(0x29000) > 256 auvoxware RET break 0 > 256 auvoxware CALL read(0x3,0x27000,0x2000) > 256 auvoxware GIO fd 3 read 1038 bytes > "# > # A sample config file for the VOXware nas server > # > # $NCDId: @(#)AUVoxConfig.eg,v 1.1 1996/04/24 17:00:06 greg Exp $ > verbose > #inputsection > # device "/dev/dsp" # the SB emulation on m y\ > PAS16 > # maxrate 11025 > # minrate 4000 # Kind of redundant > # maxfrags 3 # We want really low la t\ > ency > # minfrags 2 # the default > # fragsize 256 # Again, for low latenc y > # wordsize 8 # It only handles 8 bit s\ > anyway > # numchans 1 # Glorious living mono > #end > # > outputsection > device "/dev/audio0" # the full 16 bit inter f\ > ace! > maxrate 22000 # is flakey on my OPTi m\ > b at 44 > minrate 5000 # Redundant again > maxfrags 3 # Low latency (for doom !\ > ) > minfrags 2 # redundant really. > fragsize 256 # Low latency again.. > wordsize 8 # Yes! > numchans 1 # HiFi Stereo! > end > = > > # > # An el cheapo full duplex setup could have the following output > # section with the above inputsection, assuming that all they had > # was an 8 bit SB and the PC speaker. > # > #outputsection > # device "/dev/pcaudio" > # maxrate 8000 > # minrate 8000 > # wordsize 8 > #end > " > 256 auvoxware RET read 1038/0x40e > 256 auvoxware CALL read(0x3,0x27000,0x2000) > 256 auvoxware GIO fd 3 read 0 bytes > "" > 256 auvoxware RET read 0 > 256 auvoxware CALL write(0x2,0xefbfd0c0,0x16) > 256 auvoxware GIO fd 2 wrote 22 bytes > "+++ Maxfrags set to 3 > " > 256 auvoxware RET write 22/0x16 > 256 auvoxware CALL write(0x2,0xefbfd0c0,0x16) > 256 auvoxware GIO fd 2 wrote 22 bytes > "+++ Minfrags set to 2 > " > 256 auvoxware RET write 22/0x16 > 256 auvoxware CALL write(0x2,0xefbfd0c0,0x14) > 256 auvoxware GIO fd 2 wrote 20 bytes > "Fragsize set to 256 > " > 256 auvoxware RET write 20/0x14 > 256 auvoxware CALL ioctl(0x3,TIOCGETA,0xefbfd74c) > 256 auvoxware RET ioctl -1 errno 25 Inappropriate ioctl for device > 256 auvoxware CALL open(0x1d060,0x2,0) > 256 auvoxware NAMI "/dev/audio0" > 256 auvoxware RET open -1 errno 16 Device busy > 256 auvoxware CALL write(0x2,0xefbfd178,0x15) > 256 auvoxware GIO fd 2 wrote 21 bytes > " > Fatal server error: > " > 256 auvoxware RET write 21/0x15 > 256 auvoxware CALL write(0x2,0xefbfd14c,0x2c) > 256 auvoxware GIO fd 2 wrote 44 bytes > "could not create audio connection block info" > 256 auvoxware RET write 44/0x2c > 256 auvoxware CALL write(0x2,0xefbfd178,0x1) > 256 auvoxware GIO fd 2 wrote 1 bytes > " > " > 256 auvoxware RET write 1 > 256 auvoxware CALL exit(0x1) > > --------------446B9B3D2781E494167EB0E7-- > From owner-freebsd-multimedia Fri May 30 08:44:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA21562 for multimedia-outgoing; Fri, 30 May 1997 08:44:39 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA21557 for ; Fri, 30 May 1997 08:44:37 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/8.7.3) with SMTP id LAA28567; Fri, 30 May 1997 11:44:31 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id LAA18469; Fri, 30 May 1997 11:44:30 -0400 Date: Fri, 30 May 1997 11:44:16 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Ted Knight cc: multimedia@FreeBSD.ORG, Amancio Hasty Subject: Re: NAS voxware gravis ultrasound card In-Reply-To: <338EEDE8.41C67EA6@ix.netcom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 May 1997, Ted Knight wrote: > Hi Amancio, > > rah.star-gate.com seems not to be connected to the world. > > I want to usae Festival with NAS so I can get some fairly decent sound. > > I am having trouble getting the NAS server started. I have attached the > output of cat /dev/sndstat and kdump of ktrace of au -aa > > The kdump indicates that /dev/audio is busy. I cant see how this is so. > > Can you help me get the NAS server running. I am running FBSD 2.2.1 > and an original Ultrasound card which is forking fine on other > application. > > I am sure this is not as gee whiz as the bt848 to you, however, I need > some help here. Ted, I'll try to get back to you later (I gotta run errands right now) but I fought this once before, and at that time, NAS was opening the wrong device numbers. It needed to have a variable set up for the AUDIOSERVER (just like the DISPLAY variable), and needed to have a number changed in one of the open calls. This shouldn't be too awful hard to track down again, since I did it once before. > > Thanks, > Ted Knight > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 9120 Edmonston Ct #302 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-multimedia Fri May 30 11:20:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00394 for multimedia-outgoing; Fri, 30 May 1997 11:20:14 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA00383 for ; Fri, 30 May 1997 11:20:05 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA20995; Fri, 30 May 1997 19:45:56 +0200 From: Luigi Rizzo Message-Id: <199705301745.TAA20995@labinfo.iet.unipi.it> Subject: Re: bt848 status, comments and diffs To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 30 May 1997 19:45:55 +0200 (MET DST) Cc: multimedia@freebsd.org In-Reply-To: <199705301551.IAA00399@rah.star-gate.com> from "Amancio Hasty" at May 30, 97 08:51:11 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >From The Desk Of Luigi Rizzo : > > > The source _frame_ rate is always 30 (25 for PAL), the source > > _field_ rate is always 60 (50). Now the manual page seems to confuse > > fields and frames, which makes tests necessary to get the correct > > interpretation :) > > Well, tests over here have shown that for NTSC the source frame rate > is 30 or 60. I will have to test a little bit more tonite when I get > home . It's a matter of definitions of course. In the broadcast video language, a "frame" is made of two "fields", interlaced. Now, our interface (ioctl()) to the meteor/bktr video grabber only lets you ask for: a) odd+even fields, interlaced; this is 30 different pictures (which are full frames) per second; b) odd fields only; call them frames or fields, this is 30 different pictures per second; c) even fields only; this is 30 different pictures per second; It is fine to me to allow a video mode which lets you get d) any single field (odd or even); this gives you 60 different pictures per second; it's just that I cannot see how to differentiate between a) and d) when asking a scaled (say, 320x240) sequence. To tell the truth, in /sys/i386/ioctl_meteor.h there is a #define METEOR_FIELD_MODE 0x80000000 /* Field cap or Frame cap */ flag, but it is never used, either in the meteor or in the brooktree driver. In other words, if you are getting 30 pictures per second, interlaced, when requesting odd+even fields at 640x480 (or perhaps even down to some smaller size, say 328x248), I don't see why you should suddenly get 60 pictures per second just because you reduced the scaling to 320x240. Sounds like a very odd interaction between image size and frame rate, and frankly, even if the previous drivers acted this way, I prefer the picture rate to stay the same, no matter how I scale the image! Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Fri May 30 18:46:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA21099 for multimedia-outgoing; Fri, 30 May 1997 18:46:23 -0700 (PDT) Received: from cais.cais.com (root@cais.com [199.0.216.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA21094 for ; Fri, 30 May 1997 18:46:20 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by cais.cais.com (8.8.5/8.7.3) with SMTP id VAA00187 for ; Fri, 30 May 1997 21:46:11 -0400 (EDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id VAA13902 for ; Fri, 30 May 1997 21:45:58 -0400 Date: Fri, 30 May 1997 21:45:42 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: FreeBSD-multimedia@freebsd.org Subject: Audio devices Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know what the absolute reference is for the major and minor numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? I am not looking for the numbers, I can go do an ls -l of my /dev for that. I'm trying to find the definitive guide for them. If I can get a reference I trust, I'll go hunt thru the NAS port and fix it. These values have undergone some changes and experimentation inthe past, as various folks (Amancio, take a bow here) have worked to improve things. I think that's the reason that NAS might be wrong, and if I make a change here, I want to be able to point at the reason why I think I did it right. I know how to do the changes I want to do, its making sure I get the numbers right, beyond argument, that's important. If I knew where the MAKEDEV script came from in the CVS tree, I would take that as a reference ... anyone know? ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-multimedia Fri May 30 19:14:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22189 for multimedia-outgoing; Fri, 30 May 1997 19:14:15 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA22184 for ; Fri, 30 May 1997 19:14:12 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id TAA03642; Fri, 30 May 1997 19:14:10 -0700 (PDT) Message-Id: <199705310214.TAA03642@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Chuck Robey cc: FreeBSD-multimedia@FreeBSD.ORG Subject: Re: Audio devices In-reply-to: Your message of "Fri, 30 May 1997 21:45:42 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 1997 19:14:09 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Chuck, Most likely the source of the problem is the dual dma implementation found in the sound driver 3.0 vs. sound driver 3.5. If he upgrades the sound driver and has problems then we can address the issue. As for the NAS configuration Stephe Hocking should step in and tell us the latest and greatest that he has done with the NAS configuration either that or Ted should post on the nas@ncd.com. Regards, Amancio >From The Desk Of Chuck Robey : > Does anyone know what the absolute reference is for the major and minor > numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? > > I am not looking for the numbers, I can go do an ls -l of my /dev for > that. I'm trying to find the definitive guide for them. If I can get a > reference I trust, I'll go hunt thru the NAS port and fix it. These > values have undergone some changes and experimentation inthe past, as > various folks (Amancio, take a bow here) have worked to improve things. > I think that's the reason that NAS might be wrong, and if I make a change > here, I want to be able to point at the reason why I think I did it right. > > I know how to do the changes I want to do, its making sure I get the > numbers right, beyond argument, that's important. > > If I knew where the MAKEDEV script came from in the CVS tree, I would > take that as a reference ... anyone know? > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@eng.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD > (301) 220-2114 | version 3.0 current -- and great FUN! > ----------------------------+----------------------------------------------- > From owner-freebsd-multimedia Fri May 30 19:32:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23123 for multimedia-outgoing; Fri, 30 May 1997 19:32:55 -0700 (PDT) Received: from Kitten.mcs.com (Kitten.mcs.com [192.160.127.90]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23118 for ; Fri, 30 May 1997 19:32:52 -0700 (PDT) Received: from earth.mat.net (root@earth.mat.net [205.252.122.1]) by Kitten.mcs.com (8.8.5/8.8.2) with SMTP id VAA28478; Fri, 30 May 1997 21:32:50 -0500 (CDT) Received: from Journey2.mat.net (journey2.mat.net [205.252.122.116]) by earth.mat.net (8.6.12/8.6.12) with SMTP id WAA15647; Fri, 30 May 1997 22:27:48 -0400 Date: Fri, 30 May 1997 22:27:32 -0400 (EDT) From: Chuck Robey X-Sender: chuckr@Journey2.mat.net To: Amancio Hasty cc: FreeBSD-multimedia@FreeBSD.ORG Subject: Re: Audio devices In-Reply-To: <199705310214.TAA03642@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Fri, 30 May 1997, Amancio Hasty wrote: > Hi Chuck, > > Most likely the source of the problem is the dual dma implementation > found in the sound driver 3.0 vs. sound driver 3.5. > > If he upgrades the sound driver and has problems then we can address > the issue. > > As for the NAS configuration Stephe Hocking should step in and tell > us the latest and greatest that he has done with the NAS configuration > either that or Ted should post on the nas@ncd.com. I figured I'd get the thing right first, then worry about Ted's particular setup, which he already sent me. Hmmm, I've been running happily using the sound setup in -current, and the changes to NAS I hacked in myself a few eons ago. I just rebuilt NAS to test the build, and it nicely scragged out my changes (I did it on purpose). I have an older, non-PNP Gus (1k) ... should I get your updated sound driver and use that instead of what's in current for this? Why's it not been folded into current? Not enough feedback yet? If that's true, and if my non-PNP gus will do as a test, I'll do a test. I would like to do this with the idea that we're headed towards putting the driver into current. That fit into your plans ok? If you're saying a bunch of yes's here, ok, what's the filename I gotta pick up? > > > Regards, > Amancio ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@eng.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run Journey2 and picnic, both FreeBSD (301) 220-2114 | version 3.0 current -- and great FUN! ----------------------------+----------------------------------------------- From owner-freebsd-multimedia Sat May 31 04:46:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA20888 for multimedia-outgoing; Sat, 31 May 1997 04:46:56 -0700 (PDT) Received: from whqvax.picker.com (whqvax.picker.com [144.54.1.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id EAA20883 for ; Sat, 31 May 1997 04:46:53 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sat, 31 May 1997 7:45:50 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA10349; Sat, 31 May 97 07:45:49 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA17600; Sat, 31 May 1997 07:44:42 -0400 Message-Id: <19970531074442.47236@ct.picker.com> Date: Sat, 31 May 1997 07:44:42 -0400 From: Randall Hopper To: Chuck Robey Cc: FreeBSD-multimedia@FreeBSD.ORG Subject: Re: Audio devices References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: ; from Chuck Robey on Fri, May 30, 1997 at 09:45:42PM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Chuck Robey: |Does anyone know what the absolute reference is for the major and minor |numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? | |I am not looking for the numbers, I can go do an ls -l of my /dev for |that. I'm trying to find the definitive guide for them. If I can get a Well, this may or may not be acclaimed as the definitive guide anymore, but I have a PostScript copy of Hannu Savolainen's "Hacker's Guide to VoxWare 2.4, second draft" that has this table and subsequent text: Device Minor Multi mixer 0 yes sequencer 1 no midi 2 yes dsp 3 yes audio 4 yes dsp16 5 yes sndstat 6 no (unused) 7 no sequencer2 8 no Table 0.1: Minor number assignment of the device files ... The minor number assign ment is given in the table 0.1. The four least significant bits of the minor number are used to select the device file type or class. If there is more than one devices in this class, the upper 4 bits are used to select the device. For example the class number of the /dev/dsp is 3. Then the minor number of /dev/dsp is 3 + 16 * 0 = 3 and the /dev/dsp1 is 3 + 16 * 1 = 19. Seeing as how our Voxware drivers are dated May 6, 1995, and the docs are dated Feb 21, 1994 and describe features up-and-coming for 3.0, it makes sense that this is a close match. BTW, it holds for my card (Sound Blaster 32), except that sequencer2 is called music0, and there's and extra pss0 on minor 9. Randall From owner-freebsd-multimedia Sat May 31 12:02:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA04905 for multimedia-outgoing; Sat, 31 May 1997 12:02:59 -0700 (PDT) Received: from crh.cl.msu.edu (crh.cl.msu.edu [35.8.1.24]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA04899 for ; Sat, 31 May 1997 12:02:54 -0700 (PDT) Received: (from henrich@localhost) by crh.cl.msu.edu (8.8.5/8.8.5) id PAA23910; Sat, 31 May 1997 15:02:52 -0400 (EDT) Message-ID: <19970531150252.12556@crh.cl.msu.edu> Date: Sat, 31 May 1997 15:02:52 -0400 From: Charles Henrich To: freebsd-multimedia@freebsd.org Subject: RealPlayer ? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.75 X-Operating-System: FreeBSD 2.2.2-RELEASE Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Anyone out there know if we're ever going to get a Unix version of RealPlayer? -Crh Charles Henrich Michigan State University henrich@msu.edu http://pilot.msu.edu/~henrich From owner-freebsd-multimedia Sat May 31 14:49:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA16389 for multimedia-outgoing; Sat, 31 May 1997 14:49:34 -0700 (PDT) Received: from ohm.ingsala.unal.edu.co ([168.176.15.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA16377 for ; Sat, 31 May 1997 14:49:29 -0700 (PDT) Received: from unalmodem.usc.unal.edu.co (unalmodem20.usc.unal.edu.co [168.176.3.50]) by ohm.ingsala.unal.edu.co (8.8.5/8.8.5) with SMTP id QAA00542; Sat, 31 May 1997 16:50:30 -0500 (COT) Message-ID: <3390B282.722A@fps.biblos.unal.edu.co> Date: Sat, 31 May 1997 16:21:38 -0700 From: "Pedro F. Giffuni" Organization: Universidad Nacional de Colombia X-Mailer: Mozilla 3.0 (Win16; I) MIME-Version: 1.0 To: Randall Hopper CC: Chuck Robey , FreeBSD-multimedia@freebsd.org Subject: Re: Audio devices References: <19970531074442.47236@ct.picker.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It hasn't changed on the new guide http://www.4front-tech.com/pguide/index.html Pedro. Randall Hopper wrote: > > Chuck Robey: > |Does anyone know what the absolute reference is for the major and minor > |numbers for the audio devices, like /dev/audio, dsp, dsp0, midi, music, etc? > | > |I am not looking for the numbers, I can go do an ls -l of my /dev for > |that. I'm trying to find the definitive guide for them. If I can get a > > Well, this may or may not be acclaimed as the definitive guide > anymore, but I have a PostScript copy of Hannu Savolainen's "Hacker's Guide > to VoxWare 2.4, second draft" that has this table and subsequent text: > > Device Minor Multi > mixer 0 yes > sequencer 1 no > midi 2 yes > dsp 3 yes > audio 4 yes > dsp16 5 yes > sndstat 6 no > (unused) 7 no > sequencer2 8 no > > Table 0.1: Minor number assignment of the device files > ... > > The minor number assign ment is given in the table 0.1. The four > least significant bits of the minor number are used to select the > device file type or class. If there is more than one devices in > this class, the upper 4 bits are used to select the device. For > example the class number of the /dev/dsp is 3. Then the minor > number of /dev/dsp is 3 + 16 * 0 = 3 and the /dev/dsp1 is 3 + 16 > * 1 = 19. > > Seeing as how our Voxware drivers are dated May 6, 1995, and the docs are > dated Feb 21, 1994 and describe features up-and-coming for 3.0, it makes > sense that this is a close match. > > BTW, it holds for my card (Sound Blaster 32), except that sequencer2 is > called music0, and there's and extra pss0 on minor 9. > > Randall From owner-freebsd-multimedia Sat May 31 17:01:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA24015 for multimedia-outgoing; Sat, 31 May 1997 17:01:19 -0700 (PDT) Received: from pegasus.tlk.com (root@pegasus.tlk.com [194.97.84.20]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA24010 for ; Sat, 31 May 1997 17:01:16 -0700 (PDT) Received: from ramsey.tb.9715.org(really [194.97.84.65]) by pegasus.tlk.com via sendmail with esmtp (ident root using rfc1413) id for ; Sun, 1 Jun 1997 02:01:09 +0200 (MET DST)) Received: by ramsey.tb.9715.org via sendmail with stdio id for freebsd-multimedia@freebsd.org; Sun, 1 Jun 1997 02:01:19 +0200 (CEST) Message-Id: From: torstenb@ramsey.tb.9715.org (Torsten Blum) Subject: grabber To: freebsd-multimedia@freebsd.org Date: Sun, 1 Jun 1997 02:01:19 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL31H (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, for a projekt I need a video capture board that supports S-VIDEO (hosiden) with PAL and NTSC. Video source will be a LaserDisc Player and a Sony EVI-D31 cam. Is there a difference between the Meteor and the Bt848 cards regarding the picture quality ? Can one recommend a Bt848 based card ? -tb From owner-freebsd-multimedia Sat May 31 17:24:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA24952 for multimedia-outgoing; Sat, 31 May 1997 17:24:57 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA24946 for ; Sat, 31 May 1997 17:24:54 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id RAA05981 for ; Sat, 31 May 1997 17:24:57 -0700 (PDT) Message-Id: <199706010024.RAA05981@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: multimedia@freebsd.org Subject: http://rah.star-gate.com/HyperNews/get/forums/sound.html Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 May 1997 17:24:57 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, You can also get to the web page via http://rah.star-gate.com/ I started building a HyperNews archive for the sound driver . This is just a test round if people like the general setup then I will start loading up the web page. Also pending upon the success I may do one for the Bt848 project. The web page sports a searchable archive via glimpse. Once the web page is fully operational the glimpse interface is able to include its search space from http pointers embedded in the postings. For info on HyperNews: http://union.ncsa.uiuc.edu/HyperNews/get/hypernews.html For info on WebGlimpse: http://donkey.CS.Arizona.EDU/webglimpse/ Enjoy, Amancio From owner-freebsd-multimedia Sat May 31 17:57:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA26587 for multimedia-outgoing; Sat, 31 May 1997 17:57:39 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26582 for ; Sat, 31 May 1997 17:57:36 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id RAA06310; Sat, 31 May 1997 17:57:34 -0700 (PDT) Message-Id: <199706010057.RAA06310@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Ted Knight cc: multimedia@freebsd.org Subject: Re: new sound driver In-reply-to: Your message of "Sat, 31 May 1997 20:28:03 EDT." <3390C213.41C67EA6@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 May 1997 17:57:34 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi Ted, Try to get others in the multimedia mailing list to help you --- I am really overloaded over here. To alleviate problems such as yours I am building up a web environment when it is done I will be happy to let you know. Regards, Amancio >From The Desk Of Ted Knight : > Hi Amancio, > > I want to install the new driver. However, the three questions I put to > you remain unanswered. > > > 1. Will this new driver work with 2.2.1R? > > 2. In the subdirectory freebsd you have 2 conf.c.add files. > conf.c.add looks like the declartion of the snd driver > functions to be used if the sound system is installed. > conf.c.add2 looks like an entry for the char dev jump > table. > > I have looked for a few hours with no luck. What are > the filesnames which need to be appended with these files? > > 3. Your makedev.sh script looks like it generates snd > devices with major 33. Is this going to work in 2.2.1R > without other modifications to the kernel? > > > Ted Knight From owner-freebsd-multimedia Sat May 31 18:51:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA28355 for multimedia-outgoing; Sat, 31 May 1997 18:51:27 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA28348 for ; Sat, 31 May 1997 18:51:25 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id SAA07060; Sat, 31 May 1997 18:51:26 -0700 (PDT) Message-Id: <199706010151.SAA07060@rah.star-gate.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Ted Knight cc: multimedia@freebsd.org Subject: Re: right on! In-reply-to: Your message of "Sat, 31 May 1997 21:39:11 EDT." <3390D2BF.167EB0E7@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 31 May 1997 18:51:26 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yes, I am enthusiastic and I am *really* overloaded so I think is not too much to ask the list to help you given that I have help so many of them on the list. This is the last message that I will send on this direct line of topic . Feel free to post whatever you like. Amancio >From The Desk Of Ted Knight : > Amancio, > > Thanks, you've been a great help! > > Funny thing, the three guys on the list I spoke to before I contacted > you in the first place told me how enthusiastic you were to help, > especially with the projects you are involved in. > > Don't worry, I promise I will never write you again. > > By the way, when using the english language preposition "than" (example: > this is better "than" that) it is not spelled "then" and the > contraction of the words "it is" is spelled "it's" not "is". > > > TK From owner-freebsd-multimedia Sat May 31 19:48:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA01118 for multimedia-outgoing; Sat, 31 May 1997 19:48:23 -0700 (PDT) Received: from vegemite.Stanford.EDU (vegemite.Stanford.EDU [171.65.76.158]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA01113 for ; Sat, 31 May 1997 19:48:22 -0700 (PDT) Received: (hlew@localhost) by vegemite.Stanford.EDU (8.7.1/8.6.4) id TAA06811; Sat, 31 May 1997 19:48:19 -0700 (PDT) Date: Sat, 31 May 1997 19:48:18 -0700 (PDT) From: Howard Lew To: Charles Henrich cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: RealPlayer ? In-Reply-To: <19970531150252.12556@crh.cl.msu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sat, 31 May 1997, Charles Henrich wrote: > Anyone out there know if we're ever going to get a Unix version of > RealPlayer? That's a good question. I have been checking for it every week, and so far no hint of it yet. From owner-freebsd-multimedia Sat May 31 23:51:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA09750 for multimedia-outgoing; Sat, 31 May 1997 23:51:19 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA09745 for ; Sat, 31 May 1997 23:51:16 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA22933; Sun, 1 Jun 1997 08:17:35 +0200 From: Luigi Rizzo Message-Id: <199706010617.IAA22933@labinfo.iet.unipi.it> Subject: Re: grabber To: torstenb@ramsey.tb.9715.org (Torsten Blum) Date: Sun, 1 Jun 1997 08:17:35 +0200 (MET DST) Cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: from "Torsten Blum" at Jun 1, 97 02:01:00 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > > for a projekt I need a video capture board that supports S-VIDEO (hosiden) > with PAL and NTSC. Video source will be a LaserDisc Player and a Sony > EVI-D31 cam. My experience is only with composite video... > Is there a difference between the Meteor and the Bt848 cards regarding > the picture quality ? Having tried both, I am all for the Bt848. >From the data sheets it looks like the Bt848 is much more powerful for what concerns sampling and filtering. As an example, it can average adjacent rows to remove artifacts due to phase errors in reconstruction the color subcarrier -- a common problem in PAL which is usually solved by the use of a delay line, but the Meteor cannot do this (and yest those artifacts I am able to see here). It also seems to have a higher sampling frequency. Last but not least, Bt848-based boards cost 1/3 of the Meteor and there are many suppliers. > Can one recommend a Bt848 based card ? I have had good results with the Hauppauge board. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________