From owner-freebsd-multimedia Mon Aug 25 12:46:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA04221 for multimedia-outgoing; Mon, 25 Aug 1997 12:46:04 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA04213; Mon, 25 Aug 1997 12:45:59 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA20100; Mon, 25 Aug 1997 19:42:49 +0200 From: Luigi Rizzo Message-Id: <199708251742.TAA20100@labinfo.iet.unipi.it> Subject: snd970825.tgz available To: hackers@freebsd.org, multimedia@freebsd.org Date: Mon, 25 Aug 1997 19:42:48 +0200 (MET DST) Cc: luigi@labinfo.iet.unipi.it (Luigi Rizzo) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The latest snap of my sound driver is available at the following URLs: http://www.iet.unipi.it/~luigi/snd970825.tgz ftp://www.iet.unipi.it/pub/snd970825.tgz There are two noticeable differences since the previous release: * files now should be unpacked in /sys/i386/isa/snd directory. * the "controller snd0" statement in the config file is not needed anymore. As a consequence of these changes, in order to build a kernel, one should: * update "files.i386" * update the kernel config file, run "config" etc. * make sure that /sys/i386/isa/sound/ulaw.h exists if you also use /dev/pcaudio Although these changes are annoying, I decided to make them to make life easier for those who want to build kernels with both Amancio's driver (or the original sound driver) and this new driver. Having code in two different places is the first step, although I have not checked for name clashes yet. Major improvements of the code since the previous release: - removed a stupid bug I introduced last time in SB support which prevented SB 3.x to work. I have tested it and now SB 3.x works in both play and capture mode (half duplex though); - Better OPTI931 support which now more or less works. After debugging the OPTI931 for the whole day, I am pretty convinced that the chip has a bug and it cannot capture ULAW (all other modes and formats seem to work well). I can implement a software workaround in the driver, but I am postponing this in case I am wrong and people from OPTI comes up with a reasonable explaination of why I am wrong. - some initial support for the GUSPNP in MSS mode; - some improvements to the dma code and various code cleanup. As usual, please test this driver if you have a chance, and send feedback (_both_ positive and negative). I need feedback to support cards I do not own. I am particularly interested on how it works with the GUSPnP and SB16PnP, but info on any card is welcome. Remember, I need the output from dmesg (the section which starts with Probing for PnP devices: CSN 1 Vendor ID: OPT0931 [0x3109143e] Serial 0xffffffff port 0x0300 0x0000 0x0000 0x0000 irq 11:0 drq 4:4 port 0x0200 0x0000 0x0000 0x0000 irq 0:0 drq 4:4 port 0x0534 0x0380 0x0220 0x0e0c irq 10:0 drq 1:5 and possibly the output of "pnpinfo". Thanks for your cooperation 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/ _____________________________|______________________________________