From owner-freebsd-multimedia Sun Jul 13 01:52:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA11691 for multimedia-outgoing; Sun, 13 Jul 1997 01:52:41 -0700 (PDT) Received: from iafnl.es.iaf.nl (uucp@iafnl.es.iaf.nl [195.108.17.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id BAA11684 for ; Sun, 13 Jul 1997 01:52:37 -0700 (PDT) Received: by iafnl.es.iaf.nl with UUCP id AA21258 (5.67b/IDA-1.5 for freebsd-multimedia@FreeBSD.ORG); Sun, 13 Jul 1997 10:52:37 +0200 Received: (from wilko@localhost) by yedi.iaf.nl (8.8.5/8.6.12) id WAA01978; Sat, 12 Jul 1997 22:51:08 +0200 (MET DST) From: Wilko Bulte Message-Id: <199707122051.WAA01978@yedi.iaf.nl> Subject: Re: Photo manipulation SW To: narvi@haldjas.folklore.ee (Narvi) Date: Sat, 12 Jul 1997 22:51:07 +0200 (MET DST) Cc: n9ogk@juno.com, freebsd-multimedia@FreeBSD.ORG In-Reply-To: from "Narvi" at Jul 12, 97 08:36:58 pm X-Mailer: ELM [version 2.4 PL24 ME8a] 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 As Narvi wrote... > > On Sat, 12 Jul 1997, Jack W Doyle wrote: > > A bit about Photoshop: It's a Lose95 photo-manipulation software, with > > No it isn't. Yes, it does have a port for win32, but it isn't win > specific. I actually think it originated on the Mac. I also think it has > ports to other platforms. There is also a Solaris version, but probably more Unix variants. Wilko _ ____________________________________________________________________ | / o / / _ Bulte email: wilko@yedi.iaf.nl - Arnhem, The Netherlands |/|/ / / /( (_) Do, or do not. There is no 'try' - Yoda -------------------------------------------------------------------------- From owner-freebsd-multimedia Sun Jul 13 04:40:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA15355 for multimedia-outgoing; Sun, 13 Jul 1997 04:40:43 -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 EAA15350 for ; Sun, 13 Jul 1997 04:40:40 -0700 (PDT) Received: (from n9ogk@juno.com) by x14.boston.juno.com (queuemail) id HMC18814; Sun, 13 Jul 1997 07:39:41 EDT To: freebsd-multimedia@freebsd.org Date: Sun, 13 Jul 1997 06:29:03 -0500 Subject: Re: Photo manipulation SW Message-ID: <19970713.062904.11966.0.N9OGK@juno.com> References: <199707122326.QAA01560@rah.star-gate.com> X-Mailer: Juno 1.38 X-Juno-Line-Breaks: 1-2,4-8 From: n9ogk@juno.com (Jack W Doyle) Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Right now, buying the new FreeBSD 3.0-current CD-ROM is not an option for me, but I expect it to become an option in the near future. I apologize for the crappy situation that I am in at this time, but I do want to see what gimp is like :) Jack The faster your computer is, the slower your life becomes. From owner-freebsd-multimedia Sun Jul 13 09:34:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA26950 for multimedia-outgoing; Sun, 13 Jul 1997 09:34:36 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.186.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA26945 for ; Sun, 13 Jul 1997 09:34:31 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id JAA03010 for ; Sun, 13 Jul 1997 09:34:30 -0700 (PDT) Date: Sun, 13 Jul 1997 09:34:29 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: multimedia@freebsd.org Subject: little green men 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 again... tried recompiling vic with no success. Still have green screen. See http://resnet.uoregon.edu/dwhite/vic-green.gif for pic. I'm guessing some sort of byteswapping is at fault. When we init the device, we probably should throw a set of ioctl()s at it that restores the device to the default boot-time state, which is what vic is expecting. I don't get green if I don't run fxtv first. I'm not familiar with the vic grabber interface, but it looks like the necessary ioctl()s would end up in MeteorGrabber::format(). Format() is called before start() so it should be an okay place for it. Now we need to know the boot-time state of the driver. Or else fxtv could be a good little monkey and restore the driver state on exit. ;) Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major Spam routed to /dev/null by Procmail | Death to Cyberpromo From owner-freebsd-multimedia Sun Jul 13 11:54:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03246 for multimedia-outgoing; Sun, 13 Jul 1997 11:54: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 LAA03241 for ; Sun, 13 Jul 1997 11:54:28 -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 LAA01669; Sun, 13 Jul 1997 11:53:42 -0700 (PDT) Message-Id: <199707131853.LAA01669@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Doug White cc: multimedia@FreeBSD.ORG Subject: Re: little green men In-reply-to: Your message of "Sun, 13 Jul 1997 09:34:29 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 11:53:42 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Is this with rah's bt848 driver ? Tnks, Amancio >From The Desk Of Doug White : > Hi again... tried recompiling vic with no success. Still have green > screen. See http://resnet.uoregon.edu/dwhite/vic-green.gif for pic. > > I'm guessing some sort of byteswapping is at fault. > > When we init the device, we probably should throw a set of ioctl()s at it > that restores the device to the default boot-time state, which is what vic > is expecting. I don't get green if I don't run fxtv first. > > I'm not familiar with the vic grabber interface, but it looks like the > necessary ioctl()s would end up in MeteorGrabber::format(). Format() is > called before start() so it should be an okay place for it. > > Now we need to know the boot-time state of the driver. > > Or else fxtv could be a good little monkey and restore the driver state on > exit. ;) > > Doug White | University of Oregon > Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant > http://gladstone.uoregon.edu/~dwhite | Computer Science Major > Spam routed to /dev/null by Procmail | Death to Cyberpromo > From owner-freebsd-multimedia Sun Jul 13 12:56:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA05011 for multimedia-outgoing; Sun, 13 Jul 1997 12:56:04 -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 MAA04989 for ; Sun, 13 Jul 1997 12:55:59 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 15:54:56 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA25601; Sun, 13 Jul 97 15:54:55 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id PAA05237; Sun, 13 Jul 1997 15:52:56 -0400 Message-Id: <19970713155256.41366@ct.picker.com> Date: Sun, 13 Jul 1997 15:52:56 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp9 feedback Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Had a few minutes to sit down and build the latest driver. It appears that you changed some protos in sound_calls.h and didn't flow them to all the .c files. attach looks like it now returns void rather than long and doesn't take a mem_start arg anymore. Not knowing what the intent was, I'm not sure I'd make the right fix. Can you update the code and mail me the diffs. Also, you might build a sound driver with all the devices compiled in. That should be a pretty good build stress-test for the upcoming release. (In particular, adding: device awe0 at isa? port 0x620 will show the below problem.) Thanks, Randall cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I/usr/include -DDEFAULT_CHNLSET=1 -DEXT2FS -DMSDOSFS -DCD9660 -DNFS -DFFS -DINET -DCOMPAT_43 -DKERNEL ../../i386/isa/sound/awe_wave.c ../../i386/isa/sound/awe_wave.c:428: warning: initialization from incompatible pointer type ../../i386/isa/sound/awe_wave.c:450: conflicting types for `attach_awe_obsolete' ../../i386/isa/sound/sound_calls.h:136: previous declaration of `attach_awe_obsolete' ../../i386/isa/sound/awe_wave.c:514: warning: no previous prototype for `unload_awe' *** Error code 1 Stop. From owner-freebsd-multimedia Sun Jul 13 13:10:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA05519 for multimedia-outgoing; Sun, 13 Jul 1997 13:10: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 NAA05513 for ; Sun, 13 Jul 1997 13:10:22 -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 NAA07974; Sun, 13 Jul 1997 13:10:20 -0700 (PDT) Message-Id: <199707132010.NAA07974@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@freebsd.org Subject: Re: guspnp9 feedback In-reply-to: Your message of "Sun, 13 Jul 1997 15:52:56 EDT." <19970713155256.41366@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 13:10:20 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In /sys/i386/isa/sound/sound_calls.h change the prototype from void to int: /* From awe_wave.c */ int attach_awe_obsolete(struct address_info *hw_config); Recompile the kernel and please let us know if the driver works for you. Tnks, Amancio >From The Desk Of Randall Hopper : > Had a few minutes to sit down and build the latest driver. It appears > that you changed some protos in sound_calls.h and didn't flow them to all > the .c files. attach looks like it now returns void rather than long and > doesn't take a mem_start arg anymore. > > Not knowing what the intent was, I'm not sure I'd make the right fix. > Can you update the code and mail me the diffs. Also, you might build a > sound driver with all the devices compiled in. That should be a pretty > good build stress-test for the upcoming release. (In particular, adding: > > device awe0 at isa? port 0x620 > > will show the below problem.) > > Thanks, > > Randall > > > cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-exter ns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -nostdinc -I- -I. -I../.. -I/usr/include -DDEFAULT_CHNLSET=1 -DEXT2FS -DMSDOSFS -DCD9660 -DNFS - DFFS -DINET -DCOMPAT_43 -DKERNEL ../../i386/isa/sound/awe_wave.c > ../../i386/isa/sound/awe_wave.c:428: warning: initialization from incompatibl e pointer type > ../../i386/isa/sound/awe_wave.c:450: conflicting types for `attach_awe_obsole te' > ../../i386/isa/sound/sound_calls.h:136: previous declaration of `attach_awe_o bsolete' > ../../i386/isa/sound/awe_wave.c:514: warning: no previous prototype for `unlo ad_awe' > *** Error code 1 > > Stop. From owner-freebsd-multimedia Sun Jul 13 13:34:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA06267 for multimedia-outgoing; Sun, 13 Jul 1997 13:34:45 -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 NAA06262 for ; Sun, 13 Jul 1997 13:34:42 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 16:34:11 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA26109; Sun, 13 Jul 97 16:34:10 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id QAA05293; Sun, 13 Jul 1997 16:32:10 -0400 Message-Id: <19970713163210.43120@ct.picker.com> Date: Sun, 13 Jul 1997 16:32:10 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: Re: guspnp9 feedback References: <19970713155256.41366@ct.picker.com> <199707132010.NAA07974@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707132010.NAA07974@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 01:10:20PM -0700 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk As I said, it's not just the return type. < long attach_awe_obsolete(long mem_start, struct address_info *hw_config); > void attach_awe_obsolete(struct address_info *hw_config); Randall Amancio Hasty: |In /sys/i386/isa/sound/sound_calls.h change the prototype from void to int: | |/* From awe_wave.c */ |int attach_awe_obsolete(struct address_info *hw_config); | |Recompile the kernel and please let us know if the driver works for you. | | Tnks, | Amancio | | |From The Desk Of Randall Hopper : |> Had a few minutes to sit down and build the latest driver. It appears |> that you changed some protos in sound_calls.h and didn't flow them to all |> the .c files. attach looks like it now returns void rather than long and |> doesn't take a mem_start arg anymore. |> |> Not knowing what the intent was, I'm not sure I'd make the right fix. |> Can you update the code and mail me the diffs. Also, you might build a |> sound driver with all the devices compiled in. That should be a pretty |> good build stress-test for the upcoming release. (In particular, adding: |> |> device awe0 at isa? port 0x620 |> |> will show the below problem.) From owner-freebsd-multimedia Sun Jul 13 14:06:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07401 for multimedia-outgoing; Sun, 13 Jul 1997 14:06:27 -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 OAA07396 for ; Sun, 13 Jul 1997 14:06:20 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 17:05:46 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA26549; Sun, 13 Jul 97 17:05:45 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA05401; Sun, 13 Jul 1997 17:03:46 -0400 Message-Id: <19970713170346.27065@ct.picker.com> Date: Sun, 13 Jul 1997 17:03:46 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp9: Warp speed /dev/audio! Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk First, hope this is the right sound driver version to be testing. If not, please let me know so I can switch to the one where the comments will be the most help. Check this out! On guspnp9, if I: cat james-earl-jones-CNN.au > /dev/audio this 5 second clip flies by in less than one second! :-) The frequency is shifted way up. Besides that and the speed, it sounds OK so I guess the samples rate and/or mono-stereo setting might not be being initialized right when the driver is accessed from /dev/audio. BTW, this is on a Sound Blaster 32 (dsp-wise a SB16). Randall From owner-freebsd-multimedia Sun Jul 13 14:15:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07698 for multimedia-outgoing; Sun, 13 Jul 1997 14:15:08 -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 OAA07690 for ; Sun, 13 Jul 1997 14:15:05 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 17:13:49 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA26649; Sun, 13 Jul 97 17:13:48 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA05410; Sun, 13 Jul 1997 17:11:49 -0400 Message-Id: <19970713171149.34096@ct.picker.com> Date: Sun, 13 Jul 1997 17:11:49 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp9: /dev/dsp close() hangs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, first thanks for your previous work on the lock-ups! I haven't crashed my machine Ctrl-Cing audio apps yet and I've sure been trying. :-) A related problem I am seeing though is that about 20% of the time, Ctrl-Cing a /dev/dsp play app causes the sound driver to block inside of close(). It doesn't hang the machine (thank goodness), just the app. E.g. with mpg123: ----> THESE LINES REPEAT (WRITE AUDIO DATA UNTIL DONE...): 566 mpg123 RET read 8192/0x2000 566 mpg123 CALL write(0x4,0x34000,0x8000) 566 mpg123 GIO fd 4 wrote 32768 bytes ----> CTRL-C HIT HERE...TRY TO CLOSE-UP SHOP: 566 mpg123 RET write 32768/0x8000 566 mpg123 CALL write(0x4,0x34000,0x8000) 566 mpg123 PSIG SIGINT caught handler=0x2a10 mask=0x0 code=0x0 566 mpg123 RET write -1 errno 4 Interrupted system call 566 mpg123 CALL sigreturn(0xefbfcae8) 566 mpg123 RET sigreturn JUSTRETURN 566 mpg123 CALL close(0x3) 566 mpg123 RET close 0 566 mpg123 CALL write(0x2,0xefbfcc64,0x28) 566 mpg123 GIO fd 2 wrote 40 bytes "[0:01] Decoding of things.mp2 finished. " 566 mpg123 RET write 40/0x28 566 mpg123 CALL gettimeofday(0xefbfd3a4,0) 566 mpg123 RET gettimeofday 0 566 mpg123 CALL write(0x4,0x34000,0xa00) 566 mpg123 GIO fd 4 wrote 2560 bytes 566 mpg123 RET write 2560/0xa00 566 mpg123 CALL close(0x4) ----> WE'RE NOW BLOCKED WAITING ON /DEV/DSP CLOSE...IT DOESN'T COME BACK ----> CTRL-C HIT AGAIN 566 mpg123 PSIG SIGINT caught handler=0x2a10 mask=0x0 code=0x0 566 mpg123 RET close 0 566 mpg123 CALL sigreturn(0xefbfd334) 566 mpg123 RET sigreturn JUSTRETURN 566 mpg123 CALL exit(0) Hope this helps. If you need more info, let me know. Thanks, Randall From owner-freebsd-multimedia Sun Jul 13 14:20:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA07918 for multimedia-outgoing; Sun, 13 Jul 1997 14:20: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 OAA07909 for ; Sun, 13 Jul 1997 14:20:17 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 17:19:46 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA26733; Sun, 13 Jul 97 17:19:44 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA05430; Sun, 13 Jul 1997 17:17:46 -0400 Message-Id: <19970713171745.52107@ct.picker.com> Date: Sun, 13 Jul 1997 17:17:45 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp9: pas.h -> pas_hw.h rename needed Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In guspnp9, pas.h needs to be renamed to pas_hw.h to avoid conflicts with the "config"-generated build file. My guspnp7+SB patch you merged in a while back changed all the pas.h include refs to pas_hw.h, so that's taken care of. Just need to rename that one include. Thanks, Randall From owner-freebsd-multimedia Sun Jul 13 14:55:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA09069 for multimedia-outgoing; Sun, 13 Jul 1997 14:55:38 -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 OAA09064 for ; Sun, 13 Jul 1997 14:55:35 -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 OAA00289; Sun, 13 Jul 1997 14:55:28 -0700 (PDT) Message-Id: <199707132155.OAA00289@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! In-reply-to: Your message of "Sun, 13 Jul 1997 17:03:46 EDT." <19970713170346.27065@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 14:55:28 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Curious, Does this happen the first time or always? Do you happen to know at what frequency was james-earl-jones-CNN.au recorded at? Tnks, Amancio >From The Desk Of Randall Hopper : > First, hope this is the right sound driver version to be testing. If not, > please let me know so I can switch to the one where the comments will be > the most help. > > Check this out! On guspnp9, if I: > > cat james-earl-jones-CNN.au > /dev/audio > > this 5 second clip flies by in less than one second! :-) The frequency is > shifted way up. Besides that and the speed, it sounds OK so I guess the > samples rate and/or mono-stereo setting might not be being initialized > right when the driver is accessed from /dev/audio. > > BTW, this is on a Sound Blaster 32 (dsp-wise a SB16). > > Randall > From owner-freebsd-multimedia Sun Jul 13 15:10:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA09670 for multimedia-outgoing; Sun, 13 Jul 1997 15:10:50 -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 PAA09665 for ; Sun, 13 Jul 1997 15:10:44 -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 PAA00422; Sun, 13 Jul 1997 15:10:41 -0700 (PDT) Message-Id: <199707132210.PAA00422@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback In-reply-to: Your message of "Sun, 13 Jul 1997 16:32:10 EDT." <19970713163210.43120@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 15:10:41 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi took out the mem_start since it was not been used. Have you try out guspnp9 with your awe? Tnks, Amancio >From The Desk Of Randall Hopper : > As I said, it's not just the return type. > > < long attach_awe_obsolete(long mem_start, struct address_info *hw_config); > > void attach_awe_obsolete(struct address_info *hw_config); > > Randall > > Amancio Hasty: > |In /sys/i386/isa/sound/sound_calls.h change the prototype from void to int: > | > |/* From awe_wave.c */ > |int attach_awe_obsolete(struct address_info *hw_config); > | > |Recompile the kernel and please let us know if the driver works for you. > | > | Tnks, > | Amancio > | > | > |From The Desk Of Randall Hopper : > |> Had a few minutes to sit down and build the latest driver. It appea rs > |> that you changed some protos in sound_calls.h and didn't flow them to all > |> the .c files. attach looks like it now returns void rather than long and > |> doesn't take a mem_start arg anymore. > |> > |> Not knowing what the intent was, I'm not sure I'd make the right fix . > |> Can you update the code and mail me the diffs. Also, you might build a > |> sound driver with all the devices compiled in. That should be a pretty > |> good build stress-test for the upcoming release. (In particular, adding: > |> > |> device awe0 at isa? port 0x620 > |> > |> will show the below problem.) From owner-freebsd-multimedia Sun Jul 13 15:18:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA10051 for multimedia-outgoing; Sun, 13 Jul 1997 15:18:02 -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 PAA10046 for ; Sun, 13 Jul 1997 15:17: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 PAA00499; Sun, 13 Jul 1997 15:17:51 -0700 (PDT) Message-Id: <199707132217.PAA00499@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! In-reply-to: Your message of "Sun, 13 Jul 1997 17:03:46 EDT." <19970713170346.27065@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 15:17:51 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk If you can't find au file which has been recorded at 8khz , feel free to download : ftp://rah.star-gate.com/pub/sorrydave.au Amancio From owner-freebsd-multimedia Sun Jul 13 15:25:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA10347 for multimedia-outgoing; Sun, 13 Jul 1997 15:25:53 -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 PAA10335 for ; Sun, 13 Jul 1997 15:25:43 -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 PAA00590; Sun, 13 Jul 1997 15:25:39 -0700 (PDT) Message-Id: <199707132225.PAA00590@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Sun, 13 Jul 1997 17:11:49 EDT." <19970713171149.34096@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 15:25:39 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I need a little more info. in dmabuf.c:dma_sync while (!(out_sleep_flag[dev].aborting) && audio_devs[dev]->dmap_out->qlen) { int flag, chn; printf("dmabuf %d \n", audio_devs[dev]->dmap_out->qlen); Add the above printf and please send me the output of the last few lines . Tnks, Amanco >From The Desk Of Randall Hopper : > Well, first thanks for your previous work on the lock-ups! I haven't > crashed my machine Ctrl-Cing audio apps yet and I've sure been trying. :-) > > A related problem I am seeing though is that about 20% of the time, > Ctrl-Cing a /dev/dsp play app causes the sound driver to block inside of > close(). It doesn't hang the machine (thank goodness), just the app. > E.g. with mpg123: > > ----> THESE LINES REPEAT (WRITE AUDIO DATA UNTIL DONE...): > 566 mpg123 RET read 8192/0x2000 > 566 mpg123 CALL write(0x4,0x34000,0x8000) > 566 mpg123 GIO fd 4 wrote 32768 bytes > > ----> CTRL-C HIT HERE...TRY TO CLOSE-UP SHOP: > 566 mpg123 RET write 32768/0x8000 > 566 mpg123 CALL write(0x4,0x34000,0x8000) > 566 mpg123 PSIG SIGINT caught handler=0x2a10 mask=0x0 code=0x0 > 566 mpg123 RET write -1 errno 4 Interrupted system call > 566 mpg123 CALL sigreturn(0xefbfcae8) > 566 mpg123 RET sigreturn JUSTRETURN > 566 mpg123 CALL close(0x3) > 566 mpg123 RET close 0 > 566 mpg123 CALL write(0x2,0xefbfcc64,0x28) > 566 mpg123 GIO fd 2 wrote 40 bytes > "[0:01] Decoding of things.mp2 finished. > " > 566 mpg123 RET write 40/0x28 > 566 mpg123 CALL gettimeofday(0xefbfd3a4,0) > 566 mpg123 RET gettimeofday 0 > 566 mpg123 CALL write(0x4,0x34000,0xa00) > 566 mpg123 GIO fd 4 wrote 2560 bytes > > 566 mpg123 RET write 2560/0xa00 > 566 mpg123 CALL close(0x4) > > ----> WE'RE NOW BLOCKED WAITING ON /DEV/DSP CLOSE...IT DOESN'T COME BACK > > ----> CTRL-C HIT AGAIN > 566 mpg123 PSIG SIGINT caught handler=0x2a10 mask=0x0 code=0x0 > 566 mpg123 RET close 0 > 566 mpg123 CALL sigreturn(0xefbfd334) > 566 mpg123 RET sigreturn JUSTRETURN > 566 mpg123 CALL exit(0) > > Hope this helps. If you need more info, let me know. > > Thanks, > > Randall From owner-freebsd-multimedia Sun Jul 13 15:47:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA11463 for multimedia-outgoing; Sun, 13 Jul 1997 15:47:38 -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 PAA11452 for ; Sun, 13 Jul 1997 15:47:34 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 18:46:30 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA27792; Sun, 13 Jul 97 18:46:29 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA05715; Sun, 13 Jul 1997 18:44:27 -0400 Message-Id: <19970713184427.05917@ct.picker.com> Date: Sun, 13 Jul 1997 18:44:27 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! References: <19970713170346.27065@ct.picker.com> <199707132155.OAA00289@rah.star-gate.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="pWyiEgJYm5f9v55/" X-Mailer: Mutt 0.76 In-Reply-To: <199707132155.OAA00289@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 02:55:28PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Amancio Hasty: |Does this happen the first time or always? |Do you happen to know at what frequency was james-earl-jones-CNN.au |recorded at? | |From The Desk Of Randall Hopper : |> cat james-earl-jones-CNN.au > /dev/audio |> |> this 5 second clip flies by in less than one second! :-) The frequency is |If you can't find au file which has been recorded at 8khz , |feel free to download : |ftp://rah.star-gate.com/pub/sorrydave.au Thanks, I had one. Just running many more tests to try and provide more info for you. sorrydave.au plays at light speed as well on guspnp9; plays fine on Vox30 (current drivers). Here's a salient piece of info. On guspnp9 if I record a 8012Hz mono 8-bit sample via /dev/dsp that's 6.5 seconds long, I get a file that's 327k long instead of around 56k (simple record and play test code attached). If I play it also via guspnp9 it sounds fine. I think this is the underlying problem. Seems like /dev/audio and /dev/dsp are reading/writing bigger samples than they should. If I use the same code to record a 8012Hz mono 8-bit sample on Vox30, verify it plays fine on Vox30, verify the size makes sence, and then play it with guspnp9, I get light speed mice. Seems to confirm the sample size discrepency. BTW, in case it helps, I was able to play prerecorded 8000k/8012k .au's OK on guspnp7, so it's likely a recent change that's the culprit. Randall --pWyiEgJYm5f9v55/ Content-Type: application/octet-stream Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="play.c.gz" H4sIAJhYyTMAA41UbW/bNhD+bP2KqwfMUuHXousGZ06Xxk5rIJWL2kUwZIFBkZRFVCI1krLn Dvnvu5OUrs4WbIZk8Y7PvT3H4+h5APTAUoPPJOTMeZClcUZICOeSw49RH9Z7qeGNZVpInVR2 B44pMSWzc7jJmAdh4GgqqJwEb6DM2XFkJTdWwGtoYOEhUzyD0pqdZQWgK8jMAbjRqdpVVoo+ eJnnUEiQe2mPPlN6B9OoNV9npsoFMOhyDKdYwSavEuUdK8pcDlmFkJGQ+xGrhDJd2Km9rDOa vAKEgal8WfmvuVzAm+Vb4JiEEsxLSI1tqy/k4PdKOq+MHph0gMrBUTLbB2esPT6LyAG976SV wPAlM6OlgyVVPwTo5cp5qXugHBRGm4HR+bEPSeURy3zPASnIB9MGrS0ow30eRsAO7DiEHrHX g4NCMljuGjaJVYrkSsk+o8lB+axWDBx5cijzbPiQ3GDONMQSjTWJQtfLX2ThygxzHXJTtNBR EHynNM8r7PbPBeNIuhw5U2nBmRXD7Pxftktek6zM6bbzIlfJqS7l2uf/gDWWQcGUDpX2SOOO 94FnzMJzXO9v76Lgz6BDW6k4axaW2jSDn8aTF62Guk+aVnxgZgbjVoMONVWOqsmDqv3mUuOq jphU6e1k/OLl3VkQdPCM5njsQ442O+lN6cMmOUqrD107TaZ86rpRBM9msFhdRUEHM+00/EPI Ua4VHc5wFHquNyXh79wokU4nsSjTCvDXIG2DbMtk3qgQo2PY6CkL3lh8U+X/sUoaq5a8py3a Al63QWoha4TSIoUphN36YN4O3B3+8a90k2TrftEqqft095vuNgHkH8qHk0fB7gN8sDPotKWq 5bU+aFulU7PFY6I8gfEzpMjDZva3LWX0OdmWmhtBd8gMLj7Nl6vtIr5czZfx2+3Hi5sT5A4P IvXmh/GJumR0nc1gUDctFbg0pdRht75o2ino9mG1vfm4iq9/rYtqZjnF26wJul5slvHVqg/f o9/orIOVApIkm/oeOxWufNrhOp5fbq638/UH8nr1foNOidzHsNWneL79cPkevSw3C6x2s0Ak 8fMfyMt3F3G8uF4j+qGZZHH/zWDg4BDXkokwRY02Ic2zjuh+S/GSVF+kSUNcRzgi5zCmeThY 5WUdsMagFXq9D/4CwnGYRXoGAAA= --pWyiEgJYm5f9v55/ Content-Type: application/octet-stream; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="record.c.gz" =1F=8B=08=00=99X=C93=00=03=8DTao=D30=10=FD=DC=FC=8A[=114=99=9AvE=08P=CB=06= =DB=DA=C1=A4=D1=A2=B5=08=A11U=8E}i,=12;=D8NKA=FB=EF=9C=93 =18H=88(Q=E3=97= =F7=EE=CE=EF=CE=1D=1EB=00=87t=C3=A5=02=97!=E4=CC:=C0R[-=10=C2)rx=16=F5a=B9E= =05g=86)=81*=A9=CC=06,=93b=ECe'=F0!c=0E=84=86=BD=AE=A0=B2=08NC=99=B3=FD=D0 = =D7F=C0=CB=86=15=EE2=C93(=8D=DE=18V=00E=82L=EF=80k=95=CAMeP=F4=C1a=9EC=81= =80[4{=97I=B5=81q=D4=A8=97=99=AEr=01=0C=BA=9C=92IV=B0=D1=D3D:=CB=8A2=C7=01= =AB=882=14=B8=1D=B2JH=DD=85=8D=DCb]=CF=E8)=10=0Dt=E5=CA=CA=FD=AC=E4=14=CE._= =03=A7=12=A4`=0E!=D5=A6=DDz=81=F1=97=0A=AD=93Z=C5:=8D =8C=F7=C8L=1F=AC6f=7F= =10=B5V=BDA=83=C0=E8=F1*=AD=D0=C2=A5=DF=F9=00=A0=97K=EBP=F5@Z(=B4=D2=B1V=F9= =BE=0FI=E5=88=CB\=CF=82=07|=0C=A64=A9=0DH=CD]=1EF=C0vl?=80=9Ew=AE=07;IN=B0= =DC6NzG}&["=FBL=92=9DtY=0D=C4=D6G=B2=B4=E6=D9=A0=AD-=9E2=05s$=AD=F2K=A1=EA= =D7WX=D82=A3R=07\=17=1E=A7g=18=04=0F=A4=E2yE=8D~Q0N=86=E3=D0=EAJ =CE=8C=18d= '=BF}Fc=94=BE=0FY'r=99=DC=C7R=AE\=FE=17M=D6=CA=A0`R=85R9rn=C3=FB=C03f=E0=90= =DE=B77=B7Q=F0=3D=E8=F8O=A9=80c=D0%=AA=B0[=F7S=D8=B2=DB=87=C5=FAz=BA=98_}= =8C&=0D=CB=F8=AE=1D=C3=F3=A3=D1=E3=16=F1=B3=E0=91I=00ty=84=C2+BF-=81=B7=BF9= *z=ABs'Uz3:z=FC=E4v=12=04=1D=9A=CE=9C=E6=3D=E4=A4=D9=A0=D3=A5=0B=9B2}=81}= =E8ff=9C=8C=F9=B8=1BEpp=0C=B3=C5E=14t=A8=E6Nc>=84=9C=D65=E0=F3sF=C7=A0gzcZw= =DAb=99=D32=A4=B0=14=CFo=A3=D3I=0CusrO=914=8Av3=FF=A3=E0=8D=A2=DD=EC=FF(^= =D6=8A_=EB=AC=89P=1Ar'=85=B0=DB=0C0=C4=A6q9N=1Aoc^;=EA=A7=E9=93=EA6=D1=F1= =ABt=E1=E8=8FLw=01=DD=E4u=3D=D6)=9D=EA=E5|z=BE=BAZO=97=EF=D6=CB=D9=EA=E2=ED= =AA=0F=8F|=C8=BA=99=BFX=8B=F7=F3=E9=FA=DD=F9=DB=F5=F5=ECt=BA=BE>]=CD=88=E7K= =F8'=EF=FC=CD=E9|>=BBZ=12=D7=97=17=FD=DEJj5yBu=89ZI=ED=A6s,=BF=A1NCz=8F=A8= =93'p=E4=DB=B63=D2a=98=92J=E9=90=E6=95=FE-=A2=96OP=D4=CC=94=BF=D2=C6=A5=10= =88D'=82=C6=A2=8E=1EA=CAH,&P=1F=13J=FA=D0=9BD=D9=9C!D=9B=B0=C6#=A0Pw=C1=0Fr= =1E=D4=A2r=05=00=00 --pWyiEgJYm5f9v55/-- From owner-freebsd-multimedia Sun Jul 13 15:59:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA11850 for multimedia-outgoing; Sun, 13 Jul 1997 15:59:18 -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 PAA11842 for ; Sun, 13 Jul 1997 15:59:13 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 18:58:10 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA27933; Sun, 13 Jul 97 18:58:08 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA05729; Sun, 13 Jul 1997 18:56:09 -0400 Message-Id: <19970713185609.15629@ct.picker.com> Date: Sun, 13 Jul 1997 18:56:09 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback References: <19970713163210.43120@ct.picker.com> <199707132210.PAA00422@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707132210.PAA00422@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 03:10:41PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |Luigi took out the mem_start since it was not been used. |Have you try out guspnp9 with your awe? |> < long attach_awe_obsolete(long mem_start, struct address_info *hw_config); |> > void attach_awe_obsolete(struct address_info *hw_config); No, I hadn't. That was the purpose of the first message in this thread; to let you guys know about compile problems and the change that wasn't flowed everywhere. As to the apropriate fix for this: this routine currently returns a pointer to its malloced sample memory if successful, and 0 if not. Is it now assumed that the malloc will always succeed? Or should the malloc move someplace else based on the redesigns you and Luigi are doing? Randall From owner-freebsd-multimedia Sun Jul 13 16:06:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA12260 for multimedia-outgoing; Sun, 13 Jul 1997 16:06:17 -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 QAA12255 for ; Sun, 13 Jul 1997 16:06: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 QAA00971; Sun, 13 Jul 1997 16:06:11 -0700 (PDT) Message-Id: <199707132306.QAA00971@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback In-reply-to: Your message of "Sun, 13 Jul 1997 18:56:09 EDT." <19970713185609.15629@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 16:06:10 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We have a little disconnect here since it is Luigi who took out mem_start so I am force to wait for him to answer back and I have no clue why he decided to turn the attach routine from long to void. Can you try out the driver to see if it can uncover other problems while we wait for Luigi? Tnks, Amancio >From The Desk Of Randall Hopper : > Amancio Hasty: > |Luigi took out the mem_start since it was not been used. > |Have you try out guspnp9 with your awe? > > |> < long attach_awe_obsolete(long mem_start, struct address_info *hw_config ); > |> > void attach_awe_obsolete(struct address_info *hw_config); > > > No, I hadn't. That was the purpose of the first message in this thread; to > let you guys know about compile problems and the change that wasn't flowed > everywhere. > > As to the apropriate fix for this: this routine currently returns a > pointer to its malloced sample memory if successful, and 0 if not. Is it > now assumed that the malloc will always succeed? Or should the malloc move > someplace else based on the redesigns you and Luigi are doing? > > Randall > From owner-freebsd-multimedia Sun Jul 13 16:17:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA12555 for multimedia-outgoing; Sun, 13 Jul 1997 16:17:59 -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 QAA12550 for ; Sun, 13 Jul 1997 16:17:56 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 19:16:53 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA28172; Sun, 13 Jul 97 19:16:51 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id TAA05839; Sun, 13 Jul 1997 19:14:54 -0400 Message-Id: <19970713191453.21533@ct.picker.com> Date: Sun, 13 Jul 1997 19:14:53 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs References: <19970713171149.34096@ct.picker.com> <199707132225.PAA00590@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707132225.PAA00590@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 03:25:39PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |I need a little more info. | |in dmabuf.c:dma_sync | while (!(out_sleep_flag[dev].aborting) | && audio_devs[dev]->dmap_out->qlen) { | | int flag, chn; | printf("dmabuf %d \n", audio_devs[dev]->dmap_out->qlen); | |Add the above printf and please send me the output of the last few |lines . Ok, here it is: > mpg123 things.mp2 -----> APP STARTUP PRINTS: start sb_reset_dsp done RESET 1 done tenmicrosec done RESET 0 isa_dmastart: channel 5 busy -----> THEN WHEN I CTRL-C, I ALWAYS SEE THIS: dmabuf 2 dmabuf 1 -----> IF THE /dev/dsp close() DIDN'T HANG, THAT'S IT. -----> BUT IF THE close() HUNG, I SEE THIS LINE AGAIN AND AGAIN, PRINTING -----> ONCE EVERY 10 SECONDS: dmabuf 1 Randall From owner-freebsd-multimedia Sun Jul 13 16:20:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA12635 for multimedia-outgoing; Sun, 13 Jul 1997 16:20: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 QAA12629 for ; Sun, 13 Jul 1997 16:20:06 -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 QAA01104; Sun, 13 Jul 1997 16:20:02 -0700 (PDT) Message-Id: <199707132320.QAA01104@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! In-reply-to: Your message of "Sun, 13 Jul 1997 18:44:27 EDT." <19970713184427.05917@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 16:20:02 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk It is hard for me to read the differences between guspnp7 and guspnp9 given that guspnp9 was run thru indent. Typically , this should be done after all the changes have gone in and the driver was tested. So in the meantime, can you drop in the sb* from guspnp7 into guspnp9 and see if you still have problems with recording? You will have to hack the guspnp7 sb* code a little to get it to compile with guspnp9. I moved back guspnp7 to my ftp site in case that you need it. The speed or frequency problem is most likely related to the sb module not setting properly the frequency . Tnks, Amancio >From The Desk Of Randall Hopper : > > --pWyiEgJYm5f9v55/ > Content-Type: text/plain; charset=us-ascii > > Amancio Hasty: > |Does this happen the first time or always? > |Do you happen to know at what frequency was james-earl-jones-CNN.au > |recorded at? > | > |From The Desk Of Randall Hopper : > |> cat james-earl-jones-CNN.au > /dev/audio > |> > |> this 5 second clip flies by in less than one second! :-) The frequency is > > |If you can't find au file which has been recorded at 8khz , > |feel free to download : > |ftp://rah.star-gate.com/pub/sorrydave.au > > Thanks, I had one. Just running many more tests to try and provide more > info for you. > > sorrydave.au plays at light speed as well on guspnp9; plays fine on Vox30 > (current drivers). > > Here's a salient piece of info. On guspnp9 if I record a 8012Hz mono 8-bit > sample via /dev/dsp that's 6.5 seconds long, I get a file that's 327k long > instead of around 56k (simple record and play test code attached). If I > play it also via guspnp9 it sounds fine. I think this is the underlying > problem. > > Seems like /dev/audio and /dev/dsp are reading/writing bigger samples than > they should. > > If I use the same code to record a 8012Hz mono 8-bit sample on Vox30, > verify it plays fine on Vox30, verify the size makes sence, and then play > it with guspnp9, I get light speed mice. Seems to confirm the sample size > discrepency. > > BTW, in case it helps, I was able to play prerecorded 8000k/8012k .au's OK > on guspnp7, so it's likely a recent change that's the culprit. > > Randall > > --pWyiEgJYm5f9v55/ > Content-Type: application/octet-stream > Content-Transfer-Encoding: base64 > Content-Disposition: attachment; filename="play.c.gz" > > H4sIAJhYyTMAA41UbW/bNhD+bP2KqwfMUuHXousGZ06Xxk5rIJWL2kUwZIFBkZRFVCI1krLn > Dvnvu5OUrs4WbIZk8Y7PvT3H4+h5APTAUoPPJOTMeZClcUZICOeSw49RH9Z7qeGNZVpInVR2 > B44pMSWzc7jJmAdh4GgqqJwEb6DM2XFkJTdWwGtoYOEhUzyD0pqdZQWgK8jMAbjRqdpVVoo+ > eJnnUEiQe2mPPlN6B9OoNV9npsoFMOhyDKdYwSavEuUdK8pcDlmFkJGQ+xGrhDJd2Km9rDOa > vAKEgal8WfmvuVzAm+Vb4JiEEsxLSI1tqy/k4PdKOq+MHph0gMrBUTLbB2esPT6LyAG976SV > wPAlM6OlgyVVPwTo5cp5qXugHBRGm4HR+bEPSeURy3zPASnIB9MGrS0ow30eRsAO7DiEHrHX > g4NCMljuGjaJVYrkSsk+o8lB+axWDBx5cijzbPiQ3GDONMQSjTWJQtfLX2ThygxzHXJTtNBR > EHynNM8r7PbPBeNIuhw5U2nBmRXD7Pxftktek6zM6bbzIlfJqS7l2uf/gDWWQcGUDpX2SOOO > 94FnzMJzXO9v76Lgz6BDW6k4axaW2jSDn8aTF62Guk+aVnxgZgbjVoMONVWOqsmDqv3mUuOq > jphU6e1k/OLl3VkQdPCM5njsQ442O+lN6cMmOUqrD107TaZ86rpRBM9msFhdRUEHM+00/EPI > Ua4VHc5wFHquNyXh79wokU4nsSjTCvDXIG2DbMtk3qgQo2PY6CkL3lh8U+X/sUoaq5a8py3a > Al63QWoha4TSIoUphN36YN4O3B3+8a90k2TrftEqqft095vuNgHkH8qHk0fB7gN8sDPotKWq > 5bU+aFulU7PFY6I8gfEzpMjDZva3LWX0OdmWmhtBd8gMLj7Nl6vtIr5czZfx2+3Hi5sT5A4P > IvXmh/GJumR0nc1gUDctFbg0pdRht75o2ino9mG1vfm4iq9/rYtqZjnF26wJul5slvHVqg/f > o9/orIOVApIkm/oeOxWufNrhOp5fbq638/UH8nr1foNOidzHsNWneL79cPkevSw3C6x2s0Ak > 8fMfyMt3F3G8uF4j+qGZZHH/zWDg4BDXkokwRY02Ic2zjuh+S/GSVF+kSUNcRzgi5zCmeThY > 5WUdsMagFXq9D/4CwnGYRXoGAAA= > > --pWyiEgJYm5f9v55/ > Content-Type: application/octet-stream; charset=iso-8859-1 > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; filename="record.c.gz" > > =1F=8B=08=00=99X=C93=00=03=8DTao=D30=10=FD=DC=FC=8A[=114=99=9AvE=08P=CB=06= > =DB=DA=C1=A4=D1=A2=B5=08=A11U=8E}i,=12;=D8NKA=FB=EF=9C=93 =18H=88(Q=E3=97= > =F7=EE=CE=EF=CE=1D=1EB=00=87t=C3=A5=02=97!=E4=CC:=C0R[-=10=C2)rx=16=F5a=B9E= > =05g=86)=81*=A9=CC=06,=93b=ECe'=F0!c=0E=84=86=BD=AE=A0=B2=08NC=99=B3=FD=D0 = > =D7F=C0=CB=86=15=EE2=C93(=8D=DE=18V=00E=82L=EF=80k=95=CAMeP=F4=C1a=9EC=81= > =80[4{=97I=B5=81q=D4=A8=97=99=AEr=01=0C=BA=9C=92IV=B0=D1=D3D:=CB=8A2=C7=01= > =AB=882=14=B8=1D=B2JH=DD=85=8D=DCb]=CF=E8)=10=0Dt=E5=CA=CA=FD=AC=E4=14=CE._= > =03=A7=12=A4`=0E!=D5=A6=DDz=81=F1=97=0A=AD=93Z=C5:=8D =8C=F7=C8L=1F=AC6f=7F= > =10=B5V=BDA=83=C0=E8=F1*=AD=D0=C2=A5=DF=F9=00=A0=97K=EBP=F5@Z(=B4=D2=B1V=F9= > =BE=0FI=E5=88=CB\=CF=82=07|=0C=A64=A9=0DH=CD]=1EF=C0vl?=80=9Ew=AE=07;IN=B0= > =DC6NzG}&["=FBL=92=9DtY=0D=C4=D6G=B2=B4=E6=D9=A0=AD-=9E2=05s$=AD=F2K=A1=EA= > =D7WX=D82=A3R=07\=17=1E=A7g=18=04=0F=A4=E2yE=8D~Q0N=86=E3=D0=EAJ =CE=8C= 18d= > '=BF}Fc=94=BE=0FY'r=99=DC=C7R=AE\=FE=17M=D6=CA=A0`R=85R9rn=C3=FB=C03f=E0=90= > =DE=B77=B7Q=F0=3D=E8=F8O=A9=80c=D0%=AA=B0[=F7S=D8=B2=DB=87=C5=FAz=BA=98_}= > =8C&=0D=CB=F8=AE=1D=C3=F3=A3=D1=E3=16=F1=B3=E0=91I=00ty=84=C2+BF-=81=B7=BF9= > *z=ABs'Uz3:z=FC=E4v=12=04=1D=9A=CE=9C=E6=3D=E4=A4=D9=A0=D3=A5=0B=9B2}=81}= > =E8ff=9C=8C=F9=B8=1BEpp=0C=B3=C5E=14t=A8=E6Nc>=84=9C=D65=E0=F3sF=C7=A0gzcZw= > =DAb=99=D32=A4=B0=14=CFo=A3=D3I=0CusrO=914=8Av3=FF=A3=E0=8D=A2=DD=EC=FF(^= > =D6=8A_=EB=AC=89P=1Ar'=85=B0=DB=0C0=C4=A6q9N=1Aoc^;=EA=A7=E9=93=EA6=D1=F1= > =ABt=E1=E8=8FLw=01=DD=E4u=3D=D6)=9D=EA=E5|z=BE=BAZO=97=EF=D6=CB=D9=EA=E2=ED= > =AA=0F=8F|=C8=BA=99=BFX=8B=F7=F3=E9=FA=DD=F9=DB=F5=F5=ECt=BA=BE>]=CD=88=E7K= > =F8'=EF=FC=CD=E9|>=BBZ=12=D7=97=17=FD=DEJj5yBu=89ZI=ED=A6s,=BF=A1NCz=8F=A8= > =93'p=E4=DB=B63=D2a=98=92J=E9=90=E6=95=FE-=A2=96OP=D4=CC=94=BF=D2=C6=A5=10= > =88D'=82=C6=A2=8E=1EA=CAH,&P=1F=13J=FA=D0=9BD=D9=9C!D=9B=B0=C6#=A0Pw=C1=0Fr= > =1E=D4=A2r=05=00=00 > --pWyiEgJYm5f9v55/-- From owner-freebsd-multimedia Sun Jul 13 16:21:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA12677 for multimedia-outgoing; Sun, 13 Jul 1997 16:21:00 -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 QAA12668 for ; Sun, 13 Jul 1997 16:20:48 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 19:19:44 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA28205; Sun, 13 Jul 97 19:19:43 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id TAA05855; Sun, 13 Jul 1997 19:17:45 -0400 Message-Id: <19970713191745.53643@ct.picker.com> Date: Sun, 13 Jul 1997 19:17:45 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback References: <19970713185609.15629@ct.picker.com> <199707132306.QAA00971@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707132306.QAA00971@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 04:06:10PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |We have a little disconnect here since it is Luigi who took out mem_start |so I am force to wait for him to answer back and I have no clue |why he decided to turn the attach routine from long to void. |Can you try out the driver to see if it can uncover other problems |while we wait for Luigi? Yep, that's what I'm doing. Just built without awe support for now, and am working through the DSP tests I can think of. Randy From owner-freebsd-multimedia Sun Jul 13 16:21:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA12736 for multimedia-outgoing; Sun, 13 Jul 1997 16:21:46 -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 QAA12729 for ; Sun, 13 Jul 1997 16:21: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 QAA01133; Sun, 13 Jul 1997 16:21:38 -0700 (PDT) Message-Id: <199707132321.QAA01133@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Sun, 13 Jul 1997 19:14:53 EDT." <19970713191453.21533@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 16:21:38 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I will review dmabuf to see what is going on. Tnks, Amancio >From The Desk Of Randall Hopper : > Amancio Hasty: > |I need a little more info. > | > |in dmabuf.c:dma_sync > | while (!(out_sleep_flag[dev].aborting) > | && audio_devs[dev]->dmap_out->qlen) { > | > | int flag, chn; > | printf("dmabuf %d \n", audio_devs[dev]->dmap_out->qlen); > | > |Add the above printf and please send me the output of the last few > |lines . > > > Ok, here it is: > > > mpg123 things.mp2 > > -----> APP STARTUP PRINTS: > start sb_reset_dsp > done RESET 1 > done tenmicrosec > done RESET 0 > isa_dmastart: channel 5 busy > > -----> THEN WHEN I CTRL-C, I ALWAYS SEE THIS: > dmabuf 2 > dmabuf 1 > > -----> IF THE /dev/dsp close() DIDN'T HANG, THAT'S IT. > > -----> BUT IF THE close() HUNG, I SEE THIS LINE AGAIN AND AGAIN, PRINTI NG > -----> ONCE EVERY 10 SECONDS: > dmabuf 1 > > Randall > > > > From owner-freebsd-multimedia Sun Jul 13 17:21:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA15464 for multimedia-outgoing; Sun, 13 Jul 1997 17:21: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 RAA15457 for ; Sun, 13 Jul 1997 17:21:07 -0700 (PDT) Resent-From: rhh@ct.picker.com Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 20:20:36 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA28969; Sun, 13 Jul 97 20:20:35 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id UAA06065; Sun, 13 Jul 1997 20:18:35 -0400 Resent-Message-Id: <199707140018.UAA06065@elmer.ct.picker.com> Message-Id: <19970713201730.37369@ct.picker.com> Date: Sun, 13 Jul 1997 20:17:30 -0400 From: Randall Hopper To: Amancio Hasty Subject: guspnp9: Recording 16-bit yields Interrupted sys call on read() Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Resent-Date: Sun, 13 Jul 1997 20:18:35 -0400 Resent-To: multimedia@freebsd.org Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Back on guspnp7, I'd mentioned this as one of the 4 main things I had some trouble with, but didn't know it was tied to 16-bit. Figured that out working with test cases for guspnp9 this evening. OK, now I'll dig in and see if I can help you find some of these buggers. I'm no sound driver guru, but I think I might be able to figure out the record rate problem using strategically-placed printfs. :-) Thanks, Randall From owner-freebsd-multimedia Sun Jul 13 17:21:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA15501 for multimedia-outgoing; Sun, 13 Jul 1997 17:21:23 -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 RAA15490 for ; Sun, 13 Jul 1997 17:21:19 -0700 (PDT) Resent-From: rhh@ct.picker.com Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 20:20:48 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA28981; Sun, 13 Jul 97 20:20:47 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id UAA06069; Sun, 13 Jul 1997 20:18:47 -0400 Resent-Message-Id: <199707140018.UAA06069@elmer.ct.picker.com> Message-Id: <19970713201005.25369@ct.picker.com> Date: Sun, 13 Jul 1997 20:10:05 -0400 From: Randall Hopper To: Amancio Hasty Subject: guspnp9: Recording samples always 44kHz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Resent-Date: Sun, 13 Jul 1997 20:18:47 -0400 Resent-To: multimedia@freebsd.org Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The record code appears to always be recording 44kHz. My test procedure: If I record samples on guspnp9 with the formats on the left, and then figure out what format got written by playing them using the current Vox3.0 drivers, I find out they're really the formats on the right: Recorded Sample format actually written Rate Bits Channels Rate Bits Channels ------ ---- -------- ------ ---- -------- 44100 8 1 44100 8 1 44100 8 2 44100 8 2 22050 8 1 44100 8 1 22050 8 2 44100 8 2 8012 8 1 44100 8 1 8012 8 2 44100 8 2 You may ask why I didn't try 16-bit. I did, but it doesn't work at all. Probably a different bug, so let me mail that in a separate msg just so we can keep the threads/fix discussion separate. Thanks, Randall From owner-freebsd-multimedia Sun Jul 13 17:49:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA17062 for multimedia-outgoing; Sun, 13 Jul 1997 17:49:07 -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 RAA17057 for ; Sun, 13 Jul 1997 17:49:04 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 20:48:01 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA29295; Sun, 13 Jul 97 20:47:59 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id UAA06180; Sun, 13 Jul 1997 20:45:57 -0400 Message-Id: <19970713204557.61315@ct.picker.com> Date: Sun, 13 Jul 1997 20:45:57 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp9: strange dma #s in probe output Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I noticed that in the verbose probe output from the sound driver, that there are "two" DMAs being printed for the "sb" and "sbxvi" devices. They each only use one. The should be sb = 1 and sbxvi = 5. It's printing sb = 1,7; sbxvi = 5,7. Does this indicate a problem, or should I ignore it? Randall sndtable_probe(3) installing card 0 installed card 0 Driver name 'ProAudioSpectrum' probe 0xf01e3d04 Failed to find hardware pas0 not found at 0x388 sndtable_probe(2) installing card 1 installed card 1 Driver name 'SoundBlaster' probe 0xf01e6aa8 Probing sb at 0x00000220 start sb_dsp_detect, base 0x220 irq 5 start sb_reset_dsp done RESET 1 done tenmicrosec done RESET 0 Hardware probed OK sb0 at 0x220 irq 5 drq 1 flags 0xffffffff on isa sndtable_init_card(2) entered Located card - calling attach routine start sb_dsp_detect, base 0x220 irq 5 start sb_reset_dsp done RESET 1 done tenmicrosec done RESET 0 SoundBlaster 16 4.13> at 0x220 irq 5 dma 1,7 attach routine finished sndtable_probe(6) installing card 2 installed card 2 Driver name 'SoundBlaster16' probe 0xf01e8fa8 start sb_reset_dsp done RESET 1 done tenmicrosec done RESET 0 Hardware probed OK sbxvi0 at 0x0 drq 5 flags 0xffffffff on isa sndtable_init_card(6) entered Located card - calling attach routine SoundBlaster 16 4.13> at 0x000 irq -1 dma 5,7 attach routine finished sndtable_probe(7) installing card 3 installed card 3 Driver name 'SB16 MIDI' probe 0xf01e942c Hardware probed OK sbmidi0 at 0x330 on isa sndtable_init_card(7) entered Located card - calling attach routine SoundBlaster MPU-401> at 0x330 irq -1 attach routine finished sndtable_probe(1) installing card 4 installed card 4 Driver name 'OPL-2/OPL-3 FM' probe 0xf01e1fc4 Hardware probed OK opl0 at 0x388 on isa sndtable_init_card(1) entered Located card - calling attach routine Yamaha OPL3 FM> at 0x388 attach routine finished From owner-freebsd-multimedia Sun Jul 13 18:19:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA18712 for multimedia-outgoing; Sun, 13 Jul 1997 18:19:44 -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 SAA18707 for ; Sun, 13 Jul 1997 18:19:40 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 21:18:37 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA29654; Sun, 13 Jul 97 21:18:35 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id VAA06367; Sun, 13 Jul 1997 21:16:36 -0400 Message-Id: <19970713211635.31507@ct.picker.com> Date: Sun, 13 Jul 1997 21:16:35 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! & Recording always 44kHz References: <19970713170346.27065@ct.picker.com> <199707132155.OAA00289@rah.star-gate.com> <19970713184427.05917@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970713184427.05917@ct.picker.com>; from Randall Hopper on Sun, Jul 13, 1997 at 06:44:27PM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Here's the patch to fix both the: - Warp speed /dev/audio! - Recording samples always 44kHz bugs I reported earlier. The RANGE macro was a little dain bramaged :-) Randall --- ORIG/sound_config.h Fri Jul 11 10:56:33 1997 +++ sound_config.h Sun Jul 13 21:13:11 1997 @@ -32,7 +32,7 @@ * many variables should be reduced to a range. Here define a macro */ -#define RANGE(var, low, high) if (var<(low)) var=low; else var=high ; +#define RANGE(var, low, high) ((var)<(low)?(low) : (var)>(high)?(high) : (var)) #undef CONFIGURE_SOUNDCARD #undef DYNAMIC_BUFFER From owner-freebsd-multimedia Sun Jul 13 18:36:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA19602 for multimedia-outgoing; Sun, 13 Jul 1997 18:36:19 -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 SAA19589 for ; Sun, 13 Jul 1997 18:36: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 SAA00270; Sun, 13 Jul 1997 18:36:05 -0700 (PDT) Message-Id: <199707140136.SAA00270@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! & Recording always 44kHz In-reply-to: Your message of "Sun, 13 Jul 1997 21:16:35 EDT." <19970713211635.31507@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 18:36:04 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tnks I just added a ";" and it seems to work over here with my gus. Two more bugs left: 1. "A related problem I am seeing though is that about 20% of the time, Ctrl-Cing a /dev/dsp play app causes the sound driver to block inside of close(). It doesn't hang the machine (thank goodness), just the app." This is a dmabuf bug and I am trying to track it down right now. 2. "< long attach_awe_obsolete(long mem_start, struct address_info *hw_config); > void attach_awe_obsolete(struct address_info *hw_config);" That is to sort out long vs. void for attach routines. Personally, I think the return type should be "long" but lets see what Luigi had in mind. Cheers, Amancio >From The Desk Of Randall Hopper : > Here's the patch to fix both the: > > - Warp speed /dev/audio! > - Recording samples always 44kHz > > bugs I reported earlier. The RANGE macro was a little dain bramaged :-) > > Randall > > > --- ORIG/sound_config.h Fri Jul 11 10:56:33 1997 > +++ sound_config.h Sun Jul 13 21:13:11 1997 > @@ -32,7 +32,7 @@ > * many variables should be reduced to a range. Here define a macro > */ > > -#define RANGE(var, low, high) if (var<(low)) var=low; else var=high ; > +#define RANGE(var, low, high) ((var)<(low)?(low) : (var)>(high)?(high) : (va r)) > > #undef CONFIGURE_SOUNDCARD > #undef DYNAMIC_BUFFER > From owner-freebsd-multimedia Sun Jul 13 18:44:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA19973 for multimedia-outgoing; Sun, 13 Jul 1997 18:44:25 -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 SAA19964 for ; Sun, 13 Jul 1997 18:44:17 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 21:42:28 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA29914; Sun, 13 Jul 97 21:42:27 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id VAA06405; Sun, 13 Jul 1997 21:40:21 -0400 Message-Id: <19970713214020.28548@ct.picker.com> Date: Sun, 13 Jul 1997 21:40:20 -0400 From: Randall Hopper To: Alan Batie Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: onboard sound problem References: <19970710220458.09697@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Alan Batie on Fri, Jul 11, 1997 at 10:08:29AM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I've never used rat (maybe an MBONE expert will chime in with some help here), but the ktrace output here looks mighty fishy. First, it's opening /dev/audio (8KHz ULAW device). Then it tries to change the sample rate...Hmmmmmmm. Looks like it should have opened /dev/dsp if that's what it wanted to do. That fails of course. Then it looks like it goes off into LaLa land sending an ioctl and close to fd -1, following up that act by trying to reopen /dev/audio. Sorry, only one device at a time there. Appears rat might not be configured right and could use some fixes to handle incorrect configuration and error handling. ...that's just my best guess never having run rat before. BTW, your device files have the same major and minor as mine, so that looks OK. Hope this helps. Randall Alan Batie: |Now (and it was doing it before, but I wanted the audio to be working in |general before reporting it), rat repeatedly reports "audio busy" when I |start it up. It's 3.0.22, the pre-compiled binary from the Multimedia |Conferencing Applications Archive at http://ugwww.ucs.ed.ac.uk/mice/archive/ | | 301 rat CALL open(0x10130,0x4,0xffffffff) | 301 rat NAMI "/dev/audio" | 301 rat RET open 7 | 301 rat CALL ioctl(0x7,0x20005016 ,0) | 301 rat RET ioctl -1 errno 22 Invalid argument | 301 rat CALL ioctl(0x7,0xc004500a ,0xefbf976c) | 301 rat RET ioctl 0 | 301 rat CALL ioctl(0x7,0xc0045005 ,0xefbf9768) | 301 rat RET ioctl 0 | 301 rat CALL fstat(0x1,0xefbf93fc) | 301 rat RET fstat 0 | 301 rat CALL ioctl(0x1,TIOCGETA,0xefbf9438) | 301 rat RET ioctl 0 | 301 rat CALL write(0x1,0x19c000,0x2c) | 301 rat GIO fd 1 wrote 44 bytes | "Device doesn't support 16bit linear format! | " | 301 rat RET write 44/0x2c | 301 rat CALL ioctl(0xffffffff,0x20005016 ,0) | 301 rat RET ioctl -1 errno 9 Bad file descriptor | 301 rat CALL close(0xffffffff) | 301 rat RET close -1 errno 9 Bad file descriptor | 301 rat CALL open(0x10130,0x5,0x12a000) | 301 rat NAMI "/dev/audio" | 301 rat RET open -1 errno 16 Device busy | 301 rat CALL writev(0x2,0xefbf9730,0x4) | 301 rat GIO fd 2 wrote 24 bytes | "audio_open: Device busy | " | 301 rat RET writev 24/0x18 | 301 rat CALL close(0xffffffff) | 301 rat RET close -1 errno 9 Bad file descriptor | |lrwxrwxrwx 1 root wheel 6 Jul 10 13:44 /dev/audio@ -> audio0 |crw-rw-rw- 1 root wheel 30, 4 Jul 10 13:44 /dev/audio0 |lrwxrwxrwx 1 root wheel 4 Jul 10 13:44 /dev/dsp@ -> dsp0 |crw-rw-rw- 1 root wheel 30, 3 Jul 11 09:58 /dev/dsp0 From owner-freebsd-multimedia Sun Jul 13 18:50:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20477 for multimedia-outgoing; Sun, 13 Jul 1997 18:50:46 -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 SAA20453 for ; Sun, 13 Jul 1997 18:50:41 -0700 (PDT) Received: (from n9ogk@juno.com) by x14.boston.juno.com (queuemail) id V~W18814; Sun, 13 Jul 1997 21:48:20 EDT To: freebsd-multimedia@freebsd.org Date: Sun, 13 Jul 1997 20:37:40 -0500 Subject: Re: Photo manipulation SW Message-ID: <19970713.203741.3462.0.N9OGK@juno.com> References: <199707122326.QAA01560@rah.star-gate.com> <19970713.062904.11966.0.N9OGK@juno.com> X-Mailer: Juno 1.38 X-Juno-Line-Breaks: 4-8 From: n9ogk@juno.com (Jack W Doyle) Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, I'd like to pick it up, but all I have is text-only email. No internet access, but if there _is_ a way to send to a site via email and have it uue the file and divide the uue'd file into floppy-disk size chunks so I can move it from the Lose95 side to FreeBSD side and reassemble the chunks, then great -- I would really appreciate this. Jack The faster your computer is, the slower your life becomes. From owner-freebsd-multimedia Sun Jul 13 18:57:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20891 for multimedia-outgoing; Sun, 13 Jul 1997 18:57:30 -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 SAA20886 for ; Sun, 13 Jul 1997 18:57:26 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Sun, 13 Jul 1997 21:56:23 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA00211; Sun, 13 Jul 97 21:56:21 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id VAA06422; Sun, 13 Jul 1997 21:54:23 -0400 Message-Id: <19970713215422.44611@ct.picker.com> Date: Sun, 13 Jul 1997 21:54:22 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: Warp speed /dev/audio! & Recording always 44kHz References: <19970713211635.31507@ct.picker.com> <199707140136.SAA00270@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707140136.SAA00270@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 06:36:04PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |Tnks I just added a ";" and it seems to work over here with my gus. Oops, I goofed. When you said ";" I knew it. I'm used to defining RANGE as an expression not a statement, so the last patch makes RANGE() a no-op for how the driver's using it. Here's the real patch. BTW, all 24 refs of RANGE() except one (in gus_wave.c) have their own ; after RANGE(). For consistency, might want to add the ; there and whack it from the macro. Randall --- ORIG/sound_config.h Fri Jul 11 10:56:33 1997 +++ sound_config.h Sun Jul 13 21:46:02 1997 @@ -32,7 +32,8 @@ * many variables should be reduced to a range. Here define a macro */ -#define RANGE(var, low, high) if (var<(low)) var=low; else var=high ; +#define RANGE(var, low, high) (var) = \ + ((var)<(low)?(low) : (var)>(high)?(high) : (var)); #undef CONFIGURE_SOUNDCARD #undef DYNAMIC_BUFFER From owner-freebsd-multimedia Sun Jul 13 19:14:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA21984 for multimedia-outgoing; Sun, 13 Jul 1997 19:14:35 -0700 (PDT) Received: from elch.heim4.tu-clausthal.de (100@elch.heim4.tu-clausthal.de [139.174.244.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA21979 for ; Sun, 13 Jul 1997 19:14:32 -0700 (PDT) Received: (from olli@localhost) by elch.heim4.tu-clausthal.de (8.8.5/8.8.5) id EAA16083 for multimedia@FreeBSD.ORG; Mon, 14 Jul 1997 04:14:29 +0200 (MET DST) Message-Id: <199707140214.EAA16083@elch.heim4.tu-clausthal.de> Subject: Re: guspnp9: /dev/dsp close() hangs To: multimedia@FreeBSD.ORG Date: Mon, 14 Jul 1997 04:14:29 +0200 (MET DST) In-Reply-To: <19970713191453.21533@ct.picker.com> from "Randall Hopper" at Jul 13, 97 07:14:53 pm From: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Maybe this information could be useful in some way... Randall Hopper wrote: > [...] > > mpg123 things.mp2 > > -----> APP STARTUP PRINTS: > start sb_reset_dsp > done RESET 1 > done tenmicrosec > done RESET 0 > isa_dmastart: channel 5 busy > > -----> THEN WHEN I CTRL-C, I ALWAYS SEE THIS: > dmabuf 2 > dmabuf 1 > > -----> IF THE /dev/dsp close() DIDN'T HANG, THAT'S IT. > > -----> BUT IF THE close() HUNG, I SEE THIS LINE AGAIN AND AGAIN, PRINTING > -----> ONCE EVERY 10 SECONDS: > dmabuf 1 Using the soundrivers of 2.2.2 (Vox 2.9, I think) with an AWE32, I also experience hangs sometimes when /dev/dsp is closed, BUT only for about 10 seconds. It never blocks forever (maybe it checks for a timeout). To be honest, I first suspected a bug in mpg123, but I've looked at the respective parts of the code for days, and I haven't been able to spot a bug... Regards Oliver PS: I just released mpg123 0.59k, see http://mpg.123.org/ Doesn't fix the block-on-close problem though, of course. PPS: In case you didn't notice, I'm not that much familiar with all that sound driver stuff. I assume it's not possible to install those newer "guspnp" drivers in 2.2.2, is it? Stability is an absolute requirement for me, so I don't want to install 3.0-current. -- Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Sun Jul 13 19:32:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22847 for multimedia-outgoing; Sun, 13 Jul 1997 19:32:20 -0700 (PDT) Received: from elch.heim4.tu-clausthal.de (100@elch.heim4.tu-clausthal.de [139.174.244.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA22842 for ; Sun, 13 Jul 1997 19:32:17 -0700 (PDT) Received: (from olli@localhost) by elch.heim4.tu-clausthal.de (8.8.5/8.8.5) id EAA16122 for multimedia@FreeBSD.ORG; Mon, 14 Jul 1997 04:32:15 +0200 (MET DST) Message-Id: <199707140232.EAA16122@elch.heim4.tu-clausthal.de> Subject: Re: guspnp9: /dev/dsp close() hangs To: multimedia@FreeBSD.ORG Date: Mon, 14 Jul 1997 04:32:14 +0200 (MET DST) In-Reply-To: from "Oliver Fromme" at Jul 14, 97 04:14:29 am From: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I wrote: > [...] > Using the soundrivers of 2.2.2 (Vox 2.9, I think) with an > AWE32, I also experience hangs sometimes when /dev/dsp is > closed, BUT only for about 10 seconds. It never blocks > forever (maybe it checks for a timeout). Sorry, but I forgot to add that it does NOT only happen when Ctrl-Cing the app, but also sometimes on close() at the regular end of the app. So the problem seems not to be related to the Ctrl-C. Regards Oliver -- Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Sun Jul 13 20:10:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA24312 for multimedia-outgoing; Sun, 13 Jul 1997 20:10:46 -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 UAA24307 for ; Sun, 13 Jul 1997 20:10:43 -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 UAA00830; Sun, 13 Jul 1997 20:10:36 -0700 (PDT) Message-Id: <199707140310.UAA00830@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Mon, 14 Jul 1997 04:32:14 +0200." <199707140232.EAA16122@elch.heim4.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 20:10:35 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, That helps a lot! The problem area is probably isolated to : dmabuf_outputintr. I asked Randall to place a printf in dmabuf.c:dma_sync: while (!(out_sleep_flag[dev].aborting) && audio_devs[dev]->dmap_out->qlen) { int flag, chn; printf("dmasync %d \n", audio_devs[dev]->dmap_out->qlen); ---- It seems that dma_sync gets stuck printing "1". Which means that we failed to process an output buffer. The only routine in dmabuf which decrements the qlen field for an output buffer is dmabuf_outputintr which gets called from sbxx_dsp.c : DMAbuf_outputintr(my_dev, 1); So one condition is not letting us decrement qlen or we didn't initiate properly the output buffer . For instance, incremented qlen however failed to start the actual output buffer. Tnks, Amancio >From The Desk Of Oliver Fromme : > > I wrote: > > [...] > > Using the soundrivers of 2.2.2 (Vox 2.9, I think) with an > > AWE32, I also experience hangs sometimes when /dev/dsp is > > closed, BUT only for about 10 seconds. It never blocks > > forever (maybe it checks for a timeout). > > Sorry, but I forgot to add that it does NOT only happen when > Ctrl-Cing the app, but also sometimes on close() at the > regular end of the app. So the problem seems not to be > related to the Ctrl-C. > > Regards > Oliver > > -- > Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Sun Jul 13 21:07:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA26222 for multimedia-outgoing; Sun, 13 Jul 1997 21:07:12 -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 VAA26217 for ; Sun, 13 Jul 1997 21:07: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 VAA01095; Sun, 13 Jul 1997 21:06:53 -0700 (PDT) Message-Id: <199707140406.VAA01095@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) cc: Randall Hopper , multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Mon, 14 Jul 1997 04:14:29 +0200." <199707140214.EAA16083@elch.heim4.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 21:06:53 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi guys, In sb_dsp_close: Move down sb_free_irq to after dsp_cleanup. /* DMAbuf_close_dma (dev); */ /* sb_dsp_command (0xd4); */ dsp_cleanup(); sb_free_irq(); sb16dsp.c:sb16_dsp_close has the same problem. See if that fixes the sb cards hanging during a close. Tnks, Amancio >From The Desk Of Oliver Fromme : > > Maybe this information could be useful in some way... > > Randall Hopper wrote: > > [...] > > > mpg123 things.mp2 > > > > -----> APP STARTUP PRINTS: > > start sb_reset_dsp > > done RESET 1 > > done tenmicrosec > > done RESET 0 > > isa_dmastart: channel 5 busy > > > > -----> THEN WHEN I CTRL-C, I ALWAYS SEE THIS: > > dmabuf 2 > > dmabuf 1 > > > > -----> IF THE /dev/dsp close() DIDN'T HANG, THAT'S IT. > > > > -----> BUT IF THE close() HUNG, I SEE THIS LINE AGAIN AND AGAIN, PRI NTING > > -----> ONCE EVERY 10 SECONDS: > > dmabuf 1 > > Using the soundrivers of 2.2.2 (Vox 2.9, I think) with an > AWE32, I also experience hangs sometimes when /dev/dsp is > closed, BUT only for about 10 seconds. It never blocks > forever (maybe it checks for a timeout). > > To be honest, I first suspected a bug in mpg123, but I've > looked at the respective parts of the code for days, and > I haven't been able to spot a bug... > > Regards > Oliver > > PS: I just released mpg123 0.59k, see http://mpg.123.org/ > Doesn't fix the block-on-close problem though, of course. > > PPS: In case you didn't notice, I'm not that much familiar > with all that sound driver stuff. I assume it's not possible > to install those newer "guspnp" drivers in 2.2.2, is it? > Stability is an absolute requirement for me, so I don't want > to install 3.0-current. > > -- > Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Sun Jul 13 21:22:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA27022 for multimedia-outgoing; Sun, 13 Jul 1997 21:22:38 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.186.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA27017 for ; Sun, 13 Jul 1997 21:22:31 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id VAA03842; Sun, 13 Jul 1997 21:22:27 -0700 (PDT) Date: Sun, 13 Jul 1997 21:22:27 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: little green men In-Reply-To: <199707131853.LAA01669@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 Sun, 13 Jul 1997, Amancio Hasty wrote: > Is this with rah's bt848 driver ? Oh, I yanked only the grabber-meteor out of that since the rest of the package is dated May 24 and I'm using Randall's June 4-dated modified driver. I'll try rebuilding with the rah pack. Would it be possible to merge in the rapidly diverging drivers into -current? I have access to cvsup'd cvs tree and I'd like to use that as a reference. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major Spam routed to /dev/null by Procmail | Death to Cyberpromo From owner-freebsd-multimedia Sun Jul 13 22:08:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA29481 for multimedia-outgoing; Sun, 13 Jul 1997 22:08:16 -0700 (PDT) Received: from gdi.uoregon.edu (gdi.uoregon.edu [128.223.186.38]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA29476 for ; Sun, 13 Jul 1997 22:08:11 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id WAA00377; Sun, 13 Jul 1997 22:08:02 -0700 (PDT) Date: Sun, 13 Jul 1997 22:08:02 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: little green men 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 On Sun, 13 Jul 1997, Doug White wrote: > > Is this with rah's bt848 driver ? A followup: I recompiled the kernel with the rah pack and all is good. :) Thanks for the pointer Amancio. > Would it be possible to merge in the rapidly diverging drivers into > -current? I have access to cvsup'd cvs tree and I'd like to use that as a > reference. Doug White | University of Oregon Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant http://gladstone.uoregon.edu/~dwhite | Computer Science Major Spam routed to /dev/null by Procmail | Death to Cyberpromo From owner-freebsd-multimedia Sun Jul 13 22:10:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA29593 for multimedia-outgoing; Sun, 13 Jul 1997 22:10:36 -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 WAA29588 for ; Sun, 13 Jul 1997 22:10:32 -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 WAA01432; Sun, 13 Jul 1997 22:10:22 -0700 (PDT) Message-Id: <199707140510.WAA01432@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Doug White cc: multimedia@FreeBSD.ORG Subject: Re: little green men In-reply-to: Your message of "Sun, 13 Jul 1997 22:08:02 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 13 Jul 1997 22:10:22 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think I will commit that driver later on this week. The hold up has been setting properly the video capture frame rate. Regards, Amancio >From The Desk Of Doug White : > On Sun, 13 Jul 1997, Doug White wrote: > > > > Is this with rah's bt848 driver ? > > A followup: I recompiled the kernel with the rah pack and all is good. :) > Thanks for the pointer Amancio. > > > Would it be possible to merge in the rapidly diverging drivers into > > -current? I have access to cvsup'd cvs tree and I'd like to use that as a > > reference. > > Doug White | University of Oregon > Internet: dwhite@resnet.uoregon.edu | Residence Networking Assistant > http://gladstone.uoregon.edu/~dwhite | Computer Science Major > Spam routed to /dev/null by Procmail | Death to Cyberpromo > From owner-freebsd-multimedia Mon Jul 14 00:03:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA04716 for multimedia-outgoing; Mon, 14 Jul 1997 00:03:25 -0700 (PDT) Received: from elch.heim4.tu-clausthal.de (100@elch.heim4.tu-clausthal.de [139.174.244.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA04705 for ; Mon, 14 Jul 1997 00:03:20 -0700 (PDT) Received: (from olli@localhost) by elch.heim4.tu-clausthal.de (8.8.5/8.8.5) id JAA18049; Mon, 14 Jul 1997 09:03:13 +0200 (MET DST) Message-Id: <199707140703.JAA18049@elch.heim4.tu-clausthal.de> Subject: Re: guspnp9: /dev/dsp close() hangs To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 14 Jul 1997 09:03:12 +0200 (MET DST) Cc: multimedia@freebsd.org In-Reply-To: <199707140406.VAA01095@rah.star-gate.com> from "Amancio Hasty" at Jul 13, 97 09:06:53 pm From: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty wrote: > In sb_dsp_close: > Move down sb_free_irq to after dsp_cleanup. > > /* DMAbuf_close_dma (dev); */ > /* sb_dsp_command (0xd4); */ > dsp_cleanup(); > sb_free_irq(); Am I also supposed to comment out the DMAbuf_close_dma? I just moved sb_free_irq down, as you suggested, in both sb_dsp.c and sb16_dsp.c. The latter now looks like this (remember, this is FreeBSD 2.2.2): sb_dsp_command01 (0xd9); sb_dsp_command01 (0xd5); DISABLE_INTR (flags); RELEASE_DMA_CHN (dma8); if (dma16 != dma8) RELEASE_DMA_CHN (dma16); dsp_cleanup (); sb_free_irq (); dsp_busy = 0; RESTORE_INTR (flags); It doesn't seem to fix the problem. I spent the past 2 hours testing: On about 20% of all 44 kHz files, the 10 seconds block occurs at the close, and on about 4% of all 22 kHz files (all of that 16 bit stereo, on my AWE32). The follwoing shell script can be used for testing: ================== cut here ================== #!/bin/sh - if [ $# -ne 2 ]; then echo "Usage: `basename $0` " >&2 echo " = number of attempts" >&2 echo " = mpeg file to play" >&2 exit 1 fi ATTEMPT=$1 BLOCKS=0 while [ $ATTEMPT -gt 0 ]; do /usr/bin/printf "\rAttempts left: $ATTEMPT (of $1) " mpg123 -q "$2" & PID=$! sleep 2 kill -INT $PID sleep 1 if [ `ps -p $PID | wc -l` -gt 1 ]; then sleep 5 if [ `ps -p $PID | wc -l` -gt 1 ]; then echo "*** blocks." kill -INT $PID sleep 1 if [ `ps -p $PID | wc -l` -gt 1 ]; then kill -KILL $PID fi BLOCKS=`expr $BLOCKS + 1` fi fi ATTEMPT=`expr $ATTEMPT - 1` done /usr/bin/printf "\rBlocked $BLOCKS times (out of $1 attempts). \n" ================== cut here ================== I'd recommend that you turn the volume on your stereo down, unless you'd like to hear the first 2 seconds of your mpeg files 200 times. ;-) One side note: When I change the first "sleep 2" to "sleep 1", 22 kHz files _never_ block, while the behaviour for 44 kHz remains unchanged. Increasing the sleep value above 2 doesn't seem to change anything. And on another note, I also tried the follwoing: replaced the mpg123 with pcmplay, playing a 1 or 2 seconds raw pcm file, and removed the first kill. Same result, i.e. it's definitely not a bug in mpg123. Oliver PS: pcmplay is part of the audio/tosha FreeBSD port. -- Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Mon Jul 14 00:20:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05380 for multimedia-outgoing; Mon, 14 Jul 1997 00:20:43 -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 AAA05355 for ; Mon, 14 Jul 1997 00:20:26 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA10040; Mon, 14 Jul 1997 08:14:04 +0200 From: Luigi Rizzo Message-Id: <199707140614.IAA10040@labinfo.iet.unipi.it> Subject: Re: guspnp9 feedback To: rhh@ct.picker.com (Randall Hopper) Date: Mon, 14 Jul 1997 08:14:04 +0200 (MET DST) Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG In-Reply-To: <19970713163210.43120@ct.picker.com> from "Randall Hopper" at Jul 13, 97 04:31:51 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > As I said, it's not just the return type. > > < long attach_awe_obsolete(long mem_start, struct address_info *hw_config); > > void attach_awe_obsolete(struct address_info *hw_config); I have removed mem_start since the parameter was useless (just passed across functions) in all drivers I had seen, and only served to clutter the code. I did not touch the awe driver since I wanted to talk to Randall first (and did not expect so much activity during this weekend, which I have spent on the beach playing with my son instead :) The intent is to remove mem_start from all attach routines. All relevent info can be supplied through hw_config if needed (perhaps we need to add some field to the structure, but the interface would not change). The return type of the attach routine has been set (temporarily ?) to void since in the drivers I had seen attach() could never fail, nor it was generally tested for failute. I do not think it is a particularly good idea to have attach() return void, but since there was no error checking anyways, I did it as a first cut. In the probe/attach sequence I notice that some drivers do call the probe() routine again in the attach(). This seems pointless since there should be no attach if the previous probe failed. Also, the probe code can probably benefit from the addition of proper support for PnP boards, since these boards identify clearly themselves in the PnP id and do not require black magic in the probe routine. 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 Mon Jul 14 00:54:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA06626 for multimedia-outgoing; Mon, 14 Jul 1997 00:54:26 -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 AAA06430; Mon, 14 Jul 1997 00:49:49 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA10143; Mon, 14 Jul 1997 08:44:35 +0200 From: Luigi Rizzo Message-Id: <199707140644.IAA10143@labinfo.iet.unipi.it> Subject: snd driver attach routine To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 14 Jul 1997 08:44:35 +0200 (MET DST) Cc: rhh@ct.picker.com, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707140136.SAA00270@rah.star-gate.com> from "Amancio Hasty" at Jul 13, 97 06:35:45 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk [I am Cc'ing this to hackers since there someone might have some useful suggestion] Problem: what should be the return type of *attach() routines ? > 2. "< long attach_awe_obsolete(long mem_start, struct address_info *hw_config); > > void attach_awe_obsolete(struct address_info *hw_config);" > > That is to sort out long vs. void for attach routines. Personally, > I think the return type should be "long" but lets see > what Luigi had in mind. I have checked /sys/i386/isa/isa.c -- while the attach routine has return type "int", it is not tested for failure, which means that it better not fail :) . Note that there is no consistency at all about this in the various driver. Many (including sio.c and others that I wrote, e.g. asc.c) can fail in the attach routine, but this might mean nothing, just that I copied from a bad example (and in the case of sio.c, the attach routine is also called from another part of the driver). The drivers in /sys/pci all return void for the attach routine. So I'd go for the following: - make "void" the return type of all soundcard attach routines; - move all actions which might fail (e.g. allocate memory ?) to the probe routine; - do not invoke the probe routine again during the attach. Does this sound (er... look ?:) reasonable ? Should we also fix the existing isa drivers accordingly, if possible ? 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 Mon Jul 14 01:11:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA07341 for multimedia-outgoing; Mon, 14 Jul 1997 01:11:55 -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 BAA07291 for ; Mon, 14 Jul 1997 01:11:08 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA10172; Mon, 14 Jul 1997 08:57:48 +0200 From: Luigi Rizzo Message-Id: <199707140657.IAA10172@labinfo.iet.unipi.it> Subject: Re: guspnp9: strange dma #s in probe output To: rhh@ct.picker.com (Randall Hopper) Date: Mon, 14 Jul 1997 08:57:48 +0200 (MET DST) Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG In-Reply-To: <19970713204557.61315@ct.picker.com> from "Randall Hopper" at Jul 13, 97 08:45:38 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I noticed that in the verbose probe output from the sound driver, that > there are "two" DMAs being printed for the "sb" and "sbxvi" devices. They > each only use one. > > The should be sb = 1 and sbxvi = 5. It's printing sb = 1,7; sbxvi = 5,7. > > Does this indicate a problem, or should I ignore it? I think I know where the problem is. The "flags" field is misused to hold the secondary dma channel, but originally 0 meant no secondary dma. Now it appears that some PnP cards that I have default to use DMA 0 as the secondary DMA, so I had to patch the code in order to make this possible. The solution I used was to use the low three bits as dma address, and an additional bit to flag that the secondary dma address was used. Because of this masking, the "-1" which is the internal representation of "no secondary dma" has become 7. This might or might not cause problems later, so better check it. Thanks for pointing this out. 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 Mon Jul 14 01:55:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA09089 for multimedia-outgoing; Mon, 14 Jul 1997 01:55:21 -0700 (PDT) Received: from elch.heim4.tu-clausthal.de (100@elch.heim4.tu-clausthal.de [139.174.244.250]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA09081 for ; Mon, 14 Jul 1997 01:55:16 -0700 (PDT) Received: (from olli@localhost) by elch.heim4.tu-clausthal.de (8.8.5/8.8.5) id KAA18846; Mon, 14 Jul 1997 10:55:04 +0200 (MET DST) Message-Id: <199707140855.KAA18846@elch.heim4.tu-clausthal.de> Subject: Re: Photo manipulation SW To: n9ogk@juno.com (Jack W Doyle) Date: Mon, 14 Jul 1997 10:55:03 +0200 (MET DST) Cc: multimedia@freebsd.org In-Reply-To: <19970713.203741.3462.0.N9OGK@juno.com> from "Jack W Doyle" at Jul 13, 97 08:37:40 pm From: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) X-Mailer: ELM [version 2.4 PL24 PGP6] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk n9ogk@juno.com (Jack W Doyle) wrote: > Well, I'd like to pick it up, but all I have is text-only email. No > internet access, but if there _is_ a way to send to a site via email and > have it uue the file and divide the uue'd file into floppy-disk size > chunks so I can move it from the Lose95 side to FreeBSD side and > reassemble the chunks, then great -- I would really appreciate this. You can use "ftpmail". I don't know whether cdrom.com provides a service like this, but you can also use the ftpmailer at dec.com. To receive the files for gimp, just send email to ftpmail@decwrl.dec.com with the following lines in the message body: reply n9ogk@juno.com connect ftp.freebsd.org binary uuencode chunksize 100000 chdir /pub/FreeBSD get distfiles/gimp-0.99.9.tar.gz get distfiles/gimp-data-0.99.9.tar.gz get ports-current/graphics/gimp-devel.tar quit It will then mail you the requested files in chunks of 100 Kb each. Unfortunately 100 Kb is the maximum chunk size. If you prefer precompiled binaries for 3.0-current, tell it to get packages-current/All/gimp-0.99.9.tgz instead. To receive more information about the ftpmailer, just send the word "help" in the message body. Hope this helps. Regards Oliver -- Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Mon Jul 14 03:29:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA12508 for multimedia-outgoing; Mon, 14 Jul 1997 03:29: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 DAA12501 for ; Mon, 14 Jul 1997 03:29:53 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 14 Jul 1997 6:28:15 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA07621; Mon, 14 Jul 97 06:28:14 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id GAA06618; Mon, 14 Jul 1997 06:26:02 -0400 Message-Id: <19970714062602.02401@ct.picker.com> Date: Mon, 14 Jul 1997 06:26:02 -0400 From: Randall Hopper To: Luigi Rizzo Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback References: <19970713163210.43120@ct.picker.com> <199707140614.IAA10040@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707140614.IAA10040@labinfo.iet.unipi.it>; from Luigi Rizzo on Mon, Jul 14, 1997 at 08:14:04AM +0200 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo: |> As I said, it's not just the return type. |> |> < long attach_awe_obsolete(long mem_start, struct address_info *hw_config); |> > void attach_awe_obsolete(struct address_info *hw_config); | |I have removed mem_start since the parameter was useless (just passed |across functions) in all drivers I had seen, and only served to |clutter the code. ... |not change). The return type of the attach routine has been set |(temporarily ?) to void since in the drivers I had seen attach() |could never fail, nor it was generally tested for failute. Thanks for the info Luigi. Ok, well the awe driver mallocs kernel mem in the attach. If the malloc fails, it returns 0. Since attach() calls can fail, it might be good to leave the non-void return type in there, and we can beef up the error checking of attach() invocations as we notice unchecked invocations. |Also, the probe code can probably benefit from the addition of proper |support for PnP boards, since these boards identify clearly themselves |in the PnP id and do not require black magic in the probe routine. Good point. There's some PnP detection code for the SB32/AWE32 cards in newer versions of the Linux AWE driver, but later versions are GPLed. So I guess this would have to be reengineered (?). If I had a PnP card, I'd take a stab (I've avoided these for obvious reasons). Randall From owner-freebsd-multimedia Mon Jul 14 03:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA12986 for multimedia-outgoing; Mon, 14 Jul 1997 03:40:29 -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 DAA12975 for ; Mon, 14 Jul 1997 03:40:23 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA10468 for multimedia@freebsd.org; Mon, 14 Jul 1997 11:35:42 +0200 From: Luigi Rizzo Message-Id: <199707140935.LAA10468@labinfo.iet.unipi.it> Subject: guspnp9 - sb recording bug To: multimedia@freebsd.org Date: Mon, 14 Jul 1997 11:35:41 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > It is hard for me to read the differences between guspnp7 and guspnp9 given > that guspnp9 was run thru indent. Typically , this should be done > after all the changes have gone in and the driver was tested. I had no choice, my mind refuses to work on ugly-looking code :) In any case, one solution is to run the old code through indent and then try a "diff". If someone has problems recording with the sb (perhaps in 16-bit mode) note that in snd970711 (and then in guspnp9 ?) there was a typo in sb_dsp.c. In sb_dsp_start_input(), around line 404, you should apply the following fix if (sb_dsp_command(DSP_CMD_HSSIZE)) { /* High speed size */ sb_dsp_command((u_char) (dsp_count & 0xff)); sb_dsp_command((u_char) ((dsp_count >> 8) & 0xff)); - sb_dsp_command(DSP_CMD_HSDAC); /* High speed 8 bit ADC */ + sb_dsp_command(DSP_CMD_HSADC); /* High speed 8 bit ADC */ } else printf("SB Error: Unable to start (high speed) ADC\n"); splx(flags); } else { The correct definition in file sb_card.h should be: #define DSP_CMD_HSDAC 0x91 /* high speed dac */ #define DSP_CMD_HSADC 0x99 /* high speed adc */ Boy, I hope that's all by now. Thanks everybody for all the testing and feedback you have provided. 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 Mon Jul 14 03:52:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA13435 for multimedia-outgoing; Mon, 14 Jul 1997 03:52:06 -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 DAA13370 for ; Mon, 14 Jul 1997 03:51:38 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA10489; Mon, 14 Jul 1997 11:44:29 +0200 From: Luigi Rizzo Message-Id: <199707140944.LAA10489@labinfo.iet.unipi.it> Subject: Re: guspnp9 feedback To: rhh@ct.picker.com (Randall Hopper) Date: Mon, 14 Jul 1997 11:44:29 +0200 (MET DST) In-Reply-To: <19970714062602.02401@ct.picker.com> from "Randall Hopper" at Jul 14, 97 06:25:43 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Ok, well the awe driver mallocs kernel mem in the attach. If the malloc > fails, it returns 0. Since attach() calls can fail, it might be good to > leave the non-void return type in there, and we can beef up the error > checking of attach() invocations as we notice unchecked invocations. see one of my followup messages (also to hackers) on the failure handling in attach routines. I will have to read the bible (the daemon books on 4.3 and 4.4) to see what is the best way, but it currently seems easier to put all things which might fail into the probe routine. > |Also, the probe code can probably benefit from the addition of proper > |support for PnP boards, since these boards identify clearly themselves > |in the PnP id and do not require black magic in the probe routine. > > Good point. There's some PnP detection code for the SB32/AWE32 cards in > newer versions of the Linux AWE driver, but later versions are GPLed. So I > guess this would have to be reengineered (?). If I had a PnP card, I'd the sound_pnp.c file has some pnp code inside. Perhaps even the gus files. Finally, I have a (locally patched) copy of the pnp code from S.Patel which can be used to this purpose. So we do not really need to rewrite any low-level pnp stuff, just integrate pieces. With sound cards, I still have a conceptual problem, since one card can have multiple etherogeneous "devices" (e.g. audio, midi, synthesis) at different addresses. I will have to look more carefully at the pci code to see if/how it can deal with multifunction devices, and then will duplicate their approach for PnP. One more problem is that many of the sound files do not support multiple instances of one device, they use static variables for each device type. Cheers Luigi From owner-freebsd-multimedia Mon Jul 14 03:52:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA13464 for multimedia-outgoing; Mon, 14 Jul 1997 03:52:46 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA13457; Mon, 14 Jul 1997 03:52:41 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id UAA02952; Mon, 14 Jul 1997 20:46:14 +1000 Date: Mon, 14 Jul 1997 20:46:14 +1000 From: Bruce Evans Message-Id: <199707141046.UAA02952@godzilla.zeta.org.au> To: hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it Subject: Re: snd driver attach routine Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, rhh@ct.picker.com Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >Problem: what should be the return type of *attach() routines ? Perhaps it should be void to match reality, but it currently must be int for isa drivers to match the prototype in `struct isa_driver'. >The drivers in /sys/pci all return void for the attach routine. They have to, to match the prototype in `strcuct pci_driver'. >- move all actions which might fail (e.g. allocate memory ?) to the > probe routine; Impossible, e.g. since probe routines shouldn't allocate memory. Bruce From owner-freebsd-multimedia Mon Jul 14 05:14:34 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA16948 for multimedia-outgoing; Mon, 14 Jul 1997 05:14:34 -0700 (PDT) Received: from wugate.wustl.edu (wugate.wustl.edu [128.252.120.1]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA16941 for ; Mon, 14 Jul 1997 05:14:29 -0700 (PDT) Received: from stereotaxis.wustl.edu (stereotaxis.wustl.edu [128.252.151.57]) by wugate.wustl.edu (8.8.5/8.8.5) with SMTP id HAA05356 for ; Mon, 14 Jul 1997 07:14:28 -0500 (CDT) Received: from surgeon by stereotaxis.wustl.edu (SMI-8.6/SMI-SVR4) id HAA04651; Mon, 14 Jul 1997 07:15:50 -0500 Received: from surgeon by surgeon via SMTP (950413.SGI.8.6.12/940406.SGI.AUTO) id HAA11774; Mon, 14 Jul 1997 07:20:52 -0500 Message-ID: <33CA19A4.41C6@stereotaxis.wustl.edu> Date: Mon, 14 Jul 1997 07:20:52 -0500 From: "Michael J. Yanowitz" Organization: Stereotaxis, Inc. X-Mailer: Mozilla 3.01Gold (X11; I; IRIX 6.2 IP22) MIME-Version: 1.0 To: multimedia@freebsd.org Subject: Do you have a Linux version? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have the STB TV PCI card, and Linux. Do you have a driver for this card for Linux? If not, would you happen to know who does or might? Thanks: Michael J. Yanowitz From owner-freebsd-multimedia Mon Jul 14 08:38:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA27303 for multimedia-outgoing; Mon, 14 Jul 1997 08:38: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 IAA27295 for ; Mon, 14 Jul 1997 08:38: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 IAA04621; Mon, 14 Jul 1997 08:36:22 -0700 (PDT) Message-Id: <199707141536.IAA04621@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: Luigi Rizzo , multimedia@FreeBSD.ORG Subject: Re: guspnp9 feedback In-reply-to: Your message of "Mon, 14 Jul 1997 06:26:02 EDT." <19970714062602.02401@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 08:36:21 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We can do a malloc during the attach and if that fails invalidate the driver via some flag in the sound driver. Cheers, Amancio >From The Desk Of Randall Hopper : > Luigi Rizzo: > |> As I said, it's not just the return type. > |> > |> < long attach_awe_obsolete(long mem_start, struct address_info *hw_config ); > |> > void attach_awe_obsolete(struct address_info *hw_config); > | > |I have removed mem_start since the parameter was useless (just passed > |across functions) in all drivers I had seen, and only served to > |clutter the code. > ... > |not change). The return type of the attach routine has been set > |(temporarily ?) to void since in the drivers I had seen attach() > |could never fail, nor it was generally tested for failute. > > Thanks for the info Luigi. > > Ok, well the awe driver mallocs kernel mem in the attach. If the malloc > fails, it returns 0. Since attach() calls can fail, it might be good to > leave the non-void return type in there, and we can beef up the error > checking of attach() invocations as we notice unchecked invocations. > > |Also, the probe code can probably benefit from the addition of proper > |support for PnP boards, since these boards identify clearly themselves > |in the PnP id and do not require black magic in the probe routine. > > Good point. There's some PnP detection code for the SB32/AWE32 cards in > newer versions of the Linux AWE driver, but later versions are GPLed. So I > guess this would have to be reengineered (?). If I had a PnP card, I'd > take a stab (I've avoided these for obvious reasons). > > Randall From owner-freebsd-multimedia Mon Jul 14 08:41:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA27547 for multimedia-outgoing; Mon, 14 Jul 1997 08:41:30 -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 IAA27542 for ; Mon, 14 Jul 1997 08:41:27 -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 IAA04661; Mon, 14 Jul 1997 08:41:21 -0700 (PDT) Message-Id: <199707141541.IAA04661@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) cc: multimedia@freebsd.org Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Mon, 14 Jul 1997 09:03:12 +0200." <199707140703.JAA18049@elch.heim4.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 08:41:21 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, This is the way that the code is supposed to look like: /* DMAbuf_close_dma (dev); */ /* sb_dsp_command (0xd4); */ dsp_cleanup(); sb_free_irq(); dsp_speaker(OFF); sb_dsp_busy = 0; sb_dsp_highspeed = 0; open_mode = 0; } Now if the code still hangs it just simply mean that we are either missing an interrupt or dma_sync never finished syncing all the buffers. Amancio >From The Desk Of Oliver Fromme : > > Amancio Hasty wrote: > > In sb_dsp_close: > > Move down sb_free_irq to after dsp_cleanup. > > > > /* DMAbuf_close_dma (dev); */ > > /* sb_dsp_command (0xd4); */ > > dsp_cleanup(); > > sb_free_irq(); > > Am I also supposed to comment out the DMAbuf_close_dma? > > I just moved sb_free_irq down, as you suggested, in both > sb_dsp.c and sb16_dsp.c. The latter now looks like this > (remember, this is FreeBSD 2.2.2): > > sb_dsp_command01 (0xd9); > sb_dsp_command01 (0xd5); > > DISABLE_INTR (flags); > RELEASE_DMA_CHN (dma8); > > if (dma16 != dma8) > RELEASE_DMA_CHN (dma16); > dsp_cleanup (); > sb_free_irq (); > dsp_busy = 0; > RESTORE_INTR (flags); > > It doesn't seem to fix the problem. > I spent the past 2 hours testing: On about 20% of all > 44 kHz files, the 10 seconds block occurs at the close, > and on about 4% of all 22 kHz files (all of that 16 bit > stereo, on my AWE32). > > The follwoing shell script can be used for testing: > > ================== cut here ================== > #!/bin/sh - > if [ $# -ne 2 ]; then > echo "Usage: `basename $0` " >&2 > echo " = number of attempts" >&2 > echo " = mpeg file to play" >&2 > exit 1 > fi > ATTEMPT=$1 > BLOCKS=0 > while [ $ATTEMPT -gt 0 ]; do > /usr/bin/printf "\rAttempts left: $ATTEMPT (of $1) " > mpg123 -q "$2" & > PID=$! > sleep 2 > kill -INT $PID > sleep 1 > if [ `ps -p $PID | wc -l` -gt 1 ]; then > sleep 5 > if [ `ps -p $PID | wc -l` -gt 1 ]; then > echo "*** blocks." > kill -INT $PID > sleep 1 > if [ `ps -p $PID | wc -l` -gt 1 ]; then > kill -KILL $PID > fi > BLOCKS=`expr $BLOCKS + 1` > fi > fi > ATTEMPT=`expr $ATTEMPT - 1` > done > /usr/bin/printf "\rBlocked $BLOCKS times (out of $1 attempts). \n" > ================== cut here ================== > > I'd recommend that you turn the volume on your stereo down, > unless you'd like to hear the first 2 seconds of your mpeg > files 200 times. ;-) > > One side note: When I change the first "sleep 2" to "sleep 1", > 22 kHz files _never_ block, while the behaviour for 44 kHz > remains unchanged. Increasing the sleep value above 2 doesn't > seem to change anything. > > And on another note, I also tried the follwoing: replaced the > mpg123 with pcmplay, playing a 1 or 2 seconds raw pcm file, and > removed the first kill. Same result, i.e. it's definitely not > a bug in mpg123. > > Oliver > > PS: pcmplay is part of the audio/tosha FreeBSD port. > > -- > Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Mon Jul 14 08:47:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA27817 for multimedia-outgoing; Mon, 14 Jul 1997 08:47:48 -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 IAA27809 for ; Mon, 14 Jul 1997 08:47:40 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA10942; Mon, 14 Jul 1997 16:41:14 +0200 From: Luigi Rizzo Message-Id: <199707141441.QAA10942@labinfo.iet.unipi.it> Subject: Re: guspnp9 feedback To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 14 Jul 1997 16:41:14 +0200 (MET DST) Cc: rhh@ct.picker.com, multimedia@FreeBSD.ORG In-Reply-To: <199707141536.IAA04621@rah.star-gate.com> from "Amancio Hasty" at Jul 14, 97 08:36:02 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > We can do a malloc during the attach and if that fails invalidate the > driver via some flag in the sound driver. right, that seems the only viable alternative since malloc in the probe routines are deprecated and any feedback from the attach routines is currently ignored by the operating system. nobody has responded yet on the need of doing the probe again in the attach routine. I am going to nuke them if noone comes up with a good reason for it. Tonight I am going to distribute another set of changes to my code. I will make both a complete source and the diffs available. Hope I can get a copy of guspnp9 by then (poor connectivity right now...) 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 Mon Jul 14 11:41:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA07023 for multimedia-outgoing; Mon, 14 Jul 1997 11:41:56 -0700 (PDT) Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA07016 for ; Mon, 14 Jul 1997 11:41:54 -0700 (PDT) Received: from aahz.jf.intel.com (aahz.jf.intel.com [192.198.161.2]) by mailbag.jf.intel.com (8.8.5/8.8.4) with SMTP id LAA02216; Mon, 14 Jul 1997 11:44:11 -0700 (PDT) Received: by aahz.jf.intel.com (Smail3.1.28.1 #13) id m0wnq4E-000hy2C; Mon, 14 Jul 97 11:41 PDT Message-Id: From: batie@aahz.jf.intel.com (Alan Batie) Subject: Re: vic & 24-bit To: asami@cs.berkeley.edu (Satoshi Asami) Date: Mon, 14 Jul 1997 11:41:50 -0700 (PDT) Cc: freebsd-multimedia@freebsd.org In-Reply-To: <199707120121.SAA28263@vader.cs.berkeley.edu> from "Satoshi Asami" at Jul 11, 97 06:21:41 pm X-Mailer: ELM [version 2.4 PL24 ME8] 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 In a previous message, Satoshi Asami said: > Not sure if it is related, but the XFree86's Matrox driver is known to > have bugs in 24bpp mode. Have you tried 16bpp? Thanks, that fixed it. -- Alan Batie ------ What goes up, must come down. batie@aahz.jf.intel.com \ / Ask any system administrator. +1 503-264-8844 (voice) \ / --unknown D0 D2 39 0E 02 34 D6 B4 \/ 5A 41 21 8F 23 5F 08 9D From owner-freebsd-multimedia Mon Jul 14 12:01:20 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08014 for multimedia-outgoing; Mon, 14 Jul 1997 12:01:20 -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 MAA08007 for ; Mon, 14 Jul 1997 12:01:13 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA11361; Mon, 14 Jul 1997 19:56:05 +0200 From: Luigi Rizzo Message-Id: <199707141756.TAA11361@labinfo.iet.unipi.it> Subject: Yet another snap of the sound code... To: multimedia@freebsd.org Date: Mon, 14 Jul 1997 19:56:05 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have put another snap of my code on the sound driver. Note that I cannot test the code since I don't have a working system yet (my test machine, a Intel Zappa with a CS4232 PnP device on board, hangs as soon as I issue the reset command to the soundblaster port :) Since I cannot find the data sheets of the 4232 I am out of luck for the moment... But I have successfully built, booted and run (without using the sound drivers) a kernel with all the drivers compiled in. There is a wide choice of formats at http://www.iet.unipi.it/~luigi/ snd970714.tgz (298KB) the full sound directory gus10a-to-snd970714.diffs.gz (20KB) diffs against amancio's latest version, guspnp10a snd970711-to-snd970714.diffs.gz diffs against my previous snap, snap970711 I have merged all of amancio's patches found in guspnp9 and guspnp10a (including replacement of ulaw.h with his newer version). The new snap contains the following: - some notes on the structure of the driver (see README.LUIGI); - a first attempt at removing all the CONFIGURE_SOUNDCARD, CONFIG_XXX macros. Whenever I could understand that it worked, I tested NSND, NSB, NGUS ... and other macros, which are generated by the config program, and thus less error prone; My goal is to have the "config" program take care of the configuration process, avoiding the mess which is now in local.h . As a matter of fact I am not too far from a working solution, I am just looking for a way to reduce the kernel bloat which is involved with my approach (which is no worse than the current one). - more cleanup and removal of unused code and variables; this also involves some prototypes; - some timer function moved from soundcard.c to sequencer.c, where they are used. - in some drivers I have removed the calls to the probe() routine from the attach routine. I am going to do this on other drivers as well. TODO (AND PLEASE IF YOU HAVE IDEAS ON THIS, SEND YOUR COMMENTS TO ME OR TO THE MULTIMEDIA LIST): - prepare a list of good entries for the configuration file. Those with working hardware can please send a copy of the relevant lines in their config files ? - do the files in i386/isa/sound/freebsd have any purpose, or we can nuke them ? - there are some missing lines in i386/conf/files.i386, so that some pieces of the driver are never compiled in. Again, suggestions are welcome. 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 Mon Jul 14 12:16:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA08813 for multimedia-outgoing; Mon, 14 Jul 1997 12:16: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 MAA08807 for ; Mon, 14 Jul 1997 12:16: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 MAA05742; Mon, 14 Jul 1997 12:16:44 -0700 (PDT) Message-Id: <199707141916.MAA05742@rah.star-gate.com> To: "Michael J. Yanowitz" cc: multimedia@FreeBSD.ORG Subject: Re: Do you have a Linux version? In-reply-to: Your message of "Mon, 14 Jul 1997 07:20:52 CDT." <33CA19A4.41C6@stereotaxis.wustl.edu> Date: Mon, 14 Jul 1997 12:16:44 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Brad Parker has the linux port of the bt848 driver. Cheers, Amancio >From The Desk Of "Michael J. Yanowitz" : > I have the STB TV PCI card, and Linux. Do you have a driver for > this card for Linux? If not, would you happen to know who does or > might? > > Thanks: > Michael J. Yanowitz From owner-freebsd-multimedia Mon Jul 14 14:36:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA15626 for multimedia-outgoing; Mon, 14 Jul 1997 14:36:44 -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 OAA15620 for ; Mon, 14 Jul 1997 14:36:41 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 14 Jul 1997 17:35:37 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA05968; Mon, 14 Jul 97 17:35:36 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA10280; Mon, 14 Jul 1997 17:33:35 -0400 Message-Id: <19970714173335.27084@ct.picker.com> Date: Mon, 14 Jul 1997 17:33:35 -0400 From: Randall Hopper To: Amancio Hasty Cc: Oliver Fromme , multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs References: <199707140214.EAA16083@elch.heim4.tu-clausthal.de> <199707140406.VAA01095@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707140406.VAA01095@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 09:06:53PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |In sb_dsp_close: |Move down sb_free_irq to after dsp_cleanup. | | /* DMAbuf_close_dma (dev); */ | /* sb_dsp_command (0xd4); */ | dsp_cleanup(); | sb_free_irq(); | |sb16dsp.c:sb16_dsp_close has the same problem. | |See if that fixes the sb cards hanging during a close. No change. When I got to looking closer at sb_free_irq, I saw why :-) void sb_free_irq(void) { } Randall From owner-freebsd-multimedia Mon Jul 14 14:47:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA16166 for multimedia-outgoing; Mon, 14 Jul 1997 14:47: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 OAA16161 for ; Mon, 14 Jul 1997 14:47:21 -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 OAA06213; Mon, 14 Jul 1997 14:47:17 -0700 (PDT) Message-Id: <199707142147.OAA06213@rah.star-gate.com> To: Randall Hopper cc: Oliver Fromme , multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Mon, 14 Jul 1997 17:33:35 EDT." <19970714173335.27084@ct.picker.com> Date: Mon, 14 Jul 1997 14:47:17 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Fine, I will debug it when I get home tonite. Tnks, Amancio >From The Desk Of Randall Hopper : > Amancio Hasty: > |In sb_dsp_close: > |Move down sb_free_irq to after dsp_cleanup. > | > | /* DMAbuf_close_dma (dev); */ > | /* sb_dsp_command (0xd4); */ > | dsp_cleanup(); > | sb_free_irq(); > | > |sb16dsp.c:sb16_dsp_close has the same problem. > | > |See if that fixes the sb cards hanging during a close. > > No change. When I got to looking closer at sb_free_irq, I saw why :-) > > void > sb_free_irq(void) > { > } > > Randall From owner-freebsd-multimedia Mon Jul 14 14:55:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA16662 for multimedia-outgoing; Mon, 14 Jul 1997 14:55:24 -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 OAA16654 for ; Mon, 14 Jul 1997 14:55:16 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Mon, 14 Jul 1997 17:53:36 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA06356; Mon, 14 Jul 97 17:53:34 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA10380; Mon, 14 Jul 1997 17:51:34 -0400 Message-Id: <19970714175133.20728@ct.picker.com> Date: Mon, 14 Jul 1997 17:51:33 -0400 From: Randall Hopper To: Luigi Rizzo Cc: Amancio Hasty , multimedia@freebsd.org Subject: Re: guspnp9: Recording 16-bit yields Interrupted sys call on read() References: <19970713201730.37369@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970713201730.37369@ct.picker.com>; from Randall Hopper on Sun, Jul 13, 1997 at 08:17:30PM -0400 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Randall Hopper: | Back on guspnp7, I'd mentioned this as one of the 4 main things I had |some trouble with, but didn't know it was tied to 16-bit. Figured that out |working with test cases for guspnp9 this evening. Luigi Rizzo: |If someone has problems recording with the sb (perhaps in 16-bit |mode) note that in snd970711 there was a typo in sb_dsp.c. In |sb_dsp_start_input(), around line 404, you should apply the following |fix | | if (sb_dsp_command(DSP_CMD_HSSIZE)) { /* High speed size */ | sb_dsp_command((u_char) (dsp_count & 0xff)); | sb_dsp_command((u_char) ((dsp_count >> 8) & 0xff)); |- sb_dsp_command(DSP_CMD_HSDAC); /* High speed 8 bit ADC */ |+ sb_dsp_command(DSP_CMD_HSADC); /* High speed 8 bit ADC */ | } else | printf("SB Error: Unable to start (high speed) ADC\n"); | splx(flags); | } else { Just tried this Luigi and on a 16-bit record, the first read() still terminates with interrupted system call, for all sample rates and number of channels. E.g.: > record -r 44100 -b 16 -c 2 read() failed; errno = Interrupted system call > record -r 44100 -b 16 -c 1 read() failed; errno = Interrupted system call > record -r 11025 -b 16 -c 2 read() failed; errno = Interrupted system call > record -r 11025 -b 16 -c 1 read() failed; errno = Interrupted system call Randall From owner-freebsd-multimedia Mon Jul 14 15:02:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA17050 for multimedia-outgoing; Mon, 14 Jul 1997 15:02: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 PAA17041 for ; Mon, 14 Jul 1997 15:02: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 PAA06284; Mon, 14 Jul 1997 15:02:37 -0700 (PDT) Message-Id: <199707142202.PAA06284@rah.star-gate.com> To: Randall Hopper cc: Oliver Fromme , multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs In-reply-to: Your message of "Mon, 14 Jul 1997 17:33:35 EDT." <19970714173335.27084@ct.picker.com> Date: Mon, 14 Jul 1997 15:02:37 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk If you are interested in hacking: audio_release calls : dma_sync module specific close routine (sb_close..) According to the output which Randall sent me it appears that dma_sync is waiting on the last buffer to be processed by the soundcard. I think that dma_sync can return without processing all the buffers if thats the case, then sb_close will turn off processing interrupts from the sb card and the buffer will not be processed. Amancio >From The Desk Of Randall Hopper : > Amancio Hasty: > |In sb_dsp_close: > |Move down sb_free_irq to after dsp_cleanup. > | > | /* DMAbuf_close_dma (dev); */ > | /* sb_dsp_command (0xd4); */ > | dsp_cleanup(); > | sb_free_irq(); > | > |sb16dsp.c:sb16_dsp_close has the same problem. > | > |See if that fixes the sb cards hanging during a close. > > No change. When I got to looking closer at sb_free_irq, I saw why :-) > > void > sb_free_irq(void) > { > } > > Randall From owner-freebsd-multimedia Mon Jul 14 19:50:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00596 for multimedia-outgoing; Mon, 14 Jul 1997 19:50:12 -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 TAA00590 for ; Mon, 14 Jul 1997 19:50:08 -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 TAA07898; Mon, 14 Jul 1997 19:50:06 -0700 (PDT) Message-Id: <199707150250.TAA07898@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Michael J. Yanowitz" cc: multimedia@FreeBSD.ORG, Brad Parker Subject: Re: Do you have a Linux version? In-reply-to: Your message of "Mon, 14 Jul 1997 07:20:52 CDT." <33CA19A4.41C6@stereotaxis.wustl.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jul 1997 19:50:05 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The linux version of the bt848 driver is at: ftp://ftp.parker.boston.ma.us/pub/mbone/bt848. Brad Parker is the linux mantainer Cheers, Amancio >From The Desk Of "Michael J. Yanowitz" : > I have the STB TV PCI card, and Linux. Do you have a driver for > this card for Linux? If not, would you happen to know who does or > might? > > Thanks: > Michael J. Yanowitz From owner-freebsd-multimedia Mon Jul 14 21:02:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA02825 for multimedia-outgoing; Mon, 14 Jul 1997 21:02:09 -0700 (PDT) Received: from becker2.u.washington.edu (spaz@becker2.u.washington.edu [140.142.12.68]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA02813 for ; Mon, 14 Jul 1997 21:02:02 -0700 (PDT) Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id VAA14154; Mon, 14 Jul 1997 21:01:55 -0700 (PDT) Date: Mon, 14 Jul 1997 21:01:54 -0700 (PDT) From: "J. Utz" To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: Yet another snap of the sound code... In-Reply-To: <199707141756.TAA11361@labinfo.iet.unipi.it> 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 luigi i manged to figure out how to get the files from your web page..would pointers to the directory be appropriate, or was there some simple trick in netscape that i did not understand ( i would up pointing my browser at the file., waited till it stopped loading the tgz file as a page, and then i saved the page :-) as far as a config file is concerned... i have : pas-16 mss op3/1848 thingy musicquest mqx16s ( "real mpu 401" with chase lock sync ) turtle beach maui wavetable synth, mpu-401 ( this gaily panics the system on my 2.2-ALPHA box whenever i try and run playmidi with the maui as the midi device ) my primary interest is in..well...getting any of them to work better than they do... i dont know how much time i have to mess with this, but i will compile a pas16 kernel tonight. i would like to help really shake out the midi stuff, but i doubt i will have the time.....and i may have a serious conflict of interest with my new job working at a local microsoft contractor... nonetheless, i can at least make suggestions..... john ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Mon Jul 14 22:35:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA06659 for multimedia-outgoing; Mon, 14 Jul 1997 22:35:47 -0700 (PDT) Received: from becker2.u.washington.edu (spaz@becker2.u.washington.edu [140.142.12.68]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA06654 for ; Mon, 14 Jul 1997 22:35:43 -0700 (PDT) Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id WAA16194; Mon, 14 Jul 1997 22:35:31 -0700 (PDT) Date: Mon, 14 Jul 1997 22:35:29 -0700 (PDT) From: "J. Utz" To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: This is *really* cool!Re: Yet another snap of the sound code... 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 Hello again! just to follow up on my own post. i am building a kernel for my maui/pas16 machine ( yes, i am a soundcard geek in waiting, it was one of the reasons why i studied electrical engineering/dsp!!!!) i have rebuilt it several times because i have had trouble trying to figure out how to drive the damn thing! one of the things that is reaally coll is that my first pass was to just toss my existing config at the new sound code. Watching the probing routine work is an absolute joy to behold! It happily fired up my PAS-16 but absolute called bullshit on me with respect to my attempt to pass of my maui as a roland card: npx0: INT 16 interface -- sndtable_probe(3) -- installing card 0 -- Driver name 'ProAudioSpectrum' probe 0xf01c68f4 -- Hardware probed OK pas0 at 0x388 irq 10 drq 3 flags 0xffffffff on isa sndtable_init_card(3) entered Located card - calling attach routine at 0x388 irq 10 dma 3,7 attach routine finished -- sndtable_probe(1) -- installing card 1 -- Driver name 'OPL-2/OPL-3 FM' probe 0xf01c1024 -- Failed to find hardware opl10 not found at 0x38a -- sndtable_probe(5) -- installing card 2 -- Driver name 'Roland MPU-401' probe 0xf01c3e68 MPU401: Port 330 looks dead. -- Failed to find hardware mpu0 not found at 0x330 notice how the opl10 driver ( the opl3 driver) was handled notice how it picked up on my trickery on the midi card. the old stuff probed it as a mpu401 card! NOW the PROBLEMS! Basically 2: Config undefs my maui card and defines an MSS card despite me telling it to do exactly the opposite... oops kernel is done! gotta go try it! On Mon, 14 Jul 1997, J. Utz wrote: > Hi luigi > > i manged to figure out how to get the files from your web page..would > pointers to the directory be appropriate, or was there some simple trick > in netscape that i did not understand ( i would up pointing my browser at > the file., waited till it stopped loading the tgz file as a page, and then > i saved the page :-) > > as far as a config file is concerned... > > i have : > > pas-16 > > mss op3/1848 thingy > > musicquest mqx16s ( "real mpu 401" with chase lock sync ) > > turtle beach maui wavetable synth, mpu-401 ( this gaily panics the system > on my 2.2-ALPHA box whenever i try and run playmidi with the maui as the > midi device ) > > my primary interest is in..well...getting any of them to work better than > they do... > > i dont know how much time i have to mess with this, but i will compile a > pas16 kernel tonight. > > i would like to help really shake out the midi stuff, but i doubt i will > have the time.....and i may have a serious conflict of interest with my > new job working at a local microsoft contractor... > > nonetheless, i can at least make suggestions..... > > john > > ******************************************************************************* > John Utz spaz@u.washington.edu > idiocy is the impulse function in the convolution of life > > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Tue Jul 15 03:35:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA20126 for multimedia-outgoing; Tue, 15 Jul 1997 03:35: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 DAA20120 for ; Tue, 15 Jul 1997 03:35: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 DAA00279 for ; Tue, 15 Jul 1997 03:35:44 -0700 (PDT) Message-Id: <199707151035.DAA00279@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org Subject: ftp://rah.star-gate.com/pub/guspnp10.tar.gz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 03:35:44 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This release fixes the hanging problem that people are seeing with sbxxx cards. Minor clean up done to sbxxx module. No new functionality has been added. Didn't get a chance to fold in luigi changes will do that tomorrow. Amancio From owner-freebsd-multimedia Tue Jul 15 08:34:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA04885 for multimedia-outgoing; Tue, 15 Jul 1997 08:34:58 -0700 (PDT) Received: from bmccane.uit.net (bmccane.uit.net [208.129.189.48]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA04811; Tue, 15 Jul 1997 08:34:34 -0700 (PDT) Received: from bmccane.uit.net (localhost.mccane.com [127.0.0.1]) by bmccane.uit.net (8.8.5/8.8.5) with ESMTP id KAA22881; Tue, 15 Jul 1997 10:34:13 -0500 (CDT) Message-Id: <199707151534.KAA22881@bmccane.uit.net> X-Mailer: exmh version 2.0gamma 1/27/96 To: Amancio Hasty cc: multimedia@FreeBSD.ORG, chat@FreeBSD.ORG Subject: Re: Free At Last: A Scanner Storyn In-reply-to: Your message of "Sat, 28 Jun 1997 23:30:06 PDT." <199706290630.XAA07386@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 10:34:13 -0500 From: Wm Brian McCane Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > This is what I did to the scsi subsystem: > > /sys/scsi/scsiconf.c: > static struct scsidevs unknowndev = > { > T_UNKNOWN, T_UNKNOWN, 0, "*", "*", "*", > "uk", SC_ONE_LU > /* "uk", SC_MORE_LUS*/ > }; > > > /sys/scsi/scsi_ioctl.c: > > case XS_BUSY: > SC_DEBUG(xs->sc_link,SDEV_DB3,("busy\n")); > screq->retsts = SCCMD_BUSY; > break; > > default: > /*sc_print_addr(xs->sc_link); */ > screq->retsts = SCCMD_UNKNOWN; > break; > } > Howdy, sorry it has taken me so long to get back with you, I've been very busy (yay! I get paid ;). Anyway, after making your changes and building a new UNIX kernel, it appears to work "correctly". Except for one small problem: Whataver is in the buffer passed to the "INQUIRY" command in mustek.c is returned unchanged. The odd thing is that I am being told that the command succeeded, and that 96 bytes were read. I have tried to look at umax_??.c for differences, but there are more than a few. I then tried: $ scsi -f /dev/uk0 -c "12 0 0 0 60 0" -i 96 "s8" the Kernel debug output looks like: uk0(ahc0:3:0): scsi_cmd uk0(ahc0:3:0): get_xs uk0(ahc0:3:0): returning xs(0xf048dc00): flg(0x60)sc_link(0xf048db80)retr(0x2)timo(0x186a0) cmd(0xf048dc58)len(0x6)data(0x0)len(0x0)res(0x0) err(0x0)bp(0x0) uk0: command: 0,0,0,0,0,0-[0 bytes] uk0(ahc0:3:0): scsi_done uk0: command: 0,0,0,0,0,0-[0 bytes] uk0(ahc0:3:0): back in cmd() uk0(ahc0:3:0): sc_err1,err = 0x0 uk0(ahc0:3:0): free_xs uk0(ahc0:3:0): ukopen: dev=0x1f00 (unit 0) result 0 uk0(ahc0:3:0): scsi_do_ioctl(0xc0605101) uk0(ahc0:3:0): user_strategy uk0(ahc0:3:0): scsi_cmd uk0(ahc0:3:0): get_xs uk0(ahc0:3:0): returning xs(0xf048dc00): flg(0x428)sc_link(0xf048db80)retr(0x0)timo(0x7d0) cmd(0xf048dc58)len(0x6)data(0xf377e080)len(0x60) res(0x0)err(0x0)bp(0xf0861000) uk0: command: 12,0,0,0,60,0-[96 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ uk0(ahc0:3:0): abuk0(ahc0:3:0): scsi_done uk0: command: 12,0,0,0,60,0-[96 bytes] ------------------------------ 000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 032: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 048: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ------------------------------ uk0(ahc0:3:0): calling user done() uk0(ahc0:3:0): user-done uk0(ahc0:3:0): no error uk0(ahc0:3:0): returned from user done() uk0(ahc0:3:0): free_xs uk0(ahc0:3:0): returning to adapter out to sleep uk0(ahc0:3:0): back from sleep uk0(ahc0:3:0): ukclose: Closing device Notice that ALL 0's are returned in the result buffer, which is what is passed in the scsi command because they "bzero" the buffer before calling scsireq_enter. Could my problem be because this is a "Unknown device" and is thus not copying the result buffer into user space. Or could it be something else? brian From owner-freebsd-multimedia Tue Jul 15 10:08:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA10915 for multimedia-outgoing; Tue, 15 Jul 1997 10:08: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 KAA10907 for ; Tue, 15 Jul 1997 10:08:47 -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 KAA01690 for ; Tue, 15 Jul 1997 10:08:47 -0700 (PDT) Message-Id: <199707151708.KAA01690@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org Subject: About the Sound Driver Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 15 Jul 1997 10:08:47 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I think that I am going to leave the sound driver open for clean up kind of work till next monday. After that we will pick a stable configuration for testing and then integration into 3.0-current. This basically means that we will have frequent releases of the sound driver and that it will be nice if people post bugs or suggestions. it will be nice if some of you takes the lead on : 1. getting rid of static variables in the sound driver. If a driver needs to keep track of state it should go into its own internal per device data structure. We can partition this task on a per module basis. sb , ad1848, gus, etc... 2. clean up the prope and attach routine -- right now it is spaghetti code. 3. Provide generalized PnP support . Right now only the GUS PnP has native PnP support. Currently, I am reliant heavely on Luigi for leading the code clean up effort. Now , I hope, that the sb plack back hang is gone I hope to sync up with Luigi. Enjoy, Amancio From owner-freebsd-multimedia Tue Jul 15 10:33:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA12198 for multimedia-outgoing; Tue, 15 Jul 1997 10:33:55 -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 KAA12142 for ; Tue, 15 Jul 1997 10:33:27 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA12971; Tue, 15 Jul 1997 18:26:49 +0200 From: Luigi Rizzo Message-Id: <199707151626.SAA12971@labinfo.iet.unipi.it> Subject: Re: About the Sound Driver To: hasty@rah.star-gate.com (Amancio Hasty) Date: Tue, 15 Jul 1997 18:26:48 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199707151708.KAA01690@rah.star-gate.com> from "Amancio Hasty" at Jul 15, 97 10:08:28 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am not yet at the stage of working on #1, whereas #2 (eating spaghetti...) is relatively easy for me now that I have spent so many hours on the driver, and #3 (adding generic pnp support) is what I definitely want to do. For #3 do not be in a hurry since I am still evaluating the best architectural approach and I would hate to do some quick&dirty hack which once working would stay there forever I am sure. > Currently, I am reliant heavely on Luigi for leading the code clean up > effort. Now , I hope, that the sb plack back hang is gone I hope > to sync up with Luigi. so do I -- I will fetch your guspnp10 (or whatever you have by tomorrow) and sync up with my code (which is essentially snd970714) While you look at the sb things, randall was still having troubles recording from the sb16, and the error message (Interrupted system call) perhaps might be related to the recent inclusion of many checks for EINTR in the DMA code ? Luigi From owner-freebsd-multimedia Tue Jul 15 11:31:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA15433 for multimedia-outgoing; Tue, 15 Jul 1997 11:31:08 -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 LAA15427 for ; Tue, 15 Jul 1997 11:31:06 -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 LAA02052; Tue, 15 Jul 1997 11:30:23 -0700 (PDT) Message-Id: <199707151830.LAA02052@rah.star-gate.com> To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: About the Sound Driver In-reply-to: Your message of "Tue, 15 Jul 1997 18:26:48 +0200." <199707151626.SAA12971@labinfo.iet.unipi.it> Date: Tue, 15 Jul 1997 11:30:23 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am not sure what Randall's problem is since I am able to record from my SB16 thingy . Well, I am not entirely certain that it records well since it is hard to check out the sound remote. Again, record a file and download it to my job however I rather wait till I get home. This is with guspnp10 . Will be happy to check out the code plus your mods when I get home tonite. Cheers, Amancio >From The Desk Of Luigi Rizzo : > I am not yet at the stage of working on #1, whereas #2 (eating > spaghetti...) is relatively easy for me now that I have spent so > many hours on the driver, and #3 (adding generic pnp support) is > what I definitely want to do. For #3 do not be in a hurry since I > am still evaluating the best architectural approach and I would > hate to do some quick&dirty hack which once working would stay > there forever I am sure. > > > Currently, I am reliant heavely on Luigi for leading the code clean up > > effort. Now , I hope, that the sb plack back hang is gone I hope > > to sync up with Luigi. > > so do I -- I will fetch your guspnp10 (or whatever you have by > tomorrow) and sync up with my code (which is essentially snd970714) > > While you look at the sb things, randall was still having troubles > recording from the sb16, and the error message (Interrupted system > call) perhaps might be related to the recent inclusion of many checks > for EINTR in the DMA code ? > > Luigi From owner-freebsd-multimedia Tue Jul 15 12:28:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA19088 for multimedia-outgoing; Tue, 15 Jul 1997 12:28:59 -0700 (PDT) Received: from ns1.netcologne.de (ns1.netcologne.de [194.8.194.70]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id MAA19046; Tue, 15 Jul 1997 12:28:46 -0700 (PDT) Received: from janus by ns1.netcologne.de (8.6.12/NetCologne/marvin/netsafe-a0020) id ; Tue, 15 Jul 1997 22:25:04 +0200 with ESMTP X-Ncc-Regid: de.netcologne Message-ID: <33CBCF59.6944D32C@netcologne.de> Date: Tue, 15 Jul 1997 21:28:25 +0200 From: Richard Cochius Reply-To: richard.cochius@netcologne.de Organization: Media Connect Cologne X-Mailer: Mozilla 4.01 [en] (WinNT; I) MIME-Version: 1.0 To: "\"'freebsd-bugs@freebsd.org'\"" , "freebsd-chat@FreeBSD.ORG" , "freebsd-current@FreeBSD.ORG" , "freebsd-multimedia@FreeBSD.ORG" , "freebsd-questions@FreeBSD.ORG" , "hackers@FreeBSD.ORG" , "owner-hackers@FreeBSD.ORG" , "questions@FreeBSD.ORG" Subject: unsubscribe X-Priority: 3 (Normal) Content-Type: multipart/mixed; boundary="------------A49C1ABE0E75DBD5710EBE03" Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multi-part message in MIME format. --------------A49C1ABE0E75DBD5710EBE03 Content-Type: text/plain; charset=us-ascii Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit unsubscribe --------------A49C1ABE0E75DBD5710EBE03 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Richard Cochius Content-Disposition: attachment; filename="vcard.vcf" begin: vcard fn: Richard Cochius n: Cochius;Richard org: Media Connect Cologne adr: ;;;;;; email;internet: richard.cochius@netcologne.de tel;work: tel;fax: tel;home: x-mozilla-cpt: ;0 x-mozilla-html: FALSE end: vcard --------------A49C1ABE0E75DBD5710EBE03-- From owner-freebsd-multimedia Tue Jul 15 14:36:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA25471 for multimedia-outgoing; Tue, 15 Jul 1997 14:36: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 OAA25441 for ; Tue, 15 Jul 1997 14:35:57 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id RAA02367 for ; Tue, 15 Jul 1997 17:38:05 -0400 (EDT) Date: Tue, 15 Jul 1997 17:38:01 -0400 (EDT) From: Bernie Doehner X-Sender: bad@uhf.wdc.net To: multimedia@freebsd.org Subject: any mad16 hackers/owners out there? In-Reply-To: <199707151708.KAA01690@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 Quick question: Who on this list also has a mad16 card and has been working on porting the mad16 Linux Voxware driver to FreeBSD? I tried quite a while ago and miserably failed, but I also didn't try very hard. Would be nice if I had some company :) Bernie From owner-freebsd-multimedia Tue Jul 15 14:55:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA26485 for multimedia-outgoing; Tue, 15 Jul 1997 14:55:05 -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 OAA26474 for ; Tue, 15 Jul 1997 14:54:57 -0700 (PDT) Received: from localhost (bad@localhost) by uhf.wdc.net (8.8.5/8.6.12) with SMTP id RAA02438; Tue, 15 Jul 1997 17:56:26 -0400 (EDT) Date: Tue, 15 Jul 1997 17:56:24 -0400 (EDT) From: Bernie Doehner X-Sender: bad@uhf.wdc.net To: Luigi Rizzo cc: Amancio Hasty , multimedia@FreeBSD.ORG Subject: Clarification on PNP. In-Reply-To: <199707151626.SAA12971@labinfo.iet.unipi.it> 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 not yet at the stage of working on #1, whereas #2 (eating > spaghetti...) is relatively easy for me now that I have spent so > many hours on the driver, and #3 (adding generic pnp support) is > what I definitely want to do. For #3 do not be in a hurry since I > am still evaluating the best architectural approach and I would > hate to do some quick&dirty hack which once working would stay > there forever I am sure. > The MAD16 card under DOS has a little program you are supposed to run from DOS Autoexec.bat (it loads the card's configuration). This is what you mean by PnP, isn't it? And as such I should probably wait for Luigi's "conceptual framework" before trying again? Bernie From owner-freebsd-multimedia Tue Jul 15 15:41:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA29059 for multimedia-outgoing; Tue, 15 Jul 1997 15:41:33 -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 PAA29054 for ; Tue, 15 Jul 1997 15:41:29 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 15 Jul 1997 18:38:34 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA09965; Tue, 15 Jul 97 18:38:32 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA24464; Tue, 15 Jul 1997 18:36:30 -0400 Message-Id: <19970715183629.62447@ct.picker.com> Date: Tue, 15 Jul 1997 18:36:29 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: guspnp9: /dev/dsp close() hangs References: <199707140232.EAA16122@elch.heim4.tu-clausthal.de> <199707140310.UAA00830@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707140310.UAA00830@rah.star-gate.com>; from Amancio Hasty on Sun, Jul 13, 1997 at 08:10:35PM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Thanks for the hang-on-close() SB DSP fix Amancio! Try as I might, I can't make this happen with guspnp10 anymore. :-) I'm continuing to put the driver through its paces this evening, and will let you all know how it goes. So far, there's the outstanding: - Recording 16-bit yields Interrupted sys call on read() failure that I've already reported and a new one: - Repeated samples during ULAW play that I just found. I post details in a separate thread. Randall From owner-freebsd-multimedia Tue Jul 15 15:48:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA29360 for multimedia-outgoing; Tue, 15 Jul 1997 15:48: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 PAA29354 for ; Tue, 15 Jul 1997 15:48:32 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 15 Jul 1997 18:46:47 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA10103; Tue, 15 Jul 97 18:46:46 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA24478; Tue, 15 Jul 1997 18:44:44 -0400 Message-Id: <19970715184443.32058@ct.picker.com> Date: Tue, 15 Jul 1997 18:44:43 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp10: Repeated samples during ULAW play Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Playing a ULAW (.au) stream (either via /dev/audio or /dev/dsp) frequently now repeats the first chunk in the stream. That is, you'll hear the full stream, and then a half second or so off the front of that stream. Might may be related to the hang-on-close() fix. It's easy to reproduce. Most of the .au's I have lying around do this now. I've uploaded 3 of them to rah as: TSTSND-att.au TSTSND-autopil.au TSTSND-elvis-has-left-bldg.au Just "cat snd.au > /dev/audio". Thanks, Randall From owner-freebsd-multimedia Tue Jul 15 16:11:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA00506 for multimedia-outgoing; Tue, 15 Jul 1997 16:11:49 -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 QAA00499 for ; Tue, 15 Jul 1997 16:11:42 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 15 Jul 1997 19:10:27 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA10471; Tue, 15 Jul 97 19:10:26 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id TAA24593; Tue, 15 Jul 1997 19:08:23 -0400 Message-Id: <19970715190823.51050@ct.picker.com> Date: Tue, 15 Jul 1997 19:08:23 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@freebsd.org Subject: guspnp10: Load "pops" at start & end of ULAW play Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk For comparison, I played the same .au files on the checked-in Voxware 3.0 drivers and guspnp10. On 3.0, clean start & end of sample play. guspnp10 has load pops. Same results via /dev/audio and /dev/dsp. Again, easy to reproduce. Just cat a clean .au to /dev/audio. Randall From owner-freebsd-multimedia Tue Jul 15 16:31:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA01512 for multimedia-outgoing; Tue, 15 Jul 1997 16:31:50 -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 QAA01507 for ; Tue, 15 Jul 1997 16:31:47 -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 QAA03242; Tue, 15 Jul 1997 16:31:36 -0700 (PDT) Message-Id: <199707152331.QAA03242@rah.star-gate.com> To: Bernie Doehner cc: Luigi Rizzo , multimedia@FreeBSD.ORG Subject: Re: Clarification on PNP. In-reply-to: Your message of "Tue, 15 Jul 1997 17:56:24 EDT." Date: Tue, 15 Jul 1997 16:31:36 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I actually you don't have to wait for Luigi's PnP . Sujal Patel wrote a PnP configuration driver support. It is primitive ;however in your case you can use it to init the mad16 card and continue with the mad16 support. I will post later on Suja's PnP configurator. Currrently, at work. Cheers, Amancio >From The Desk Of Bernie Doehner : > > I am not yet at the stage of working on #1, whereas #2 (eating > > spaghetti...) is relatively easy for me now that I have spent so > > many hours on the driver, and #3 (adding generic pnp support) is > > what I definitely want to do. For #3 do not be in a hurry since I > > am still evaluating the best architectural approach and I would > > hate to do some quick&dirty hack which once working would stay > > there forever I am sure. > > > > The MAD16 card under DOS has a little program you are supposed to run from > DOS Autoexec.bat (it loads the card's configuration). This is what you > mean by PnP, isn't it? And as such I should probably wait for Luigi's > "conceptual framework" before trying again? > > Bernie > From owner-freebsd-multimedia Thu Jul 17 19:35:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA21628 for multimedia-outgoing; Thu, 17 Jul 1997 19:35:53 -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 TAA21623 for ; Thu, 17 Jul 1997 19:35:50 -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 TAA06776; Thu, 17 Jul 1997 19:35:10 -0700 (PDT) Message-Id: <199707180235.TAA06776@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Conrad Sabatier cc: Daniel Baker , Robert Busby , Steve Galland , Patrick McGuire , Gary Pitts , "Craig B. Massey" , freebsd-multimedia@FreeBSD.ORG Subject: Re: MAJOR progress on the AWE 64 sound front under FreeBSD! In-reply-to: Your message of "Thu, 17 Jul 1997 18:24:05 CDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 17 Jul 1997 19:35:10 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, the PnP stuff is not that bad if you happen to have a PnP bios and know what the BIOS sets your card to then you can treat it as a regular card provided of course that the card does not require further initialization such as the gus pnp. You haven't mentioned which sound driver are you using. Till Luigi rolls out his supper duper sound driver with PnP support you can init PnP devices in FreeBSD with: ftp://rah.star-gate.com/pub/FreeBSD-ISA_PnP_June8.tar.gz Sujal Patel from Progressive Networks is the author of the PnP code . Randall reminded me about a patch to the above PnP code. Recently I bought a SB 16 PnP and my BIOS is initializing the card so I don't need the PnP code for my P133 test system . The PnP code can reconfigure the card in case that I specifically need to test or use a configuration. ----- I found a problem in pnp.c of FreeBSD-ISA_PnP_June8.tar.gz. If Logical Device Number is explicitly specified as `0', it cause a trouble. A board which has multiple LDN (such as Sound Blaster {32, AWE32, AWE64}) may not work. -- furuta@sra.co.jp (Atsushi Furuta) Advanced Technology Group. Software Research Associates, Inc. --- pnp.c.orig Wed Jul 16 11:38:26 1997 +++ pnp.c Wed Jul 16 11:39:06 1997 @@ -206,7 +206,7 @@ printf (" Configuring (Logical Device %x)\n", ci->ldn != -1 ? ci->ldn : 0); - if (ci->ldn > 0) + if (ci->ldn >= 0) SEND (SET_LDN, ci->ldn); for (i = 0; i < 8; i++) -----End of forwarded message----- Enjoy, Amancio >From The Desk Of Conrad Sabatier : > I'm listening to a CD in the background as I type this, playing through my > Soundblaster AWE 64! Yay! > > Got the CD, microphone and mixer parts working; the mixer even does bass and > treble! Still having some problems with MIDI/au stuff, though. I think I'm > definitely going to have to install that AWE driver for FreeBSD to get that > ironed out. Think I'll postpone that until the weekend, when I can work on > it concentratedly. I'm too excited right now. :-) > > Still, I can't believe I'm actually getting *sound* out of this thing, under > UNIX! I was just about ready to just write it off as impossible, or at > least just too frustratingly difficult to bother with. Fantastic! > > Think I'll go have a few beers tonight to celebrate. :-) > > Conrad, boy genius, in a decidedly self-congratulatory mood (and deservedly > so!) :-) > > P.S. For those of you just tuning in, the AWE 64 is a Plug-and-Play card > (some would say Plug-and-Pray). FreeBSD, unfortunately, does *not* support > PnP by default, so configuring certain hardware is a rather tricky business > (especially cards like this one, that have no jumpers or DIP switches to > configure the IRQ and such). > > -- > Conrad Sabatier > http://www.neosoft.com/~conrads/ From owner-freebsd-multimedia Thu Jul 17 20:42:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA24747 for multimedia-outgoing; Thu, 17 Jul 1997 20:42:18 -0700 (PDT) Received: from localhost.neosoft.com (as5200-port-254.no.neosoft.com [206.27.167.254]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA24739 for ; Thu, 17 Jul 1997 20:42:12 -0700 (PDT) Received: (from conrads@localhost) by localhost.neosoft.com (8.8.6/8.8.6) id DAA01257; Fri, 18 Jul 1997 03:40:37 GMT Message-ID: X-Mailer: XFMail 1.2-alpha [p0] on FreeBSD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199707180235.TAA06776@rah.star-gate.com> Date: Thu, 17 Jul 1997 22:40:36 -0500 (CDT) Organization: NeoSoft, Inc. From: Conrad Sabatier To: Amancio Hasty Subject: Re: MAJOR progress on the AWE 64 sound front under FreeBSD! Cc: freebsd-multimedia@FreeBSD.ORG Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On 18-Jul-97 Amancio Hasty wrote: >Well, the PnP stuff is not that bad if you happen to have a PnP bios >and know what the BIOS sets your card to then you can treat it >as a regular card provided of course that the card does not require >further initialization such as the gus pnp. The problem with my system is that it has this lousy motherboard audio that conflicts with the AWE 64. So I had to disable the PnP BIOS and manually configure everything. >You haven't mentioned which sound driver are you using. VoxWare Sound Driver:3.0-beta-950506 (Sun Feb 5 14:38:12 EST 1995 freebsd-hackers@freefall.cdrom.com) >Till Luigi rolls out his supper duper sound driver with PnP support you >can init PnP devices in FreeBSD with: > >ftp://rah.star-gate.com/pub/FreeBSD-ISA_PnP_June8.tar.gz > >Sujal Patel from Progressive Networks is the author of the PnP >code . Yes, I've experimented with this before, but because I was still using the PnP BIOS at the time, it didn't help (the card still wasn't being found at boot time). I think now that the card is being recognized, and the motherboard audio is disabled (hallelujah!), this might help. Will try it again, for sure. >Randall reminded me about a patch to the above PnP code. >Recently I bought a SB 16 PnP and my BIOS is initializing the >card so I don't need the PnP code for my P133 test system . >The PnP code can reconfigure the card in case that I specifically >need to test or use a configuration. My machine has one of the weirdest BIOSes. If I enable PnP, the AWE 64 isn't found. If I disable PnP, the AWE 64 is found, but the motherboard PS/2 mouse disappears. Really screwy. I finally had to attach a serial mouse and disable PnP altogether. Of course, this means the card is not being initialized, which I think is why the MIDI/au stuff is still not right. Still, I seem to be on the right track, at last. Will explore the PnP code and the AWE driver, and hopefully get the card fully functional soon. In the meantime, it sure is nice to finally have CD audio! :-) -- Conrad Sabatier http://www.neosoft.com/~conrads/ From owner-freebsd-multimedia Fri Jul 18 00:23:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05748 for multimedia-outgoing; Fri, 18 Jul 1997 00:23:39 -0700 (PDT) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA05732 for ; Fri, 18 Jul 1997 00:23:31 -0700 (PDT) Received: from sister.ludd.luth.se (gozer@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with SMTP id JAA12542; Fri, 18 Jul 1997 09:23:24 +0200 Date: Fri, 18 Jul 1997 09:23:18 +0200 (MET DST) From: Johan Larsson Reply-To: Johan Larsson To: Amancio Hasty cc: freebsd-multimedia@freebsd.org Subject: Re: MAJOR progress on the AWE 64 sound front under FreeBSD! In-Reply-To: <199707180235.TAA06776@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 Thu, 17 Jul 1997, Amancio Hasty wrote: > Till Luigi rolls out his supper duper sound driver with PnP support you > can init PnP devices in FreeBSD with: > > ftp://rah.star-gate.com/pub/FreeBSD-ISA_PnP_June8.tar.gz > > Sujal Patel from Progressive Networks is the author of the PnP > code . Doesn't this code require 2.* kernels? Is there anything like this for the 3.0-current kernel? I have a nonPnP bios, so i have to boot into dos and initialize my sb16pnp, and then softboot into freebsd. I know i asked this before :-) But i didn't get any answer the last time. -- * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * * finger gozer@mother.ludd.luth.se for more information... +-+-+ * From owner-freebsd-multimedia Fri Jul 18 00:24:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA05864 for multimedia-outgoing; Fri, 18 Jul 1997 00:24: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 AAA05855 for ; Fri, 18 Jul 1997 00:24:48 -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 AAA00526; Fri, 18 Jul 1997 00:24:43 -0700 (PDT) Message-Id: <199707180724.AAA00526@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Johan Larsson cc: freebsd-multimedia@freebsd.org Subject: Re: MAJOR progress on the AWE 64 sound front under FreeBSD! In-reply-to: Your message of "Fri, 18 Jul 1997 09:23:18 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 00:24:42 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk This code works fine with 3.0 -current which is what I run over here. Regards, Amancio >From The Desk Of Johan Larsson : > On Thu, 17 Jul 1997, Amancio Hasty wrote: > > > Till Luigi rolls out his supper duper sound driver with PnP support you > > can init PnP devices in FreeBSD with: > > > > ftp://rah.star-gate.com/pub/FreeBSD-ISA_PnP_June8.tar.gz > > > > Sujal Patel from Progressive Networks is the author of the PnP > > code . > > Doesn't this code require 2.* kernels? Is there anything like this for the > 3.0-current kernel? I have a nonPnP bios, so i have to boot into dos and > initialize my sb16pnp, and then softboot into freebsd. I know i asked > this before :-) But i didn't get any answer the last time. > > -- > * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * > * finger gozer@mother.ludd.luth.se for more information... +-+-+ * > > > From owner-freebsd-multimedia Fri Jul 18 00:33:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA06277 for multimedia-outgoing; Fri, 18 Jul 1997 00:33:38 -0700 (PDT) Received: from zed.ludd.luth.se (zed.ludd.luth.se [130.240.16.33]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA06272 for ; Fri, 18 Jul 1997 00:33:34 -0700 (PDT) Received: from sister.ludd.luth.se (gozer@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with SMTP id JAA12637; Fri, 18 Jul 1997 09:33:28 +0200 Date: Fri, 18 Jul 1997 09:33:21 +0200 (MET DST) From: Johan Larsson To: Amancio Hasty cc: freebsd-multimedia@freebsd.org Subject: Re: MAJOR progress on the AWE 64 sound front under FreeBSD! In-Reply-To: <199707180724.AAA00526@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 Hmm, strange.. Oh well, i try to build a new kernel tonight and see if it goes better. :-) On Fri, 18 Jul 1997, Amancio Hasty wrote: > This code works fine with 3.0 -current which is what I run over here. > > Regards, > Amancio > > >From The Desk Of Johan Larsson : > > On Thu, 17 Jul 1997, Amancio Hasty wrote: > > > > > Till Luigi rolls out his supper duper sound driver with PnP support you > > > can init PnP devices in FreeBSD with: > > > > > > ftp://rah.star-gate.com/pub/FreeBSD-ISA_PnP_June8.tar.gz > > > > > > Sujal Patel from Progressive Networks is the author of the PnP > > > code . > > > > Doesn't this code require 2.* kernels? Is there anything like this for the > > 3.0-current kernel? I have a nonPnP bios, so i have to boot into dos and > > initialize my sb16pnp, and then softboot into freebsd. I know i asked > > this before :-) But i didn't get any answer the last time. > > > > -- > > * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * > > * finger gozer@mother.ludd.luth.se for more information... +-+-+ * > > > > > > > > > -- * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * * finger gozer@mother.ludd.luth.se for more information... +-+-+ * From owner-freebsd-multimedia Fri Jul 18 03:11:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA13717 for multimedia-outgoing; Fri, 18 Jul 1997 03:11: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 DAA13712 for ; Fri, 18 Jul 1997 03:11:47 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id LAA17413 for multimedia@freebsd.org; Fri, 18 Jul 1997 11:07:33 +0200 From: Luigi Rizzo Message-Id: <199707180907.LAA17413@labinfo.iet.unipi.it> Subject: sound and dma ... To: multimedia@freebsd.org Date: Fri, 18 Jul 1997 11:07:33 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk looking at the dma code in the sound driver (dmabuf.c) it appears that the driver supports the splitting of the buffers in a number of sub-buffers, so that some can be initialized with data while another one can be in use for the dma engine. This should serve to avoid clicks and interruptions in the flow of sound data especially at high speeds. However: - this mechanism really seems overkill, two buffers being sufficient (and additional buffering can be implemented separately if needed); - i am not sure if the mechanism is really used at all. The default in the code is to use only ONE buffer, and can be overridden only if some application issues one of these two ioctls: SOUND_PCM_SUBDIVIDE SNDCTL_DSP_SUBDIVIDE (and still... they could be implemented as nops and let two buffers be the default as in pcaudio.) Can you please do a grep on the sources of your favourite sound applications to see if they happen to use one of the two ioctls above ? In rewriting the dma code I would certainly prefer not to deal with this overly complex mechanism and go with plain double buffering. 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 Fri Jul 18 08:06:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA25165 for multimedia-outgoing; Fri, 18 Jul 1997 08:06: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 IAA25150 for ; Fri, 18 Jul 1997 08:06: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 IAA05006; Fri, 18 Jul 1997 08:03:37 -0700 (PDT) Message-Id: <199707181503.IAA05006@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: sound and dma ... In-reply-to: Your message of "Fri, 18 Jul 1997 11:07:33 +0200." <199707180907.LAA17413@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 08:03:37 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, The problem with eliminating functionality like is that it will render us uncompatible with the linux or with linux apps. SOUND_PCM_SUBDIVIDE is really use for setting the buffer size and to provide multiple buffers. The sound driver generates N number of buffers based upon the size of its pool and the the size of a buffer. The intent is eliminate clicks. There is also buffering done on sound cards such as the gus --- the gus as to pcm devices its native one and its cs4231 , on the native side the driver buffer up sound streams so the effect is double buffering. Regards, Amancio >From The Desk Of Luigi Rizzo : > looking at the dma code in the sound driver (dmabuf.c) it appears that > the driver supports the splitting of the buffers in a number of > sub-buffers, so that some can be initialized with data while another > one can be in use for the dma engine. This should serve to avoid clicks > and interruptions in the flow of sound data especially at high speeds. > > However: > - this mechanism really seems overkill, two buffers being sufficient > (and additional buffering can be implemented separately if needed); > > - i am not sure if the mechanism is really used at all. The default in > the code is to use only ONE buffer, and can be overridden only if > some application issues one of these two ioctls: > SOUND_PCM_SUBDIVIDE > SNDCTL_DSP_SUBDIVIDE > (and still... they could be implemented as nops and let two buffers > be the default as in pcaudio.) > > Can you please do a grep on the sources of your favourite sound > applications to see if they happen to use one of the two ioctls above ? > > In rewriting the dma code I would certainly prefer not to deal with this > overly complex mechanism and go with plain double buffering. > > 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 Fri Jul 18 08:28:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA27906 for multimedia-outgoing; Fri, 18 Jul 1997 08:28:36 -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 IAA27776 for ; Fri, 18 Jul 1997 08:27:13 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA17750; Fri, 18 Jul 1997 16:13:17 +0200 From: Luigi Rizzo Message-Id: <199707181413.QAA17750@labinfo.iet.unipi.it> Subject: Re: sound and dma ... To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 18 Jul 1997 16:13:17 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199707181503.IAA05006@rah.star-gate.com> from "Amancio Hasty" at Jul 18, 97 08:03:18 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hi, > The problem with eliminating functionality like is that > it will render us uncompatible with the linux or with linux > apps. > > SOUND_PCM_SUBDIVIDE is really use for setting the buffer size and > to provide multiple buffers. > > The sound driver generates N number of buffers based upon the size > of its pool and the the size of a buffer. The intent is eliminate > clicks. There is also buffering done on sound cards such as the right, I was mistaken... at a more careful reading the code seems to generate a number of sub-buffers as you mention, and the 'SUBDIVIDE' ioctl is only of use if one wants to force the driver to split the available buffer space in more pieces than it would do using the normal heuristics. In this view (and especially, now that I understand _how_ it works), I can probably keep the current code. Note however that my idea was _not_ to kill the ioctl, just make it a NOP. Cheers Luigi From owner-freebsd-multimedia Fri Jul 18 09:33:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA01750 for multimedia-outgoing; Fri, 18 Jul 1997 09:33: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 JAA01739 for ; Fri, 18 Jul 1997 09:33:18 -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 JAA05399; Fri, 18 Jul 1997 09:30:57 -0700 (PDT) Message-Id: <199707181630.JAA05399@rah.star-gate.com> To: Luigi Rizzo cc: multimedia@FreeBSD.ORG Subject: Re: sound and dma ... In-reply-to: Your message of "Fri, 18 Jul 1997 16:13:17 +0200." <199707181413.QAA17750@labinfo.iet.unipi.it> Date: Fri, 18 Jul 1997 09:30:57 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk No problem;specially, since , the dma subsystem is so complex for just playing audio --- I think is amazing . Hopefully, with PCI things will get better because the complex buffering scheme is really about reducing latency to the sound card. Have fun! Amancio >From The Desk Of Luigi Rizzo : > > Hi, > > The problem with eliminating functionality like is that > > it will render us uncompatible with the linux or with linux > > apps. > > > > SOUND_PCM_SUBDIVIDE is really use for setting the buffer size and > > to provide multiple buffers. > > > > The sound driver generates N number of buffers based upon the size > > of its pool and the the size of a buffer. The intent is eliminate > > clicks. There is also buffering done on sound cards such as the > > right, I was mistaken... at a more careful reading the code seems > to generate a number of sub-buffers as you mention, and the > 'SUBDIVIDE' ioctl is only of use if one wants to force the driver > to split the available buffer space in more pieces than it would > do using the normal heuristics. In this view (and especially, now that > I understand _how_ it works), I can probably keep the current code. > > Note however that my idea was _not_ to kill the ioctl, just make it a > NOP. > > Cheers > Luigi > From owner-freebsd-multimedia Fri Jul 18 10:24:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA04437 for multimedia-outgoing; Fri, 18 Jul 1997 10:24:31 -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 KAA04430 for ; Fri, 18 Jul 1997 10:24:23 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id SAA17901; Fri, 18 Jul 1997 18:20:22 +0200 From: Luigi Rizzo Message-Id: <199707181620.SAA17901@labinfo.iet.unipi.it> Subject: Re: sound and dma ... To: hasty@rah.star-gate.com (Amancio Hasty) Date: Fri, 18 Jul 1997 18:20:22 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199707181630.JAA05399@rah.star-gate.com> from "Amancio Hasty" at Jul 18, 97 09:30:38 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > No problem;specially, since , the dma subsystem is so complex for > just playing audio --- I think is amazing . Hopefully, with PCI > things will get better because the complex buffering scheme is > really about reducing latency to the sound card. yes except all sound card I can find are ISA units... But this discussion on the double buffering problem has made me finally remember that I forgot to implement such a scheme in the "asc" driver (for scanner) and this is probably the reason why, in color mode, I occasionally lose samples :( Latest snap of the sound code (with sndstat working and initial support for multiple boards of the same type) at http://www.iet.unipi.it/~luigi/snd970718.tgz this includes a critical fix to "pnp.c" which was the reason why my card had a tendency to hang during the probe... I have a test machine with 1 PnP device (CS4232) and an old sound galaxy which probes as SoundBlaster 2.1: rizzo# cat /dev/sndstat FreeBSD Sound Driver Jul 18 1997 Installed drivers: pcm0: at 0x0240 irq 7 dma 1:0 pcm1: at 0x0220 irq 7 dma 1:0 rizzo# Cheers Luigi From owner-freebsd-multimedia Fri Jul 18 11:37:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA08691 for multimedia-outgoing; Fri, 18 Jul 1997 11:37:15 -0700 (PDT) Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id LAA08679; Fri, 18 Jul 1997 11:37:05 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-43.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA17421 (5.67b/IDA-1.5); Fri, 18 Jul 1997 20:36:55 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id UAA09874; Fri, 18 Jul 1997 20:36:45 +0200 (CEST) X-Face: " Date: Fri, 18 Jul 1997 20:36:44 +0200 From: Stefan Esser To: Bruce Evans Cc: hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, rhh@ct.picker.com, Stefan Esser Subject: Re: snd driver attach routine References: <199707141046.UAA02952@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707141046.UAA02952@godzilla.zeta.org.au>; from Bruce Evans on Mon, Jul 14, 1997 at 08:46:14PM +1000 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 14, Bruce Evans wrote: > >Problem: what should be the return type of *attach() routines ? > > Perhaps it should be void to match reality, but it currently must be > int for isa drivers to match the prototype in `struct isa_driver'. > > >The drivers in /sys/pci all return void for the attach routine. > > They have to, to match the prototype in `strcuct pci_driver'. I could easily change the return type of the PCI attach function. Should I ??? Regards, STefan From owner-freebsd-multimedia Fri Jul 18 15:41:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA20835 for multimedia-outgoing; Fri, 18 Jul 1997 15:41:04 -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 PAA20824 for ; Fri, 18 Jul 1997 15:40:57 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 18 Jul 1997 18:38:25 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA20877; Fri, 18 Jul 97 18:38:24 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA20149; Fri, 18 Jul 1997 18:36:18 -0400 Message-Id: <19970718183618.17735@ct.picker.com> Date: Fri, 18 Jul 1997 18:36:18 -0400 From: Randall Hopper To: Brian Campbell Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: guspnp10 References: <19970716222336.26139@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970716222336.26139@pobox.com>; from Brian Campbell on Wed, Jul 16, 1997 at 10:23:36PM -0400 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Brian Campbell: |I grabbed gugnp10 and installed it under my 2.2-STABLE system with |a GusMAX, SB16 and SCC-1. It detected each of these (although it |appears to detect the MAX as a PnP which the SB16 is). | |It failed to detect the FM chips however. Has anyone had their |OPL3 detected by this revision? Interesting. With pnp10, it finds the OPL on my SB32: /kernel.gus10: sndtable_probe(1) /kernel.gus10: installing card 4 /kernel.gus10: installed card 4 /kernel.gus10: Driver name 'OPL-2/OPL-3 FM' probe 0xf01e /kernel.gus10: Hardware probed OK /kernel.gus10: opl0 at 0x388 on isa /kernel.gus10: sndtable_init_card(1) entered /kernel.gus10: Located card - calling attach routine /kernel.gus10: Yamaha OPL3 FM> at 0x388 /kernel.gus10: attach routine finished ...though I have a non-PnP card, so maybe its related to that. Randall From owner-freebsd-multimedia Fri Jul 18 15:48:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA21245 for multimedia-outgoing; Fri, 18 Jul 1997 15:48:58 -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 PAA21239 for ; Fri, 18 Jul 1997 15:48:55 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 18 Jul 1997 18:47:52 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA20971; Fri, 18 Jul 97 18:47:52 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id SAA20159; Fri, 18 Jul 1997 18:45:46 -0400 Message-Id: <19970718184546.52607@ct.picker.com> Date: Fri, 18 Jul 1997 18:45:46 -0400 From: Randall Hopper To: Conrad Sabatier Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: Progress at last with AWE 64! References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Conrad Sabatier on Wed, Jul 16, 1997 at 10:19:43PM -0500 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk |Now, I just need a little advice on configuring the card. Anyone out there |who could tell me the proper settings for DRQ's with this thing? | |Here's what I'm using in my kernel: | |controller snd0 | |options SBC_IRQ=5 |device sb0 at isa? port 0x220 irq 5 conflicts drq 1 vector sbintr |device sbxvi0 at isa? port 0x220 irq 5 drq 5 conflicts |device sbmidi0 at isa? port 0x330 irq 5 conflicts |device opl3 at isa? port 0x388 |device awe0 at isa? port 0x620 irq 5 conflicts Glad to hear your having more success with this version. Kudos to Amancio and Luigi for their efforts! Here's what I use for my SB32. Packaged S/W and PnP aside, we have the same soundcard: controller snd0 device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 # Yamaha OPL-2/OPL-3 FM - for SB, SB Pro, SB16, PAS device opl0 at isa? port 0x388 device awe0 at isa? port 0x620 This is the default SB16 configuration. Just paste this as-is for starters. Also, if any other device is on irq 5, dma 5 or dma 1, try to move or disable it/them for now so you can get things up-and-running with the least resistance. |This is the closest I've come yet to getting this thing working. Success |is at hand! :-) Hope this helps! Randall From owner-freebsd-multimedia Fri Jul 18 16:37:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA23932 for multimedia-outgoing; Fri, 18 Jul 1997 16:37: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 QAA23923 for ; Fri, 18 Jul 1997 16:37:05 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Fri, 18 Jul 1997 19:35:38 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA21593; Fri, 18 Jul 97 19:35:37 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id TAA20242; Fri, 18 Jul 1997 19:33:25 -0400 Message-Id: <19970718193324.15928@ct.picker.com> Date: Fri, 18 Jul 1997 19:33:24 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: About the Sound Driver References: <199707151626.SAA12971@labinfo.iet.unipi.it> <199707151830.LAA02052@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707151830.LAA02052@rah.star-gate.com>; from Amancio Hasty on Tue, Jul 15, 1997 at 11:30:23AM -0700 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty: |From The Desk Of Luigi Rizzo : |> While you look at the sb things, randall was still having troubles |> recording from the sb16, and the error message (Interrupted system |> call) perhaps might be related to the recent inclusion of many checks |> for EINTR in the DMA code ? |I am not sure what Randall's problem is since I am able to record |from my SB16 thingy . Well, I am not entirely certain that it |records well since it is hard to check out the sound remote. Hmm, that's interesting. Just to make sure we're poking the sound driver the same way, I uploaded my simple DSP record/play utils to: ftp://rah.star-gate.com/pub/dsp-recplay.tgz If you would when you get a minute, please try: dsp-record -r 44100 -c 2 -b s16le -d 5 > RAW # Record for 5 seconds dsp-play -r 44100 -c 2 -b s16le < RAW I get EINTR on the first read() in dsp-record w/ guspnp10. Randall From owner-freebsd-multimedia Fri Jul 18 16:48:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24466 for multimedia-outgoing; Fri, 18 Jul 1997 16:48:00 -0700 (PDT) Received: from pobox.com (ott-on5-41.netcom.ca [207.181.91.105]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA24457 for ; Fri, 18 Jul 1997 16:47:46 -0700 (PDT) Received: (from brianc@localhost) by pobox.com (8.8.5/8.8.5) id TAA00259; Fri, 18 Jul 1997 19:46:04 -0400 (EDT) Message-ID: <19970718194558.54614@pobox.com> Date: Fri, 18 Jul 1997 19:45:58 -0400 From: Brian Campbell To: freebsd-multimedia@FreeBSD.org Subject: Re: guspnp10 References: <19970716222336.26139@pobox.com> <19970718183618.17735@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970718183618.17735@ct.picker.com>; from Randall Hopper on Fri, Jul 18, 1997 at 06:36:18PM -0400 Sender: owner-multimedia@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Fri, Jul 18, 1997 at 06:36:18PM -0400, Randall Hopper wrote: > Brian Campbell: > |It failed to detect the FM chips however. Has anyone had their > |OPL3 detected by this revision? > > Interesting. With pnp10, it finds the OPL on my SB32: > > /kernel.gus10: sndtable_probe(1) > /kernel.gus10: installing card 4 > /kernel.gus10: installed card 4 > /kernel.gus10: Driver name 'OPL-2/OPL-3 FM' probe 0xf01e > > /kernel.gus10: Hardware probed OK > /kernel.gus10: opl0 at 0x388 on isa > /kernel.gus10: sndtable_init_card(1) entered > /kernel.gus10: Located card - calling attach routine > /kernel.gus10: Yamaha OPL3 FM> at 0x388 > /kernel.gus10: attach routine finished Could be, I suppose. The sound sources from 2.2-stable still detect the OPL. It's also interesting that guspnp10 finds and assigns the various devices differently, and that the card config shows the FM chips as using IRQ 1 (I didn't think they used any IRQs). I guess I'll keep looking ... $ sdiff sndstat.{old,new} VoxWare Sound Driver:3.0-beta-950506 | VoxWare Sound Driver:3.5-alpha8-970706 Config options: ffffffff | Config options: 188090a Installed drivers: Installed drivers: Type 1: OPL-2/OPL-3 FM Type 1: OPL-2/OPL-3 FM Type 5: Roland MPU-401 Type 5: Roland MPU-401 Type 2: SoundBlaster Type 2: SoundBlaster Type 6: SoundBlaster16 Type 6: SoundBlaster16 Type 7: SB16 MIDI Type 7: SB16 MIDI Type 4: Gravis Ultrasound Type 4: Gravis Ultrasound Card config: Card config: SoundBlaster at 0x220 irq 5 drq 1 | SoundBlaster at 0x220 irq 5 drq 1,7 Roland MPU-401 at 0x330 irq 9 drq 0 | SoundBlaster16 at 0x220 irq 5 drq 5,7 SoundBlaster16 at 0x220 irq 5 drq 5 | SB16 MIDI at 0x300 irq 5 SB16 MIDI at 0x300 irq 5 drq 4294967295 | (OPL-2/OPL-3 FM at 0x388 irq 1) Gravis Ultrasound at 0x240 irq 11 drq 3 | Gravis Ultrasound at 0x240 irq 11 drq 3 OPL-2/OPL-3 FM at 0x388 irq 65535 drq 4 | Roland MPU-401 at 0x330 irq 9 drq 0,7 Audio devices: Audio devices: 0: SoundBlaster 16 4.13 0: SoundBlaster 16 4.13 1: Gravis UltraSound | 1: GUS PNP (CS4231) (DUPLEX) 2: GUS MAX (CS4231) | 2: Gravis UltraSound (DUPLEX) Synth devices: Synth devices: 0: Yamaha OPL-3 | 0: Gravis PNP (1024k) 1: Gravis UltraSound MAX (1024k) < Midi devices: Midi devices: 0: SoundBlaster 16 Midi 0: SoundBlaster 16 Midi 1: Gravis UltraSound Midi 1: Gravis UltraSound Midi 2: MPU-401 1.5B Midi interface #1 | 2: MPU-401 1.5U Midi interface #1 Timers: Timers: 0: System Timer | 0: System clock 1: OPL-3/GUS Timer | 1: GUS 2: MPU-401 Timer 2: MPU-401 Timer Mixers: Mixers: 0: SoundBlaster 0: SoundBlaster 1: Gravis Ultrasound | 1: AD1848/CS4248/CS4231 2: AD1848/CS4248/CS4231 | 2: Gravis Ultrasound From owner-freebsd-multimedia Fri Jul 18 17:18:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA25593 for multimedia-outgoing; Fri, 18 Jul 1997 17:18:40 -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 RAA25587; Fri, 18 Jul 1997 17:18:33 -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 RAA07293; Fri, 18 Jul 1997 17:18:20 -0700 (PDT) Message-Id: <199707190018.RAA07293@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Stefan Esser cc: Bruce Evans , luigi@labinfo.iet.unipi.it, hackers@freebsd.org, multimedia@freebsd.org, rhh@ct.picker.com Subject: Re: snd driver attach routine In-reply-to: Your message of "Fri, 18 Jul 1997 20:36:44 +0200." <19970718203644.04289@mi.uni-koeln.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Jul 1997 17:18:19 -0700 From: Amancio Hasty Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Well, we should be able to detect device specific failure and not allow access to the device driver that way our drivers don't have to handle a fatal low level device configuration . Amancio >From The Desk Of Stefan Esser : > On Jul 14, Bruce Evans wrote: > > >Problem: what should be the return type of *attach() routines ? > > > > Perhaps it should be void to match reality, but it currently must be > > int for isa drivers to match the prototype in `struct isa_driver'. > > > > >The drivers in /sys/pci all return void for the attach routine. > > > > They have to, to match the prototype in `strcuct pci_driver'. > > I could easily change the return type of > the PCI attach function. Should I ??? > > Regards, STefan From owner-freebsd-multimedia Fri Jul 18 22:19:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA07731 for multimedia-outgoing; Fri, 18 Jul 1997 22:19:58 -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 WAA07723; Fri, 18 Jul 1997 22:19:48 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA18529; Sat, 19 Jul 1997 06:16:45 +0200 From: Luigi Rizzo Message-Id: <199707190416.GAA18529@labinfo.iet.unipi.it> Subject: Re: snd driver attach routine To: hasty@rah.star-gate.com (Amancio Hasty) Date: Sat, 19 Jul 1997 06:16:45 +0200 (MET DST) Cc: se@FreeBSD.ORG, bde@zeta.org.au, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, rhh@ct.picker.com In-Reply-To: <199707190018.RAA07293@rah.star-gate.com> from "Amancio Hasty" at Jul 18, 97 05:18:00 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Well, we should be able to detect device specific failure and > not allow access to the device driver that way our drivers don't > have to handle a fatal low level device configuration . I think I get the rationale for not testing return value in the attach routine. After the probe you (should) know that the peripheral is there. A failure to attach should then depend only on os problems (typically, failure to allocate resources such as memory, dma, irq, or a device descriptor). Since no resource allocation was in the probe, the routine calling the attach has nothing to do on failure -- all deallocations should be done in the attach routine being device specific. Secondly, if I am not mistaken, once you create a device entry in the fs with a major number corresponding to an existing device, the routines for the devices are always invoked and they have to check the minor dev anyways to see if it corresponds to a configured device. So basically I think that it is ok to have the attach routine to return void for all buses (which means that, if something has to be changed, is the attach for isa drivers). Cheers Luigi > >From The Desk Of Stefan Esser : > > On Jul 14, Bruce Evans wrote: > > > >Problem: what should be the return type of *attach() routines ? > > > > > > Perhaps it should be void to match reality, but it currently must be > > > int for isa drivers to match the prototype in `struct isa_driver'. > > > > > > >The drivers in /sys/pci all return void for the attach routine. > > > > > > They have to, to match the prototype in `strcuct pci_driver'. > > > > I could easily change the return type of > > the PCI attach function. Should I ??? > > > > Regards, STefan -----------------------------+-------------------------------------- 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 Jul 18 23:48:33 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA10949 for multimedia-outgoing; Fri, 18 Jul 1997 23:48:33 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id XAA10942; Fri, 18 Jul 1997 23:48:25 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id QAA29949; Sat, 19 Jul 1997 16:43:32 +1000 Date: Sat, 19 Jul 1997 16:43:32 +1000 From: Bruce Evans Message-Id: <199707190643.QAA29949@godzilla.zeta.org.au> To: hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it Subject: Re: snd driver attach routine Cc: bde@zeta.org.au, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, rhh@ct.picker.com, se@FreeBSD.ORG Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >I think I get the rationale for not testing return value in the attach >routine. > >After the probe you (should) know that the peripheral is there. A >failure to attach should then depend only on os problems (typically, >failure to allocate resources such as memory, dma, irq, or a device >descriptor). Since no resource allocation was in the probe, the routine >calling the attach has nothing to do on failure -- all deallocations >should be done in the attach routine being device specific. In practice, for isa devices the IRQ allocation is done in generic code, so the probe status is necessary (but not used). >Secondly, if I am not mistaken, once you create a device entry in the >fs with a major number corresponding to an existing device, the >routines for the devices are always invoked and they have to check the >minor dev anyways to see if it corresponds to a configured device. This is a bug. Drivers whose probe or attach can fail should not use SYSINIT() to register their device switches. Bruce From owner-freebsd-multimedia Sat Jul 19 04:52:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA21799 for multimedia-outgoing; Sat, 19 Jul 1997 04:52:02 -0700 (PDT) Received: from Hydro.CAM.ORG (Hydro.CAM.ORG [198.168.100.7]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA21742; Sat, 19 Jul 1997 04:51:51 -0700 (PDT) Received: from 1 (DynamicPPP-193.HIP.CAM.ORG [205.151.119.193]) by Hydro.CAM.ORG (8.8.4/8.8.4) with ESMTP id HAA18548; Sat, 19 Jul 1997 07:51:42 -0400 (EDT) Message-ID: <33D0AA62.56ED3612@coproductions.com> Date: Sat, 19 Jul 1997 07:52:02 -0400 From: Jean-Marc Felio Reply-To: Reply-to-Felio@coproductions.com X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: Ragan Slawomir CC: "\"'freebsd-bugs@freebsd.org'\"" , "freebsd-chat@FreeBSD.ORG" , "freebsd-current@FreeBSD.ORG" , "freebsd-multimedia@FreeBSD.ORG" , "freebsd-questions@FreeBSD.ORG" , "hackers@FreeBSD.ORG" , "owner-hackers@FreeBSD.ORG" , "questions@FreeBSD.ORG" , freebsd-bugs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, "\"freebsd-chat@FreeBSD.ORG\"" , "\"freebsd-current@FreeBSD.ORG\"" , freebsd-multimedia@FreeBSD.ORG Subject: unsubscribe X-Priority: 3 (Normal) References: <9707171549.ZM21695@liza.trier.fh-rpl.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk unsubscribe From owner-freebsd-multimedia Sat Jul 19 05:53:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA24531 for multimedia-outgoing; Sat, 19 Jul 1997 05:53:47 -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 FAA24521; Sat, 19 Jul 1997 05:53:39 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id NAA18801; Sat, 19 Jul 1997 13:46:57 +0200 From: Luigi Rizzo Message-Id: <199707191146.NAA18801@labinfo.iet.unipi.it> Subject: Re: snd driver attach routine To: bde@zeta.org.au (Bruce Evans) Date: Sat, 19 Jul 1997 13:46:57 +0200 (MET DST) Cc: hasty@rah.star-gate.com, bde@zeta.org.au, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, rhh@ct.picker.com, se@FreeBSD.ORG In-Reply-To: <199707190643.QAA29949@godzilla.zeta.org.au> from "Bruce Evans" at Jul 19, 97 04:43:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >I think I get the rationale for not testing return value in the attach > >routine. > > > >After the probe you (should) know that the peripheral is there. A > >failure to attach should then depend only on os problems (typically, > >failure to allocate resources such as memory, dma, irq, or a device > >descriptor). Since no resource allocation was in the probe, the routine > >calling the attach has nothing to do on failure -- all deallocations > >should be done in the attach routine being device specific. > > In practice, for isa devices the IRQ allocation is done in generic code, > so the probe status is necessary (but not used). ^^^^^ you mean attach I guess... but in isa.c I see the following piece of code: ... isdp->id_alive = id_alive; } (*dp->attach)(isdp); if (isdp->id_irq) { if (mp) INTRMASK(*mp, isdp->id_irq); register_intr(ffs(isdp->id_irq) - 1, isdp->id_id, isdp->id_ri_flags, isdp->id_intr, mp, isdp->id_unit); INTREN(isdp->id_irq); } ... so all the necessary info is in the id_irq field of the struct isa_device -- a device which does not attach properly could just zero this field. > >Secondly, if I am not mistaken, once you create a device entry in the > >fs with a major number corresponding to an existing device, the > >routines for the devices are always invoked and they have to check the > >minor dev anyways to see if it corresponds to a configured device. > > This is a bug. Drivers whose probe or attach can fail should not use > SYSINIT() to register their device switches. it is not a bug, it is a need. A device switch (registered with SYSINIT) serves for a device _type_, but you can have several units of the same type (hence with the same major number), so you have to check the minor number anyways. 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 Sat Jul 19 07:36:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA27781 for multimedia-outgoing; Sat, 19 Jul 1997 07:36:59 -0700 (PDT) Received: from prova.iet.unipi.it (prova1.iet.unipi.it [131.114.9.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id HAA27773; Sat, 19 Jul 1997 07:36:50 -0700 (PDT) Received: (from luigi@localhost) by prova.iet.unipi.it (8.8.5/8.8.5) id QAA01053; Sat, 19 Jul 1997 16:37:50 +0200 (CEST) From: Luigi Rizzo Message-Id: <199707191437.QAA01053@prova.iet.unipi.it> Subject: dma handling in the sound driver To: hackers@freebsd.org, multimedia@freebsd.org Date: Sat, 19 Jul 1997 16:37:50 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL31 (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 I have planned to rewrite the dma buffer handling routines for the sound driver as follows. To me this seems reasonably simple and efficient. Can you please have a look at this high-level description of the problem (including some pseudo-code, very close to the actual implementation) and tell if this looks reasonable ? (this description will also go into the source files, so hopefully people will not have a hard time in understanding how it works...) Thanks Luigi ------- The main problem with the DMA in the sound driver is to avoid that the flow of data from/to the codec is interrupted, resulting in missing samples or clicks. The problem is dealt with at several levels. 1) within the sound card, there is some amount of buffering (e.g. a FIFO, or on-board memory, etc.) so as to overcome occasional periods when the user process is slow. 2) some amount of buffering must be supplied in the driver as well, for those boards (many) which do not have enough buffering. Even in presence of buffering, there might be problems when the current DMA operation terminates and a new one is restarted. In fact: - if we use a single DMA buffer, we need the time to refill it before starting the next op. The largest the buffer (and the size of the block being transferred), the longest is the idle time; - with two DMA buffers, we can refill one buffer while the other one is in use by the DMA engine. We can still have troubles if we start a long refill near the end of operation of DMA on the other buffer, but this problem can be minimized (but not avoided; if we are late, we are late, no matter how many buffers we have!) In our implementation, we use a single memory block structured as three logical, variable-size, buffers: one in use by the dma engine, the next one ready for use by the dma (already filled up), the last one free for refills. dp,dl rp,rl fp,fl +-------+-------------+---------------+------+ | free | used by dma | ready for use | free | +-------+-------------+---------------+------+ Both the "ready" and "free" areas can wrap around the end of the buffer. The "dma" are Three pointers (dp, rp, fp) and three length (dl, rl, fl) are used for the purpose. At initialization: dp = rp = fp = 0 ; /* beginning of buffer */ dl = 0 ; /* meaning no dma activity) */ rl = 0 ; /* meaning no data ready */ fl = bufsize ; Upon dma_interrupt(), we try to use the next buffer if possible: s=splhigh(); fl += dl ; dp = rp ; dl = 0 ; if (rl > 0) { dl = min(rl, bufsize - rp ) ; /* do not wrap */ rl -= dl ; rp += dl ; if (rp == bufsize) rp = 0; /* * now try to avoid too small dma transfers in the near future. * This can happen if I let rp start too close to the end of * the buffer. If this happens, and have enough data, try to * split the available block in two approx. equal parts. */ if (bufsize - rp < MIN_DMA_SIZE && bufsize - dp > 2*MIN_DMA_SIZE) { dl = (bufsize - dp) / 2; rl += (rp - (dp + dl) ) ; rp = dp + dl ; } restart_dma(); } splx(s) Upon user_write() for n bytes we copy data into the free buffer and then extend the ready block. Instead of doing all the copy at once, we start with small pieces in order to minimize the chance of a starvation. The size of the smallest chunk is chosen in a way that the execution time of uiomove is still dominated by the constant part. bsz = 64 ; /* min block size */ while (n>0) { int l = min (n, bsz); l = min (l, fl); l = min (l, bufsize - fp ); uiomove(buf, .. , l); s=splhigh(); rl += l ; fl -= l ; fp += l ; if (fp == bufsize) fp = 0 ; if (rl == l) { dl = rl ; restart_dma(); } splx(s); if (fl == 0) { /* buffer full, must sleep */ tsleep( ... ); /* handle errors etc. */ } bsz = min(bufsize, bsz*2); } ==================================================================== 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 Sat Jul 19 11:45:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA06912 for multimedia-outgoing; Sat, 19 Jul 1997 11:45:30 -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 LAA06907; Sat, 19 Jul 1997 11:45:26 -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 LAA17575; Sat, 19 Jul 1997 11:45:07 -0700 (PDT) Message-Id: <199707191845.LAA17575@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver In-reply-to: Your message of "Sat, 19 Jul 1997 16:37:50 +0200." <199707191437.QAA01053@prova.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 11:45:06 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Lets take a case example the dma algorithm from the current sound driver for the SB16 dmabuf splits a pool of continous memory into N buffers where each buffer can hold upto a 1/2 second. auto dma is chosen. In the case of playing sun style au files recorded at 8khz , the size of a buffer is 4096 , 1/2 seconds worth. The dma auto init pool size is taken from a sound driver constant which is usually a multiple of 4k for our example the dma auto init buffer is 32k. A high level audio write routine whose buffer count usually is a bigger than 32k , breaks up the the write request in 4096 bytes buffers. The sound card loops on its auto init dma buffer as well as the sound driver's dma buffer routines. Cheers, Amancio >From The Desk Of Luigi Rizzo : > I have planned to rewrite the dma buffer handling routines for > the sound driver as follows. > > To me this seems reasonably simple and efficient. Can you please > have a look at this high-level description of the problem (including some > pseudo-code, very close to the actual implementation) and tell if this > looks reasonable ? > > (this description will also go into the source files, so hopefully > people will not have a hard time in understanding how it works...) > > Thanks > Luigi > > ------- > > > The main problem with the DMA in the sound driver is to avoid that the > flow of data from/to the codec is interrupted, resulting in missing > samples or clicks. The problem is dealt with at several levels. > > 1) within the sound card, there is some amount of buffering (e.g. a > FIFO, or on-board memory, etc.) so as to overcome occasional > periods when the user process is slow. > > 2) some amount of buffering must be supplied in the driver as well, > for those boards (many) which do not have enough buffering. > > Even in presence of buffering, there might be problems when the > current DMA operation terminates and a new one is restarted. In fact: > - if we use a single DMA buffer, we need the time to refill it before > starting the next op. The largest the buffer (and the size of the > block being transferred), the longest is the idle time; > - with two DMA buffers, we can refill one buffer while the other one > is in use by the DMA engine. We can still have troubles if we start > a long refill near the end of operation of DMA on the other buffer, > but this problem can be minimized (but not avoided; if we are late, > we are late, no matter how many buffers we have!) > > In our implementation, we use a single memory block structured as > three logical, variable-size, buffers: one in use by the dma engine, > the next one ready for use by the dma (already filled up), the last > one free for refills. > > dp,dl rp,rl fp,fl > +-------+-------------+---------------+------+ > | free | used by dma | ready for use | free | > +-------+-------------+---------------+------+ > > Both the "ready" and "free" areas can wrap around the end of the > buffer. The "dma" are > > Three pointers (dp, rp, fp) and three length (dl, rl, fl) are used for > the purpose. > > At initialization: > dp = rp = fp = 0 ; /* beginning of buffer */ > dl = 0 ; /* meaning no dma activity) */ > rl = 0 ; /* meaning no data ready */ > fl = bufsize ; > > Upon dma_interrupt(), we try to use the next buffer if possible: > > s=splhigh(); > fl += dl ; > dp = rp ; > dl = 0 ; > if (rl > 0) { > dl = min(rl, bufsize - rp ) ; /* do not wrap */ > rl -= dl ; > rp += dl ; > if (rp == bufsize) rp = 0; > /* > * now try to avoid too small dma transfers in the near future. > * This can happen if I let rp start too close to the end of > * the buffer. If this happens, and have enough data, try to > * split the available block in two approx. equal parts. > */ > if (bufsize - rp < MIN_DMA_SIZE && bufsize - dp > 2*MIN_DMA_SIZE) { > dl = (bufsize - dp) / 2; > rl += (rp - (dp + dl) ) ; > rp = dp + dl ; > } > restart_dma(); > } > splx(s) > > Upon user_write() for n bytes we copy data into the free buffer and > then extend the ready block. Instead of doing all the copy at once, we > start with small pieces in order to minimize the chance of a > starvation. The size of the smallest chunk is chosen in a way that the > execution time of uiomove is still dominated by the constant part. > > bsz = 64 ; /* min block size */ > while (n>0) { > int l = min (n, bsz); > l = min (l, fl); > l = min (l, bufsize - fp ); > uiomove(buf, .. , l); > s=splhigh(); > rl += l ; > fl -= l ; > fp += l ; > if (fp == bufsize) fp = 0 ; > if (rl == l) { > dl = rl ; > restart_dma(); > } > splx(s); > if (fl == 0) { /* buffer full, must sleep */ > tsleep( ... ); > /* handle errors etc. */ > } > bsz = min(bufsize, bsz*2); > } > > ==================================================================== > 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 Sat Jul 19 16:15:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA16459 for multimedia-outgoing; Sat, 19 Jul 1997 16:15:51 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16454 for ; Sat, 19 Jul 1997 16:15:49 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id QAA18203 for ; Sat, 19 Jul 1997 16:15:47 -0700 (PDT) Date: Sat, 19 Jul 1997 16:15:47 -0700 (PDT) From: "J. Utz" To: multimedia@FreeBSD.ORG Subject: 970714 configure.c the formatting is making me crazy! In-Reply-To: <199707181620.SAA17901@labinfo.iet.unipi.it> 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 am messing with configure.c in the 970714 sound snap because the 970718 version doesn't have a configure.c the conditionals are full tab indents, which means that the lines in the really important part are totally messed up in 80 columns in emacs! arghh! is there some magic emacs command that fixes this stuff automatically? I am trying to figure out why configure ( which asks questions about configuring a maui card ) doesn't ever configure the dang thing ( atleast as far as looking at local.h is concerned... i noticed at line 494 there is an open curly brace just sitting there all by itself, then, at line 501 there is a for loop with no open curly brace! printf("/*\tGenerated by configure. Don't edit!!!!\t*/\n"); printf("/*\tMaking changes to this file is not as simple as it may look.\t*/\n\n"); { /* * Partial driver */ full_driver = 0; for (i = 0; i <= OPT_LAST; i++) if (can_select_option(i)) { the formatting is making it impossible for me to figure out what is going on, so i am going thru the whole thing and shorting up the indents by hand, great way to explore code, but sort of irritating... is that lonely curly brace supposed to be there? tnx! john ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 16:22:44 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA16743 for multimedia-outgoing; Sat, 19 Jul 1997 16:22:44 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA16738 for ; Sat, 19 Jul 1997 16:22:40 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id QAA17822 for ; Sat, 19 Jul 1997 16:22:39 -0700 (PDT) Date: Sat, 19 Jul 1997 16:22:39 -0700 (PDT) From: "J. Utz" To: multimedia@freebsd.org Subject: what does local.h do? 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; local.h never seems to get written with the correct data, but /etc/soundconf does. what is the purpose of local.h? i just noticed that the config data appears to be properly written to the file /etc/soudconf. Is this what the soundriver actually looks at when it probes? this would be interesting because i am compiling the kernel for my soundcard machine on a different machine ( downstairs is a 486 with the soundcards, mira is a fake pentium that is a much nicer place to build kernels ). I cant believe that the driver uses /etc/soundconf to probe because it is finding the cards on downstairs even tho i have never copied over the /etc/soundconf from mira..... what do u guys know? tnx! john ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 16:42:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17539 for multimedia-outgoing; Sat, 19 Jul 1997 16:42:10 -0700 (PDT) Received: from Ilsa.StevesCafe.com (Ilsa.StevesCafe.com [205.168.119.129]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA17534 for ; Sat, 19 Jul 1997 16:42:07 -0700 (PDT) Received: from Ilsa.StevesCafe.com (localhost [127.0.0.1]) by Ilsa.StevesCafe.com (8.8.6/8.8.5) with ESMTP id RAA27696; Sat, 19 Jul 1997 17:41:34 -0600 (MDT) Message-Id: <199707192341.RAA27696@Ilsa.StevesCafe.com> X-Mailer: exmh version 2.0gamma 1/27/96 From: Steve Passe To: "J. Utz" cc: multimedia@FreeBSD.ORG Subject: Re: 970714 configure.c the formatting is making me crazy! In-reply-to: Your message of "Sat, 19 Jul 1997 16:15:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 17:41:34 -0600 Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, > i am messing with configure.c in the 970714 sound snap because the 970718 > version doesn't have a configure.c > > the conditionals are full tab indents, which means that the lines in the > really important part are totally messed up in 80 columns in emacs! arghh! > is there some magic emacs command that fixes this stuff automatically? don't go crazy reformting source, the style police will just make you change it back before its allowwed in the tree. from "man style": NAME style - Kernel source file style guide ... Indentation is an 8 character tab. Second level indents are four spaces. while (cnt < 20) z = a + really + long + statement + that + needs + two lines + gets + indented + four + spaces + on + the + second + and + subsequent + lines. Do not add whitespace at the end of a line, and only use tabs then spaces to form the indentation. Do not use more spaces than a tab will produce and do not use spaces in front of tabs. -- Steve Passe | powered by smp@csn.net | Symmetric MultiProcessor FreeBSD From owner-freebsd-multimedia Sat Jul 19 16:46:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17716 for multimedia-outgoing; Sat, 19 Jul 1997 16:46:35 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA17711 for ; Sat, 19 Jul 1997 16:46:34 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id QAA18197 for ; Sat, 19 Jul 1997 16:46:32 -0700 (PDT) Date: Sat, 19 Jul 1997 16:46:32 -0700 (PDT) From: "J. Utz" To: multimedia@FreeBSD.ORG Subject: help? extra braces in configure.c!!!???!!! 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 ok, look at this and tell me what u think. i cant believe this works as intended! the opening bare brace is matched by a closing bare brace, but what the hell? the for loop should execute the next line, but the next "line" is a big if thingy! what goes on? i think that the "big if thingy" is a "line" since it is curly bracket, but, man, that is hard to follow! opinions? { /* * Partial driver */ full_driver = 0; for (i = 0; i <= OPT_LAST; i++) if (can_select_option(i)) { if (!(selected_options & B(i))) /* Not selected yet */ if (!hw_table[i].verify) { if (hw_table[i].alias) selected_options |= B(hw_table[i].alias); else selected_options |= B(i); } else { int def_answ = hw_table[i].default_answ; fprintf(stderr, def_answ ? "%s (y/n) ? " : " %s (n/y) ? ", questions[i]); if (think_positively(def_answ)) if (hw_table[i].alias) selected_options |= B(hw_table[i].alias); else selected_options |= B(i); } } } ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 16:53:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA17934 for multimedia-outgoing; Sat, 19 Jul 1997 16:53:11 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA17929 for ; Sat, 19 Jul 1997 16:53:08 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id QAA18646; Sat, 19 Jul 1997 16:53:05 -0700 (PDT) Date: Sat, 19 Jul 1997 16:53:05 -0700 (PDT) From: "J. Utz" To: Steve Passe cc: multimedia@FreeBSD.ORG Subject: Re: 970714 configure.c the formatting is making me crazy! In-Reply-To: <199707192341.RAA27696@Ilsa.StevesCafe.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 Hi steve; i think that if it followed style police guidelines, that would be an improvement, all indents are tabs, no 4char indents to be found, methinks! this isn't really for commit purposes, this is for comprehension purposes, so i am probably stuck doing this and then just keeping it around as a reference...well commented beasty that it is (not!) On Sat, 19 Jul 1997, Steve Passe wrote: > Hi, > > > i am messing with configure.c in the 970714 sound snap because the 970718 > > version doesn't have a configure.c > > > > the conditionals are full tab indents, which means that the lines in the > > really important part are totally messed up in 80 columns in emacs! arghh! > > is there some magic emacs command that fixes this stuff automatically? > > don't go crazy reformting source, the style police will just make you change it > back before its allowwed in the tree. > -- > Steve Passe | powered by > smp@csn.net | Symmetric MultiProcessor FreeBSD ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 17:27:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA19151 for multimedia-outgoing; Sat, 19 Jul 1997 17:27:54 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA19143 for ; Sat, 19 Jul 1997 17:27:49 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id RAA19323 for ; Sat, 19 Jul 1997 17:27:47 -0700 (PDT) Date: Sat, 19 Jul 1997 17:27:47 -0700 (PDT) From: "J. Utz" To: multimedia@freebsd.org Subject: loading "Operating system" into maui card Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk me again, in "wife-out-of-town-total-obsessional-mode" :-). what happens with this "compiled in to the kernel with bin to hex stuff?" the maui has an o/s that has to get downloaded to it via a dos app called "setupsnd". would this be analagous to the way these other cards like the logitech soundman and other mandatory download cards work? fwiw, the maui actually has a 68020 or 68030 on it, i forget which one... i guess what i am asking is: should i just grab some working code from one of the other soundcards and just try to stuff it in? tnx! ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 18:00:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20096 for multimedia-outgoing; Sat, 19 Jul 1997 18:00: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 SAA20091 for ; Sat, 19 Jul 1997 18:00: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 SAA00361; Sat, 19 Jul 1997 18:00:32 -0700 (PDT) Message-Id: <199707200100.SAA00361@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "J. Utz" cc: multimedia@FreeBSD.ORG Subject: Re: loading "Operating system" into maui card In-reply-to: Your message of "Sat, 19 Jul 1997 17:27:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 18:00:32 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Just try stuff out with your maui . Try to figure out if its default mode is SB or emulates some other card. >From your description, it is kind of hard to setup your card because you need a bootloader to download a program to the card then to kick off the program in the sound card. Try to figure as much as you can from the dos or windows about its configuration , IRQ, DMA type of emulation if any ... Cheers, Amancio >From The Desk Of "J. Utz" : > me again, in "wife-out-of-town-total-obsessional-mode" :-). > > what happens with this "compiled in to the kernel with bin to hex stuff?" > > the maui has an o/s that has to get downloaded to it via a dos app called > "setupsnd". would this be analagous to the way these other cards like the > logitech soundman and other mandatory download cards work? > > fwiw, the maui actually has a 68020 or 68030 on it, i forget which one... > > i guess what i am asking is: should i just grab some working code from one > of the other soundcards and just try to stuff it in? > > tnx! > > ***************************************************************************** ** > John Utz spaz@u.washington.edu > idiocy is the impulse function in the convolution of life > From owner-freebsd-multimedia Sat Jul 19 18:02:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20137 for multimedia-outgoing; Sat, 19 Jul 1997 18:02: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 SAA20131 for ; Sat, 19 Jul 1997 18:02: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 SAA00400; Sat, 19 Jul 1997 18:02:42 -0700 (PDT) Message-Id: <199707200102.SAA00400@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "J. Utz" cc: multimedia@FreeBSD.ORG Subject: Re: 970714 configure.c the formatting is making me crazy! In-reply-to: Your message of "Sat, 19 Jul 1997 16:15:47 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 18:02:42 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We don't use configure.c . The purpose of local.h is to provide a set of default values for popular sound cards which can be overriden at boot time and it has a couple of sound card constants such as dsp buffer size. Amancio >From The Desk Of "J. Utz" : > Hi; > > i am messing with configure.c in the 970714 sound snap because the 970718 > version doesn't have a configure.c > > the conditionals are full tab indents, which means that the lines in the > really important part are totally messed up in 80 columns in emacs! arghh! > is there some magic emacs command that fixes this stuff automatically? > > I am trying to figure out why configure ( which asks questions about > configuring a maui card ) doesn't ever configure the dang thing ( atleast > as far as looking at local.h is concerned... > > i noticed at line 494 there is an open curly brace just sitting there all > by itself, then, at line 501 there is a for loop with no open curly brace! > > printf("/*\tGenerated by configure. Don't edit!!!!\t*/\n"); > printf("/*\tMaking changes to this file is not as simple as it may > look.\t*/\n\n"); > > { > /* > * Partial driver > */ > > full_driver = 0; > > for (i = 0; i <= OPT_LAST; i++) > if (can_select_option(i)) { > > > the formatting is making it impossible for me to figure out what is going > on, so i am going thru the whole thing and shorting up the indents by > hand, great way to explore code, but sort of irritating... > > is that lonely curly brace supposed to be there? > > tnx! > > john > > ***************************************************************************** ** > John Utz spaz@u.washington.edu > idiocy is the impulse function in the convolution of life > From owner-freebsd-multimedia Sat Jul 19 18:11:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20532 for multimedia-outgoing; Sat, 19 Jul 1997 18:11:43 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20525 for ; Sat, 19 Jul 1997 18:11:34 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id SAA20154 for ; Sat, 19 Jul 1997 18:11:33 -0700 (PDT) Date: Sat, 19 Jul 1997 18:11:33 -0700 (PDT) From: "J. Utz" To: multimedia@freebsd.org Subject: README.LUIGI how would this work specifically? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk OK; from README.LUIGI: device pcmX at isa ? port? tty irq N drq D flags F vector pcmintr device midiX at isa ? port? tty flags F device synthX at isa ? port? tty flags F ok, to have a self centered, concrete example: i have a PAS-16, it has a pseudo-midi port ( non mpu401 ), it has a 8bit soundblaster on it, it has an opl3 on it, and it has it's own little Mediavision PAS-16 chip. i have a turtle beach maui, it is a wavetable synthesizer, and it is accessed via the midi port as near as i can figure. it has a true midi mpu401 interface. but it has a synthesizer. ok, now how would i split these guys up into the 3 categories? tnx! john ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 18:22:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA20951 for multimedia-outgoing; Sat, 19 Jul 1997 18:22:08 -0700 (PDT) Received: from becker1.u.washington.edu (spaz@becker1.u.washington.edu [140.142.12.67]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA20946 for ; Sat, 19 Jul 1997 18:22:04 -0700 (PDT) Received: from localhost (spaz@localhost) by becker1.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id SAA18865 for ; Sat, 19 Jul 1997 18:22:03 -0700 (PDT) Date: Sat, 19 Jul 1997 18:22:03 -0700 (PDT) From: "J. Utz" To: multimedia@freebsd.org Subject: can we use uss/lite source code? 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 found a maui.c on a maui homepage ca we use it? here is the copywrite block at the top of the file. i wont print the whole file in case it might be illegal! looks like gpl to me, is that not something we want to use? /* * Copyright (C) by Hannu Savolainen 1993-1996 * * USS/Lite for Linux is distributed under the GNU GENERAL PUBLIC LICENSE (GPL) * Version 2 (June 1991). See the "COPYING" file distributed with this software * for more info. */ ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 19:01:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22357 for multimedia-outgoing; Sat, 19 Jul 1997 19:01:05 -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 TAA22349 for ; Sat, 19 Jul 1997 19:00:58 -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 TAA00462; Sat, 19 Jul 1997 19:00:54 -0700 (PDT) Message-Id: <199707200200.TAA00462@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "J. Utz" cc: multimedia@FreeBSD.ORG Subject: Re: can we use uss/lite source code? In-reply-to: Your message of "Sat, 19 Jul 1997 18:22:03 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 19:00:54 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Just ask Hannu .... Amancio >From The Desk Of "J. Utz" : > Hi; > > i found a maui.c on a maui homepage ca we use it? here is the copywrite > block at the top of the file. i wont print the whole file in case it might > be illegal! > > > looks like gpl to me, is that not something we want to use? > > /* > * Copyright (C) by Hannu Savolainen 1993-1996 > * > * USS/Lite for Linux is distributed under the GNU GENERAL PUBLIC LICENSE > (GPL) > * Version 2 (June 1991). See the "COPYING" file distributed with this > software > * for more info. > */ > > > > ***************************************************************************** ** > John Utz spaz@u.washington.edu > idiocy is the impulse function in the convolution of life > From owner-freebsd-multimedia Sat Jul 19 19:02:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA22402 for multimedia-outgoing; Sat, 19 Jul 1997 19:02:54 -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 TAA22391 for ; Sat, 19 Jul 1997 19:02:44 -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 TAA00480; Sat, 19 Jul 1997 19:02:39 -0700 (PDT) Message-Id: <199707200202.TAA00480@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "J. Utz" cc: multimedia@FreeBSD.ORG Subject: Re: help? extra braces in configure.c!!!???!!! In-reply-to: Your message of "Sat, 19 Jul 1997 16:46:32 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 19:02:39 -0700 From: Amancio Hasty Sender: owner-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We don't use configure.c and will be removed from the sound driver distribution. Amancio >From The Desk Of "J. Utz" : > ok, look at this and tell me what u think. i cant believe this works as > intended! > > the opening bare brace is matched by a closing bare brace, but what the > hell? the for loop should execute the next line, but the next "line" is a > big if thingy! what goes on? i think that the "big if thingy" is a "line" > since it is curly bracket, but, man, that is hard to follow! > > opinions? > > { > /* > * Partial driver > */ > > full_driver = 0; > > for (i = 0; i <= OPT_LAST; i++) > if (can_select_option(i)) { > if (!(selected_options & B(i))) /* Not selected yet */ > if (!hw_table[i].verify) { > if (hw_table[i].alias) > selected_options |= B(hw_table[i].alias); > else > selected_options |= B(i); > } > else { > int def_answ = hw_table[i].default_answ; > fprintf(stderr, def_answ ? "%s (y/n) ? " : " %s (n/y) ? ", > questions[i]); > if (think_positively(def_answ)) > if (hw_table[i].alias) > selected_options |= B(hw_table[i].alias); > else > selected_options |= B(i); > } > } > } > > > ***************************************************************************** ** > John Utz spaz@u.washington.edu > idiocy is the impulse function in the convolution of life > From owner-freebsd-multimedia Sat Jul 19 19:26:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA23255 for multimedia-outgoing; Sat, 19 Jul 1997 19:26:55 -0700 (PDT) Received: from becker2.u.washington.edu (spaz@becker2.u.washington.edu [140.142.12.68]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA23250 for ; Sat, 19 Jul 1997 19:26:53 -0700 (PDT) Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id TAA04855; Sat, 19 Jul 1997 19:26:49 -0700 (PDT) Date: Sat, 19 Jul 1997 19:26:48 -0700 (PDT) From: "J. Utz" To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: can we use uss/lite source code? In-Reply-To: <199707200200.TAA00462@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 Are u being facetious? or do u mean that seriously? anybody have an email address? the os download code is in the file! On Sat, 19 Jul 1997, Amancio Hasty wrote: > Just ask Hannu .... > > Amancio > > From The Desk Of "J. Utz" : > > Hi; > > > > i found a maui.c on a maui homepage ca we use it? here is the copywrite > > block at the top of the file. i wont print the whole file in case it might > > be illegal! > > > > > > looks like gpl to me, is that not something we want to use? > > > > /* > > * Copyright (C) by Hannu Savolainen 1993-1996 > > * > > * USS/Lite for Linux is distributed under the GNU GENERAL PUBLIC LICENSE > > (GPL) > > * Version 2 (June 1991). See the "COPYING" file distributed with this > > software > > * for more info. > > */ > > > > > > > > ***************************************************************************** > ** > > John Utz spaz@u.washington.edu > > idiocy is the impulse function in the convolution of life > > > > > ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life From owner-freebsd-multimedia Sat Jul 19 19:46:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA24280 for multimedia-outgoing; Sat, 19 Jul 1997 19:46: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 TAA24275 for ; Sat, 19 Jul 1997 19:46: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 TAA00817; Sat, 19 Jul 1997 19:45:56 -0700 (PDT) Message-Id: <199707200245.TAA00817@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "J. Utz" cc: multimedia@FreeBSD.ORG Subject: Re: can we use uss/lite source code? In-reply-to: Your message of "Sat, 19 Jul 1997 19:26:48 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 19 Jul 1997 19:45:56 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Again, ask Hannu if it is okay to use his file... the oss web page should have an email address. Amancio >From The Desk Of "J. Utz" : > Are u being facetious? > > or do u mean that seriously? > > anybody have an email address? > > the os download code is in the file! > > On Sat, 19 Jul 1997, Amancio Hasty wrote: > > > Just ask Hannu .... > > > > Amancio > > > > From The Desk Of "J. Utz" : > > > Hi; > > > > > > i found a maui.c on a maui homepage ca we use it? here is the copywrite > > > block at the top of the file. i wont print the whole file in case it migh t > > > be illegal! > > > > > > > > > looks like gpl to me, is that not something we want to use? > > > > > > /* > > > * Copyright (C) by Hannu Savolainen 1993-1996 > > > * > > > * USS/Lite for Linux is distributed under the GNU GENERAL PUBLIC LICENSE > > > (GPL) > > > * Version 2 (June 1991). See the "COPYING" file distributed with this > > > software > > > * for more info. > > > */ > > > > > > > > > > > > ************************************************************************* **** > > ** > > > John Utz spaz@u.washington.edu > > > idiocy is the impulse function in the convolution of life > > > > > > > > > > > ***************************************************************************** ** > John Utz spaz@u.washington.edu > idiocy is the impulse function in the convolution of life > From owner-freebsd-multimedia Sat Jul 19 19:59:26 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA24874 for multimedia-outgoing; Sat, 19 Jul 1997 19:59:26 -0700 (PDT) Received: from becker2.u.washington.edu (spaz@becker2.u.washington.edu [140.142.12.68]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA24867 for ; Sat, 19 Jul 1997 19:59:24 -0700 (PDT) Received: from localhost (spaz@localhost) by becker2.u.washington.edu (8.8.4+UW97.07/8.8.4+UW97.05) with SMTP id TAA32542; Sat, 19 Jul 1997 19:59:19 -0700 (PDT) Date: Sat, 19 Jul 1997 19:59:18 -0700 (PDT) From: "J. Utz" To: hannu@voxware.pp.fi cc: multimedia@freebsd.org Subject: use of maui.c from uss/lite permission? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Greetings hannu; i have located a maui.c file on a web site that claims to be from a uss/lite distribution. it is newer then the voxware-3.5 alpha code that the freebsd multimedia mailing list is trying to use for our default sound drivers. may we have your permission to use this file? the exact header from the file looks like this: /* * sound/maui.c * * The low level driver for Turtle Beach Maui and Tropez. */ /* * Copyright (C) by Hannu Savolainen 1993-1996 * * USS/Lite for Linux is distributed under the GNU GENERAL PUBLIC LICENSE(GPL) * Version 2 (June 1991). See the "COPYING" file distributed with thissoftware * for more info. */ i hope to hear from you in the affirmative! sincerely; john ******************************************************************************* John Utz spaz@u.washington.edu idiocy is the impulse function in the convolution of life