From owner-freebsd-hackers Sun Aug 3 02:29:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id CAA16149 for hackers-outgoing; Sun, 3 Aug 1997 02:29:51 -0700 (PDT) Received: from www2.shoppersnet.com (shoppersnet.com [204.156.152.112]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id CAA16131 for ; Sun, 3 Aug 1997 02:29:40 -0700 (PDT) Received: (from hlew@localhost) by www2.shoppersnet.com (8.8.5/8.8.5) id CAA11802; Sun, 3 Aug 1997 02:32:59 -0700 (PDT) Date: Sun, 3 Aug 1997 02:32:59 -0700 (PDT) From: Howard Lew To: Amancio Hasty cc: Luigi Rizzo , hackers@FreeBSD.ORG Subject: Re: device close behaviour - a question In-Reply-To: <199708030700.AAA00271@rah.star-gate.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi guys! Okay, I'm testing out Luigi's snd970731 driver... Is this setup correct in the kernel config? controller snd0 device pcm0 at isa ? port? tty irq 5 drq 1 flags 0x9 vector pcmintr #device midi0 at isa ? port? tty flags F #device synth0 at isa ? port? tty flags F dmesg probe shows: pcm0 at 0xffff irq 5 drq 1 mem 0x00000000 flags 0x00000009 en 1 confl 0 no address supplied, try default 0x0530 I/O address inactive (ff), try pseudo_mss no address supplied, try default sb_reset_dsp failed pcm0 not found at 0xffffffff Actual Card is: Sound Origins 32 DSP Wavetable 3D PNP ISA OPTI925 Chipset Supports SB Pro, MSS/WSS, Roland Sound Canvas Win95 configures it as: MSS/WSS 0x530 irq 5 DMA 0/1, irq 300 2/9 OS: FreeBSD 2.2.2-RELENG #1 (7/13/97) > > Hi, > > guspnp14 is based upon the linux sound driver 3.5 and is fully > compliant with the linux sound driver 3.5,i.e., I didn't alter > its functionality. The name guspnp right now is a little misleading > because the driver works with different sound cards. > For instance, it works with the sb16 pnp, pas 16, gus pnp pro, > audiotrix pro, and gus max. It is supposed to work with the awe however > I have not gotten any report lately. Preliminary PnP was added for just the > gus pnp pro. The driver also went thru a mild code clean up. > > While the guspnp14 is stabilized for cards other than the guspnp, > Luigi started a badly needed rewrite of the sound driver mostly > because the existing guspnp14 or linux sound driver 3.5 we find > overly complex and a general mechanism for PnP sound cards needs > to be implemented. > > So in a nutshell, Luigi is spearheading the new sound driver project > for FreeBSD and guspnp14 is a stop gap till we managed to complete > the new sound driver. As for the stability of guspnp14 is pretty > rock solid right now however is very difficult to maintain. > > guspnp14 doesn not offer the ability to open a sound card multiple > times it does offer, for the guspnp, full duplex audio using a > single file descriptor. > > > The isa_dmastatus comes in handy for cards that are ill behaved > or that for some reason the sound cards seems to miss interrupts. > Haven't run into this sort of problem with the gus however it > has surfaced a lot with the sb16 pnp. > > > To download the most recent version of the guspnp series of sound driver: > ftp://rah.star-gate.com/pub/guspnp.tar.gz > > Luigi's latest snapshot is at: > > http://www.iet.unipi.it/~luigi/snd970731.tgz > > Folks, now is a good time to join the sound driver project! > So subscribe to the multimedia mailing list and hack away 8) > > Regards, > Amancio > > >From The Desk Of Howard Lew : > > > > I had a chance to play around with the sound code. I like the driver > > documentation a lot. > > > > Is the guspnp14 stuff much different from Luigi's snd970726 code? > > > > Hmmm... Is the isa_dmastatus really used at this point? I looked around > > the isa code trying to patch it up to compile, but I couldn't find a > > function related to it. > > > > Or was this the question below? > > > > > > > > > > I am having a problem related to the having multiple (actually, > > > 2) open descriptors on the same character device. More specifically, > > > I notice that only the last close does actually invoke the device > > > close routine. > > > > > > >From the code in /sys/miscfs/specfs/spec_vnops.c, function > > > spec_close(), this behaviour seems intentional. But can someone > > > explain why this is done and where this is useful ? > > > I do not dare to suggest that this be changed since I guess it would > > > break many things... or not ? > > > > > > In my case, I have implemented the ability of having up to two open > > > descriptors on full-duplex audio devices, one for read and one for > > > write. The above behaviour does not let me record that a channel > > > has been freed (this I would have done using the close() call), > > > and complicates life to the driver since it has to guess what is > > > happening. > > > > > > I do have locks on concurrent operations of the same type, and have > > > implemented some hacks to (more or less) control that proper device > > > usage is done. However, these are hacks, and the lack of information > > > can cause suboptimal behaviours. As an example, due to the missing > > > close I cannot decide to stop a DMA read since I don't know if the > > > reading process has gone. > > > > > > 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/ > > > _____________________________|______________________________________ > > > > > > > > > > > > > --------------------------------------------------------------------------- > > Shoppers Network (Support) AMD K5/K6s, Cyrix 6x86, Intel Pentiums/Pro > > Phone: (415) 759-8584 Email: howard@shoppersnet.com > > ==============================> WWW - http://www.shoppersnet.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > > --------------------------------------------------------------------------- Shoppers Network (Support) AMD K5/K6s, Cyrix 6x86, Intel Pentiums/Pro Phone: (415) 759-8584 Email: howard@shoppersnet.com ==============================> WWW - http://www.shoppersnet.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~