From owner-freebsd-multimedia Tue Nov 25 07:48:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA21479 for multimedia-outgoing; Tue, 25 Nov 1997 07:48:55 -0800 (PST) (envelope-from owner-freebsd-multimedia) Received: from thumper.cns.vt.edu (thumper.cns.vt.edu [128.173.12.196]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA21473 for ; Tue, 25 Nov 1997 07:48:51 -0800 (PST) (envelope-from ceharris@cns.vt.edu) Received: (ceharris@localhost) by thumper.cns.vt.edu (8.8.5/8.8.5) id KAA17972 for freebsd-multimedia@freebsd.org; Tue, 25 Nov 1997 10:48:46 -0500 (EST) From: Carl Harris Message-Id: <199711251548.KAA17972@thumper.cns.vt.edu> Subject: Re: GUS PnP + 3.0-971022-SNAP help To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 25 Nov 1997 10:48:24 -0500 (EST) In-Reply-To: <199711241428.PAA02678@labinfo.iet.unipi.it> from "Luigi Rizzo" at Nov 24, 97 03:28:40 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > I've been trying (rather unsuccessfully) to get the GUS PnP driver from > > rah.star-gate.com to compile with the 3.0-971022-SNAP kernel sources. > > I've tried every version I can find there, and not one of them compiles > > without error. The most recent version (guspnp23) complains that > > PCM_ENABLE_INPUT and PCM_ENABLE_OUTPUT are not defined. Turns out that the problem is that PCM_ENABLE_* defines are located in sys/i386/include/soundcard.h which is not part of the guspnpXX.tar.gz file. I built a kernel with the sources that are distributed with the 3.0-971022-SNAP, by simply replacing the soundcard.h with the copy in -current, and by replacing sys/i386/isa/sound with the sources from -current. Next question. Amancio's web page which describes the setup for using full-duplex audio with vat4.0 is not available. Can someone give me some help in getting this to work? I currently have only a /dev/audio0, and as I recall, I need a /dev/audio1 as well. I tried creating a /dev/audio1 with the same major/minor numbers as /dev/audio0, but this had no discernable effect. -- Carl Harris Communication Systems Lead Engineer CNS Research and Development, Virginia Tech ceharris@vt.edu