From owner-freebsd-multimedia Sun Jul 20 09:07:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21812 for multimedia-outgoing; Sun, 20 Jul 1997 09:07:52 -0700 (PDT) Received: from grizzly.fas.com (chs0274.awod.com [208.140.97.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA21796 for ; Sun, 20 Jul 1997 09:07:44 -0700 (PDT) Message-Id: <199707201607.JAA21796@hub.freebsd.org> Received: by grizzly.fas.com ($Revision: 1.37.109.23 $/16.2) id AA031764858; Sun, 20 Jul 1997 12:07:38 -0400 Subject: Simple two way audio on local network. To: freebsd-multimedia@freebsd.org (Free BSD Multimedia List) Date: Sun, 20 Jul 1997 12:07:37 -0400 (EDT) From: "Stan Brown" X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I have a small network of computers in my house. Among these I have a FreeBSD 2.2.2 machine downstairs with a GUS PnP, and an HP 735 upstairs. Both of these have quite nice audio, with speakers and cheap mikes. I would like to set up to be able to use these as a simple intercom from upstairs to downstairs. Could someone point me to the tight tool(s) to set up to accomplish this? Thanks. -- Stan Brown stanb@netcom.com 404-996-6955 Factory Automation Systems Atlanta Ga. -- Look, look, see Windows 95. Buy, lemmings, buy! Pay no attention to that cliff ahead... Henry Spencer (c) 1997 Stan Brown. Redistribution via the Microsoft Network is prohibited. From owner-freebsd-multimedia Sun Jul 20 10:43:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26043 for multimedia-outgoing; Sun, 20 Jul 1997 10:43:59 -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 KAA26038 for ; Sun, 20 Jul 1997 10:43:56 -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 KAA04918; Sun, 20 Jul 1997 10:43:45 -0700 (PDT) Message-Id: <199707201743.KAA04918@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: brianc@pobox.com (Brian Campbell), freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver In-reply-to: Your message of "Sun, 20 Jul 1997 09:11:51 +0200." <199707200711.JAA19743@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 1997 10:43:45 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Guys, I understand Luigi's position given that I had to dig into the code and understand it. Simplication of the dma code is a very important step towards having having a stable sound driver and for future support by others. Have fun, Amancio >From The Desk Of Luigi Rizzo : > > On Sat, Jul 19, 1997 at 04:37:50PM +0200, Luigi Rizzo wrote: > > > I have planned to rewrite the dma buffer handling routines for > > > the sound driver as follows. > > > > Why? > > > > Is the current mechanism insufficient? I thought changes were only > > requried for full-duplex operation. > > > > There is a mechanism for setting the size and number of DMA buffers, > > is there not? Will this be removed, or the settings simply ignored? > > the main problem I have is that I find the dma code quite complex to > follow and understand (as all code which has been evolving for a long > time and adapting to new boards etc.). The scheme I have described is, > in my opinion, simpler and more effective with respect to latency. > > Maybe it's just my problem but since I am doing the work I'll do it in > the way I find more effective. > > Plus I'll document it ! > > Cheers > Luigi From owner-freebsd-multimedia Sun Jul 20 10:46:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA26116 for multimedia-outgoing; Sun, 20 Jul 1997 10:46: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 KAA26111 for ; Sun, 20 Jul 1997 10:46: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 KAA04966; Sun, 20 Jul 1997 10:46:28 -0700 (PDT) Message-Id: <199707201746.KAA04966@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Stan Brown" cc: freebsd-multimedia@FreeBSD.ORG (Free BSD Multimedia List) Subject: Re: Simple two way audio on local network. In-reply-to: Your message of "Sun, 20 Jul 1997 12:07:37 EDT." <199707201607.JAA21796@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 1997 10:46:28 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Try running vat . Cheers, Amancio >From The Desk Of "Stan Brown" : > I have a small network of computers in my house. Among these I have a > FreeBSD 2.2.2 machine downstairs with a GUS PnP, and an HP 735 > upstairs. Both of these have quite nice audio, with speakers and cheap > mikes. > > I would like to set up to be able to use these as a simple intercom fro m > upstairs to downstairs. > > Could someone point me to the tight tool(s) to set up to accomplish > this? > > Thanks. > > -- > Stan Brown stanb@netcom.com 404-996-69 55 > Factory Automation Systems > Atlanta Ga. > -- > Look, look, see Windows 95. Buy, lemmings, buy! > Pay no attention to that cliff ahead... Henry Spencer > (c) 1997 Stan Brown. Redistribution via the Microsoft Network is prohibited. From owner-freebsd-multimedia Sun Jul 20 11:09:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA27115 for multimedia-outgoing; Sun, 20 Jul 1997 11:09:39 -0700 (PDT) Received: from sujal.prognet.com (sujal.prognet.com [204.255.154.231]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA27110 for ; Sun, 20 Jul 1997 11:09:37 -0700 (PDT) Received: from localhost (smpatel@localhost) by sujal.prognet.com (8.8.4/8.8.4) with SMTP id LAA12794; Sun, 20 Jul 1997 11:07:12 -0700 (PDT) X-Authentication-Warning: sujal.prognet.com: smpatel owned process doing -bs Date: Sun, 20 Jul 1997 11:07:12 -0700 (PDT) From: Sujal Patel To: Amancio Hasty cc: Luigi Rizzo , Brian Campbell , freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver In-Reply-To: <199707201743.KAA04918@rah.star-gate.com> 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 > I understand Luigi's position given that I had to dig into the > code and understand it. Simplication of the dma code is a very > important step towards having having a stable sound driver and > for future support by others. I Agree... I've been through that code too, and if someone wants to clean it up- God Bless them!! :-) Sujal > > >From The Desk Of Luigi Rizzo : > > > On Sat, Jul 19, 1997 at 04:37:50PM +0200, Luigi Rizzo wrote: > > > > I have planned to rewrite the dma buffer handling routines for > > > > the sound driver as follows. > > > > > > Why? > > > > > > Is the current mechanism insufficient? I thought changes were only > > > requried for full-duplex operation. > > > > > > There is a mechanism for setting the size and number of DMA buffers, > > > is there not? Will this be removed, or the settings simply ignored? > > > > the main problem I have is that I find the dma code quite complex to > > follow and understand (as all code which has been evolving for a long > > time and adapting to new boards etc.). The scheme I have described is, > > in my opinion, simpler and more effective with respect to latency. > > > > Maybe it's just my problem but since I am doing the work I'll do it in > > the way I find more effective. > > > > Plus I'll document it ! > > > > Cheers > > Luigi > > > > From owner-freebsd-multimedia Sun Jul 20 17:45:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA11282 for multimedia-outgoing; Sun, 20 Jul 1997 17:45:02 -0700 (PDT) Received: from pobox.com (ras115.microplus.ca [207.81.20.34]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA11263 for ; Sun, 20 Jul 1997 17:44:47 -0700 (PDT) Received: (from brianc@localhost) by pobox.com (8.8.5/8.8.5) id UAA04118; Sun, 20 Jul 1997 20:44:40 -0400 (EDT) Message-ID: <19970720204439.26980@pobox.com> Date: Sun, 20 Jul 1997 20:44:39 -0400 From: Brian Campbell To: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver References: <19970720010235.26253@pobox.com> <199707200711.JAA19743@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707200711.JAA19743@labinfo.iet.unipi.it>; from Luigi Rizzo on Sun, Jul 20, 1997 at 09:11:51AM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Sun, Jul 20, 1997 at 09:11:51AM +0200, Luigi Rizzo wrote: > > On Sat, Jul 19, 1997 at 04:37:50PM +0200, Luigi Rizzo wrote: > > Is the current mechanism insufficient? I thought changes were only > > requried for full-duplex operation. > > the main problem I have is that I find the dma code quite complex to > follow and understand (as all code which has been evolving for a long > time and adapting to new boards etc.). The scheme I have described is, > in my opinion, simpler and more effective with respect to latency. > > Plus I'll document it ! Simplification is a good goal. Documentation even even better. But I wasn't aware there were visible [audible? ;-] latency problems. > > There is a mechanism for setting the size and number of DMA buffers, > > is there not? Will this be removed, or the settings simply ignored? > > i forgot to say that all current ioctls will remain valid (for > backward compatibility reasons). If they are really useful, they > will have the same effect. If they become useless (e.g. in the case > of SNDCTL_DSP_SETFRAGMENT, because the new implementation implicitly > solves the problem), they might become a nop, or they will just > maintain a fake state variable. Not to suggest you shouldn't go off in your own direction, but I don't think SETFRAGMENT is useless. Sometimes you'll want to feed the dsp in little bits, sometimes you'll have lots to feed all at once then several CPU intensive seconds before you provide more -- suggesting the use of a large buffer. Similarly for recording. Sometimes you'll want to use a low number of small buffers for sampling -- say for some sort of recognition function, or frequency analyzer. You want to get hold of the samples as soon as possible and if your processing time on those samples means the recording "stalls" and you miss a buffer or three then you just want to continue with what's happening "now". In other circumstances you may want a few large buffers to make sure nothing gets lost and there are no "clicks". The point being that you probably can't chose a "best" number or size of DMA buffers. You probably also can't solve all latency problems (unless there's a gross one that exists that I'm unaware of) for all uses. P.S. What's going on with linux and free audio drivers these days? Are they still running 3.5 or have things d?evolved? From owner-freebsd-multimedia Sun Jul 20 18:59:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14777 for multimedia-outgoing; Sun, 20 Jul 1997 18:59:01 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id SAA14767; Sun, 20 Jul 1997 18:58:58 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id LAA20128; Mon, 21 Jul 1997 11:28:44 +0930 (CST) From: Michael Smith Message-Id: <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> Subject: Re: dma handling in the sound driver In-Reply-To: <199707191437.QAA01053@prova.iet.unipi.it> from Luigi Rizzo at "Jul 19, 97 04:37:50 pm" To: luigi@iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 11:28:44 +0930 (CST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > - 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!) This is the traditional double-buffered approach. You go on to describe a triple-buffered approach which is more suited to the high latency that is often encountered in multiprocessing situations. > 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. I presume that the plan here is that the host DMA controller loops endlessly over this buffer in autoinit mode? If not, there's no apparent need for such a complex approach; you can just use three separate buffers each sized suitably to cover the latency involved in filling the next. Another alternative would be to simply use an endlessly-recirculating DMA buffer of appropriate size thus : DMA V XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO Some data has been written to the sound device. Regardless of how much data you have, you start the DMA going. DMA V OOOOOOOOOOOOOOOXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO Here the DMA is in progress, consuming data. A selecting writer would be able to write here. DMA V YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY ... and more data has arrived. The key to keeping more data in the buffer than is consumed by the looping DMA is to make sure that any selecting writer is woken up often enough to keep you busy. In order to do this, you need something that interrupts you more than once per DMA loop. At 44kHz, 16-bit stereo you are looking at 160kB/sec throughput, which equates to 1.6kB per possible wakeup(). This isn't too hard to manage really; a 64kB recirculating buffer will give you 400ms of audio, or a 200ms mean wakeup time. You can play some more neat games. In the original first case : DMA V XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO ^ TC you set the terminal count short of the end of the buffer. This avoids your having to worry about the DMA running into unfilled buffer space. In the later case, where the buffer contents have wrapped : DMA V YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY ^ TC TC is set to the end of the buffer, and the autoinit bit is set, so that it will loop back to the start. When it does loop, you'll get an interrupt, and you can reprogram TC again : DMA V YYYYOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO ^ TC If an application is too slow to respond to your waking it up, then there's really nothing more you can do. As Amancio has observed, many applications will want to write small amounts of data on a regular basis. A timer event run once every 1/hz seconds can easily monitor the progress of the DMA and update the buffer tail pointer & wake up any writers. In this model, the overhead of uiomove is effectively irrelevant; data is solicited from the application as early as is possible. I'm not sure if this actually helps you... > Luigi Rizzo Dip. di Ingegneria dell'Informazione -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Sun Jul 20 19:36:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA16519 for multimedia-outgoing; Sun, 20 Jul 1997 19:36:36 -0700 (PDT) Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id TAA16509 for ; Sun, 20 Jul 1997 19:36:33 -0700 (PDT) Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <53127(4)>; Sun, 20 Jul 1997 19:36:00 PDT Received: by crevenia.parc.xerox.com id <177512>; Sun, 20 Jul 1997 19:35:51 -0700 From: Bill Fenner To: multimedia@freebsd.org Subject: /dev/sequencer and gmod-3.0.6? Message-Id: <97Jul20.193551pdt.177512@crevenia.parc.xerox.com> Date: Sun, 20 Jul 1997 19:35:46 PDT Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I'm trying to update our port of gmod to 3.0.6 . The UI seems to work just peachy, but when it tries to go and play the mod file, it locks up. A ktrace seems to show that it's writing a ton of data to /dev/sequencer. I've got no clue what it might be doing. If anyone with a GUS feels like trying to figure out what's going on, my new port is at http://www.freebsd.org/~fenner/new-gmod.tar.gz Thanks, Bill From owner-freebsd-multimedia Sun Jul 20 19:46:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA16912 for multimedia-outgoing; Sun, 20 Jul 1997 19:46:01 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA16884; Sun, 20 Jul 1997 19:45:50 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id MAA20440; Mon, 21 Jul 1997 12:15:30 +0930 (CST) From: Michael Smith Message-Id: <199707210245.MAA20440@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707170553.HAA15160@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 17, 97 07:53:40 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 12:15:29 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > controller sndX > > > brings in all the files related to generic sound support for all > > > subsystem. This includes, in particular, the mixer, dma code, > > > timers, and some support routines. > > > > > > 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 > > > > Thes should ideally be "at snd?", eg. like the 'disk' stuff, or just > > 'device xxx' like the SCSI devices. They're _not_ "at isa?" in the > > true sense of the word. > > right. But what are the implications of using "at xyz?" ? How do I test > for a specific bus, etc. ? I've just been working through this with the parallel-port stuff, as the ultimate goal there is to produce drivers that will work on any parallel port. The way to go for that (at the moment) is like the PCI code; you use a linker set to create an aggregated list of drivers, which you then scan with your bus code. This isn't really ideal for your case though, as whilst there's some common sound code, there's little or no correlation between the various component drivers, other than (perhaps) that they are aggregated together on a single card. > The identification info should suffice to determine exactly which > board you have (down to the revision level of the chip) so I think > there is really little need to "probe" the device; rather, one > should just run the appropriate configuration commands and deal > with exceptions the standard way. ISA device probing should essentially provide additional information supplementary to that divined by PnP. Once you have all the "what is where" information, you can start working out what to do with it. If using the PnP stuff is of interest to you, you could help me out with some suggestions for calling 16-bit protected-mode BIOS interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of documentation on various bits and pieces (including the ECSD interface) which would be _very_ helpful in this endeavour. 8) > Luigi Rizzo | Dip. di Ingegneria dell'Informazione -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Sun Jul 20 20:29:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA18976 for multimedia-outgoing; Sun, 20 Jul 1997 20:29:28 -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 UAA18971; Sun, 20 Jul 1997 20:29: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 UAA00494; Sun, 20 Jul 1997 20:28:52 -0700 (PDT) Message-Id: <199707210328.UAA00494@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Michael Smith cc: luigi@iet.unipi.it (Luigi Rizzo), hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver In-reply-to: Your message of "Mon, 21 Jul 1997 11:28:44 +0930." <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 20 Jul 1997 20:28:52 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Guys, All I am trying to do is to explain the existing dma algorithm so that the new re-design does not break the sound apps. Michael's explication is very close to the current dma algorithm. SNDCTL_DSP_SETFRAGMENT sets the block of io which the sub modules use to send or receive data. SNDCTL_DSP_SETBLKSIZE for all practical purposes is the same as the above. If the user does not set the block size then the dma routines choses a size equal to about 1/2 second worth of data. For typical sun style au files this is 4096 bytes . A quick walk thru of the existing dma routines cat TSTSND-elvis-has-left-bldg.au >/dev/audio Jul 20 19:15:29 cioloco /kernel: audio cnt 18364 audio_write initiates request for dma Jul 20 19:15:29 cioloco /kernel: dmabuf start count 65536 Set up an auto dma buffer of size 65536 The current block size which we use for io is 4096. qlen is the number of buffer's queued up . The dma routines loop on the auto dma buffer modulus 4096. Jul 20 19:15:29 cioloco /kernel: intrflag 0 cnt 4095 dsp_count 4095 This is the first time thru in sb16_dsp.c so we kick off the dma process. Jul 20 19:15:29 cioloco /kernel: what qlen 4 qhead 1 We got an interrupt and we have 4 queued up buffers Jul 20 19:15:29 cioloco /kernel: return cnt 4095 Jul 20 19:15:30 cioloco /kernel: what qlen 3 qhead 2 Jul 20 19:15:30 cioloco /kernel: return cnt 4095 Jul 20 19:15:30 cioloco /kernel: what qlen 2 qhead 3 Jul 20 19:15:30 cioloco /kernel: return cnt 4095 Jul 20 19:15:31 cioloco /kernel: what qlen 1 qhead 4 Jul 20 19:15:31 cioloco /kernel: what qlen 0 qhead 5 No more buffers to process we are done. I don't think latency is a problem with the current dma routines given that we can always set the block of io . However the dma routines are very complex and simplification is needed. >From The Desk Of Michael Smith : > Luigi Rizzo stands accused of saying: > > > > - 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!) > > This is the traditional double-buffered approach. You go on to > describe a triple-buffered approach which is more suited to the high > latency that is often encountered in multiprocessing situations. > > > 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. > > I presume that the plan here is that the host DMA controller loops > endlessly over this buffer in autoinit mode? > > If not, there's no apparent need for such a complex approach; you can > just use three separate buffers each sized suitably to cover the > latency involved in filling the next. > > Another alternative would be to simply use an endlessly-recirculating > DMA buffer of appropriate size thus : > > DMA > V > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO > > Some data has been written to the sound device. Regardless of how > much data you have, you start the DMA going. > > DMA > V > OOOOOOOOOOOOOOOXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO > > Here the DMA is in progress, consuming data. A selecting writer would be > able to write here. > > DMA > V > YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY > > ... and more data has arrived. The key to keeping more data in the buffer > than is consumed by the looping DMA is to make sure that any selecting > writer is woken up often enough to keep you busy. In order to do this, > you need something that interrupts you more than once per DMA loop. > > At 44kHz, 16-bit stereo you are looking at 160kB/sec throughput, which > equates to 1.6kB per possible wakeup(). This isn't too hard to manage > really; a 64kB recirculating buffer will give you 400ms of audio, or > a 200ms mean wakeup time. > > You can play some more neat games. In the original first case : > > DMA > V > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXOOOOOOOOOOOOOOOOOO > ^ > TC > > you set the terminal count short of the end of the buffer. This avoids > your having to worry about the DMA running into unfilled buffer space. > > In the later case, where the buffer contents have wrapped : > > DMA > V > YYYYOOOOOOOOOOOOOOOOOOOOOXXXXXXXXXYYYYYYYYYYYYYYYYYY > ^ > TC > > TC is set to the end of the buffer, and the autoinit bit is set, so > that it will loop back to the start. When it does loop, you'll get an > interrupt, and you can reprogram TC again : > > DMA > V > YYYYOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO > ^ > TC > > If an application is too slow to respond to your waking it up, then > there's really nothing more you can do. As Amancio has observed, many > applications will want to write small amounts of data on a regular > basis. A timer event run once every 1/hz seconds can easily monitor > the progress of the DMA and update the buffer tail pointer & wake up > any writers. > > In this model, the overhead of uiomove is effectively irrelevant; data > is solicited from the application as early as is possible. > > I'm not sure if this actually helps you... > > > Luigi Rizzo Dip. di Ingegneria dell'Informazione > > -- > ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ > ]] Genesis Software genesis@gsoft.com.au [[ > ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ > ]] realtime instrument control. (ph) +61-8-8267-3493 [[ > ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Sun Jul 20 21:54:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22521 for multimedia-outgoing; Sun, 20 Jul 1997 21:54:06 -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 VAA22514 for ; Sun, 20 Jul 1997 21:54:02 -0700 (PDT) Received: (from olli@localhost) by elch.heim4.tu-clausthal.de (8.8.6/8.8.6) id GAA13291 for multimedia@freebsd.org; Mon, 21 Jul 1997 06:53:52 +0200 (MET DST) Message-Id: <199707210453.GAA13291@elch.heim4.tu-clausthal.de> Subject: Re: dma handling in the sound driver To: multimedia@freebsd.org Date: Mon, 21 Jul 1997 06:53:52 +0200 (MET DST) In-Reply-To: <199707210328.UAA00494@rah.star-gate.com> from "Amancio Hasty" at Jul 20, 97 08:28:52 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-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hello, Just a small comment/question... Amancio Hasty wrote: > [...] > SNDCTL_DSP_SETFRAGMENT > sets the block of io which the sub modules use to send or receive > data. > > SNDCTL_DSP_SETBLKSIZE > for all practical purposes is the same as the above. > > If the user does not set the block size then the dma routines choses > a size equal to about 1/2 second worth of data. For typical sun > style au files this is 4096 bytes . I am currently facing the following problem: I am writing a frontend for mpg123 (MPEG audio player). When the user presses the Pause/Stop button (or Fast Forward or whatever), there's always a small delay -- I guess it is because of that 1/2 second DMA buffer. However, I'd like the audio to stop _immediately_ when a button is pressed, not 1/2 second later or something like that. There are probably two solutions: - Using one of the above ioctls to reduce the buffer block size (about 1/10 or maybe 1/5 second would be acceptable). However, that probably increases the risk that the audio playback is interrupted because the buffer can't be filled in time by the application. This might especially be a problem on slower CPUs, and/or if several other processes are running in parallel. - Tell the audio device somehow to stop playback, and (in case of Fast Forward) forget the rest of the buffered data. (In the latter case, it would be an additional bonus if the audio device could tell the application how much data was discarded.) -- However, as far as I know, this isn't possible, is it? Any suggestions and helpful hints are greatly appreciated. Regards Oliver PS: On Solaris, I solved the problem like this: By doing a write() with 0 bytes, a special "mark" is inserted in the buffer. When the playback has reached that mark, a signal (SIGPOLL) is delivered to the process, so we know how much data has been actually played. Furthermore, the device supports "pausing" by setting a flag (AUDIO_SETINFO ioctl), and it can flush the remaining audio data from its buffer (I_FLUSH STREAMS ioctl). -- Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Sun Jul 20 21:54:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA22572 for multimedia-outgoing; Sun, 20 Jul 1997 21:54:46 -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 VAA22543; Sun, 20 Jul 1997 21:54:34 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA20510; Mon, 21 Jul 1997 05:52:10 +0200 From: Luigi Rizzo Message-Id: <199707210352.FAA20510@labinfo.iet.unipi.it> Subject: Re: sound driver structure and configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 05:52:10 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707210245.MAA20440@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 12:15:10 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > > > > > > > device pcmX at isa ? port? tty irq N drq D flags F vector pcmintr ... > > > Thes should ideally be "at snd?", eg. like the 'disk' stuff, or just > > > 'device xxx' like the SCSI devices. They're _not_ "at isa?" in the > > > true sense of the word. > > > > right. But what are the implications of using "at xyz?" ? How do I test > > for a specific bus, etc. ? > > The way to go for that (at the moment) is like the PCI code; you use a > linker set to create an aggregated list of drivers, which you then > scan with your bus code. more or less this is what I do now. Except that I do not leave the user a choice of which modules to include and which not, and the actual selection of the driver to use (if necessary at all) is done through some bits of the 'flags' field. I have done this because in in the sound driver there are probably a couple of main operating modes (i.e. soundblaster and MSS) for the codec, and all the card-specific code is for initialization or handling special features of the board. And it is too complex to ask the user (possibly an inexperienced one) to produce a correct configuration file otherwise, with all the required options for his board. > If using the PnP stuff is of interest to you, you could help me out > with some suggestions for calling 16-bit protected-mode BIOS > interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of unfortunately i am not enough familiar with the architecture of the system to help out on this... 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 Sun Jul 20 22:08:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA23182 for multimedia-outgoing; Sun, 20 Jul 1997 22:08:13 -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 WAA23176 for ; Sun, 20 Jul 1997 22:08:05 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA20534; Mon, 21 Jul 1997 06:05:51 +0200 From: Luigi Rizzo Message-Id: <199707210405.GAA20534@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: brianc@pobox.com (Brian Campbell) Date: Mon, 21 Jul 1997 06:05:50 +0200 (MET DST) Cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: <19970720204439.26980@pobox.com> from "Brian Campbell" at Jul 20, 97 08:44:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Not to suggest you shouldn't go off in your own direction, but I > don't think SETFRAGMENT is useless. I agree that with the current code SETFRAGMENT is necessary for the reasons you mention. But with my scheme it becomes less necessary because there is no predefined buffer size, the driver adapts to the size of io requests done by the driver, while at the same time it feeds the dma engine with the largest possible buffer size. What I _can_ do (and in fact will, following your and other comments) is to make the SETFRAGMENT call be used to limit the max size passed to the DMA. This would be useful to reduce latency when reading. The change is just one line of code: dl = min (dl, maxfragmentsize); so I am not too worried about implementing it :) Cheers Luigi From owner-freebsd-multimedia Sun Jul 20 22:25:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA23675 for multimedia-outgoing; Sun, 20 Jul 1997 22:25:19 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id WAA23670; Sun, 20 Jul 1997 22:25:13 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA20549; Mon, 21 Jul 1997 06:22:55 +0200 From: Luigi Rizzo Message-Id: <199707210422.GAA20549@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 06:22:54 +0200 (MET DST) Cc: luigi@iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG In-Reply-To: <199707210158.LAA20128@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 11:28:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > > > - with two DMA buffers, we can refill one buffer while the other one ... > This is the traditional double-buffered approach. You go on to certainly I am not inventing anything :) the problem is that, while writing, one never knows if sufficient info are given to let everybody understand all the details, so better give more than be too criptic. > describe a triple-buffered approach which is more suited to the high > latency that is often encountered in multiprocessing situations. in fact I don't agree that multiprocessors should necessarily have high latency, and if a critical interrupt (e.g. the one restarting a DMA transfer) is delayed too much, we are in trouble and get holes in the i/o no matter what we do... > > 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. > > I presume that the plan here is that the host DMA controller loops > endlessly over this buffer in autoinit mode? whoops... I did not think explicitly to autoinit mode, actually I suspect that some changes are necessary to my scheme to support automode. I'll look into them, thanks for the suggestion. > If not, there's no apparent need for such a complex approach; you can > just use three separate buffers each sized suitably to cover the > latency involved in filling the next. not sure. the problem which worries me more is the latency from the time the write routine is invoked with a large block, and the time the next buffer is completely filled up by the uiomove. Now you are right that one could play games such as first mark the buffer as full, with the appropriate length, and then start the uiomove, in the assumption that uiomove will finish first anyways (if not interrupted...) > Another alternative would be to simply use an endlessly-recirculating > DMA buffer of appropriate size thus : ... > I'm not sure if this actually helps you... yes a lot. An interesting alternative, I just have to see how complex (and reliable) is to read from the DMA registers on the fly, and how to do this with the MSS which has some kind of dma support on board. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Sun Jul 20 22:53:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA24584 for multimedia-outgoing; Sun, 20 Jul 1997 22:53:02 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA24562; Sun, 20 Jul 1997 22:52:48 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id PAA21772; Mon, 21 Jul 1997 15:21:49 +0930 (CST) From: Michael Smith Message-Id: <199707210551.PAA21772@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707210352.FAA20510@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 05:52:10 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 15:21:49 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > > The way to go for that (at the moment) is like the PCI code; you use a > > linker set to create an aggregated list of drivers, which you then > > scan with your bus code. > > more or less this is what I do now. Except that I do not leave the user > a choice of which modules to include and which not, and the actual > selection of the driver to use (if necessary at all) is done through > some bits of the 'flags' field. Ok. > I have done this because in in the sound driver there are probably a > couple of main operating modes (i.e. soundblaster and MSS) for the > codec, and all the card-specific code is for initialization or handling > special features of the board. And it is too complex to ask the user > (possibly an inexperienced one) to produce a correct configuration file > otherwise, with all the required options for his board. Aha. May I offer a suggestion? Have the 'snd' controller pull in all the modules for the various on-card subsystems. Have each of these subsystems register themselves in a linker set using a 'name' field to identify themselves. Then have 'device at ...?' statements which pull in probe code for each of the basic supported board types; eg. mss, sb16, etc. Each of these sets of probe code know how to find the board type they support, whether via PnP or direct probing, and then they use the linker set from the snd controller to locate the subsystem modules and feed them the information required to initialise the subsystems on the card. This lets you have board-specific probe and setup code, while keeping the driver components separate and board-independant. > > If using the PnP stuff is of interest to you, you could help me out > > with some suggestions for calling 16-bit protected-mode BIOS > > interfaces from 32-bit (eg. FreeBSD kernel) mode 8) I have reams of > > unfortunately i am not enough familiar with the architecture of the > system to help out on this... Drat. 8) > Luigi -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Mon Jul 21 00:42:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28089 for multimedia-outgoing; Mon, 21 Jul 1997 00:42:54 -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 AAA28066; Mon, 21 Jul 1997 00:42:44 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA20692; Mon, 21 Jul 1997 08:37:06 +0200 From: Luigi Rizzo Message-Id: <199707210637.IAA20692@labinfo.iet.unipi.it> Subject: Re: sound driver structure and configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 08:37:06 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707210551.PAA21772@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 03:21:30 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Aha. May I offer a suggestion? > > Have the 'snd' controller pull in all the modules for the various > on-card subsystems. Have each of these subsystems register themselves > in a linker set using a 'name' field to identify themselves. > > Then have 'device at ...?' statements which pull in probe code for right, but this brings me back to the initial question. What does the config progrm do when it finds a "device at foo?" statement ? I have tried running config with different config files where foo is replaced by bar o rother strings and see no difference in the output . I guess the "isa" keyword is somehow magic (or it becomes specially treated because of something in the "files.i386" file ? 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 21 00:43:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28114 for multimedia-outgoing; Mon, 21 Jul 1997 00:43:25 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA28038 for ; Mon, 21 Jul 1997 00:42:03 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id IAA20704; Mon, 21 Jul 1997 08:39:57 +0200 From: Luigi Rizzo Message-Id: <199707210639.IAA20704@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: oliver.fromme@heim3.tu-clausthal.de (Oliver Fromme) Date: Mon, 21 Jul 1997 08:39:57 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199707210453.GAA13291@elch.heim4.tu-clausthal.de> from "Oliver Fromme" at Jul 21, 97 06:53:33 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Hello, > > Just a small comment/question... > > I am currently facing the following problem: I am writing a > frontend for mpg123 (MPEG audio player). When the user > presses the Pause/Stop button (or Fast Forward or whatever), > there's always a small delay -- I guess it is because of that > 1/2 second DMA buffer. However, I'd like the audio to stop ok so you would need a "suspend" ioctl which would immediately block io, and report the amount of undelivered bytes so that play can rewind before resuming ? Or you are just happy by suspending the transfer and restarting it with the data left to transfer ? 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 21 00:45:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28213 for multimedia-outgoing; Mon, 21 Jul 1997 00:45:25 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28207; Mon, 21 Jul 1997 00:45:21 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA22211; Mon, 21 Jul 1997 17:12:58 +0930 (CST) From: Michael Smith Message-Id: <199707210742.RAA22211@genesis.atrad.adelaide.edu.au> Subject: Re: dma handling in the sound driver In-Reply-To: <199707210422.GAA20549@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 06:22:54 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 17:12:58 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, luigi@iet.unipi.it, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > certainly I am not inventing anything :) the problem is that, while > writing, one never knows if sufficient info are given to let > everybody understand all the details, so better give more than be too > criptic. Oh, understood entirely. Likewise my reply 8) > > describe a triple-buffered approach which is more suited to the high > > latency that is often encountered in multiprocessing situations. > > in fact I don't agree that multiprocessors should necessarily have high > latency, and if a critical interrupt (e.g. the one restarting a DMA > transfer) is delayed too much, we are in trouble and get holes in the > i/o no matter what we do... Oops, I meant "multiprogramming", sorry. The big issue with something like this is the possibility that the task responsible for writing audio data may be a long way down the list of runnables. > whoops... I did not think explicitly to autoinit mode, actually I > suspect that some changes are necessary to my scheme to support > automode. I'll look into them, thanks for the suggestion. Sure. Note that autoinit is only suitable for circular buffers. > > If not, there's no apparent need for such a complex approach; you can > > just use three separate buffers each sized suitably to cover the > > latency involved in filling the next. > > not sure. the problem which worries me more is the latency from the > time the write routine is invoked with a large block, and the time the > next buffer is completely filled up by the uiomove. Now you are right > that one could play games such as first mark the buffer as full, with > the appropriate length, and then start the uiomove, in the assumption > that uiomove will finish first anyways (if not interrupted...) ... or you can chunk any copy in in reasonable slabs, and update the DMA controller TC after each slab. ie. for any given write, divide the region being written into page-sized slabs so that you have at most one VM hit per uiomove and then update the DMA after each one. Note that the endleess buffer approach I described specifically tries to avoid the delay problem by trying to keep the buffer as full as possible at all times. It is only in the case where the buffer is almost empty because the writer has lagged that you have to worry about how long a copyin takes. You might also want to check and see if the copyin used by uiomove actually faults the pages first and then copies, or whether it only faults on demand. In this case, doing a full-sized move would actually be faster. Also, consider that the move overhead is really nothing more than another latency item; ie. it's quantitive not qualatative. > yes a lot. An interesting alternative, I just have to see how complex > (and reliable) is to read from the DMA registers on the fly, and how to > do this with the MSS which has some kind of dma support on board. Indeedy. As Amancio said, my suggestion's nothing new either; streaming DMA is probably about as old as double-buffered DMA 8) The former is good for DMA controllers that loop, the latter for those that support buffer chaining. The 8357 doesn't do buffer chaining, so streaming is the way to go. -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Mon Jul 21 00:47:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28292 for multimedia-outgoing; Mon, 21 Jul 1997 00:47: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 AAA28287 for ; Mon, 21 Jul 1997 00:47: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 AAA00376; Mon, 21 Jul 1997 00:47:22 -0700 (PDT) Message-Id: <199707210747.AAA00376@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: dma handling in the sound driver In-reply-to: Your message of "Mon, 21 Jul 1997 06:53:52 +0200." <199707210453.GAA13291@elch.heim4.tu-clausthal.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 00:47:22 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, You can issue SNDCTL_DSP_SYNC to flush the buffer as for the buffer size you can probably use 1/5 second you can compute the block size based upon the frequency. With respect to not getting back on time thats a function of how much cpu time its spend doing other things. You will have more than 1/5 second to get back to the driver because the driver queues up N buffer requests. You can figured out how many buffers are outstanding by issuing : 1. SNDCTL_DSP_GETOSPACE --- count_info info; ioctl(fd, SNDCTL_DSP_GETOPTR, &info); --- info.blocks == to the number of outstanding buffers. You can stop instantly by issuing a : SNDCTL_DSP_RESET Since that does an abrupt halt I suggest that you mute the volume and after the SNDCTL_DSP_RESET you can restore the volume ---- Hope this helps, Amancio >From The Desk Of Oliver Fromme : > > Hello, > > Just a small comment/question... > > Amancio Hasty wrote: > > [...] > > SNDCTL_DSP_SETFRAGMENT > > sets the block of io which the sub modules use to send or receive > > data. > > > > SNDCTL_DSP_SETBLKSIZE > > for all practical purposes is the same as the above. > > > > If the user does not set the block size then the dma routines choses > > a size equal to about 1/2 second worth of data. For typical sun > > style au files this is 4096 bytes . > > I am currently facing the following problem: I am writing a > frontend for mpg123 (MPEG audio player). When the user > presses the Pause/Stop button (or Fast Forward or whatever), > there's always a small delay -- I guess it is because of that > 1/2 second DMA buffer. However, I'd like the audio to stop > _immediately_ when a button is pressed, not 1/2 second later > or something like that. > > There are probably two solutions: > > - Using one of the above ioctls to reduce the buffer block > size (about 1/10 or maybe 1/5 second would be acceptable). > However, that probably increases the risk that the audio > playback is interrupted because the buffer can't be filled > in time by the application. This might especially be a > problem on slower CPUs, and/or if several other processes > are running in parallel. > > - Tell the audio device somehow to stop playback, and (in case > of Fast Forward) forget the rest of the buffered data. (In > the latter case, it would be an additional bonus if the > audio device could tell the application how much data was > discarded.) -- However, as far as I know, this isn't > possible, is it? > > Any suggestions and helpful hints are greatly appreciated. > > Regards > Oliver > > PS: On Solaris, I solved the problem like this: By doing a > write() with 0 bytes, a special "mark" is inserted in the > buffer. When the playback has reached that mark, a signal > (SIGPOLL) is delivered to the process, so we know how much data > has been actually played. Furthermore, the device supports > "pausing" by setting a flag (AUDIO_SETINFO ioctl), and it can > flush the remaining audio data from its buffer (I_FLUSH STREAMS > ioctl). > > -- > Oliver Fromme, Leibnizstr. 18-61, 38678 Clausthal, Germany > (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) From owner-freebsd-multimedia Mon Jul 21 00:52:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA28496 for multimedia-outgoing; Mon, 21 Jul 1997 00:52:01 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA28479; Mon, 21 Jul 1997 00:51:55 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA22242; Mon, 21 Jul 1997 17:21:31 +0930 (CST) From: Michael Smith Message-Id: <199707210751.RAA22242@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707210637.IAA20692@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 08:37:06 am" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 17:21:30 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > Aha. May I offer a suggestion? > > > > Have the 'snd' controller pull in all the modules for the various > > on-card subsystems. Have each of these subsystems register themselves > > in a linker set using a 'name' field to identify themselves. > > > > Then have 'device at ...?' statements which pull in probe code for > > right, but this brings me back to the initial question. What does the > config progrm do when it finds a "device at foo?" statement ? I have > tried running config with different config files where foo is replaced > by bar o rother strings and see no difference in the output . I guess > the "isa" keyword is somehow magic (or it becomes specially treated > because of something in the "files.i386" file ? Oops, my previous wasn't good enough, sorry. The 'device at foo?' doesn't appear to do anything special, and my suggesting it was really wrong. Here, in full glory : controller snd? # sound support, also all chipset modules device zw0 at isa? port... # ZongleWonker ISA board probe ... device bf0 # Bafwangg PCI soundcard probe Then a chipset module might say : struct snddriver_module foo_codec = { foocodec_attach, SNDD_TYPE_CODEC, (void *)foocodec_function_switch, "foo_codec" } DATA_SET(snddriver, foo_codec); Then the 'zw' driver, knowing that the board it had found had a 'foo' codec, would look it up by name in the 'snddriver' linker set, and call its attach function to attach it, passing in the parameters required. Likewise the Bafwang card code would just detect the card and pull up the desired chip driver(s). Does that make more sense? 8) -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Mon Jul 21 04:07:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA06949 for multimedia-outgoing; Mon, 21 Jul 1997 04:07:12 -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 EAA06924; Mon, 21 Jul 1997 04:06:36 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA20937; Mon, 21 Jul 1997 12:04:22 +0200 From: Luigi Rizzo Message-Id: <199707211004.MAA20937@labinfo.iet.unipi.it> Subject: Re: sound driver structure and configuration To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 12:04:22 +0200 (MET DST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG In-Reply-To: <199707210751.RAA22242@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 21, 97 05:21:11 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo stands accused of saying: > > > Aha. May I offer a suggestion? > > > > > > Have the 'snd' controller pull in all the modules for the various > > > on-card subsystems. Have each of these subsystems register themselves > > > in a linker set using a 'name' field to identify themselves. > > > > > > Then have 'device at ...?' statements which pull in probe code for > > > > right, but this brings me back to the initial question. What does the > > config progrm do when it finds a "device at foo?" statement ? I have > > tried running config with different config files where foo is replaced > > by bar o rother strings and see no difference in the output . I guess > > the "isa" keyword is somehow magic (or it becomes specially treated > > because of something in the "files.i386" file ? > > Oops, my previous wasn't good enough, sorry. > > The 'device at foo?' doesn't appear to do anything special, and my > suggesting it was really wrong. > > Here, in full glory : > > controller snd? # sound support, also all chipset modules > > device zw0 at isa? port... # ZongleWonker ISA board probe > ... > device bf0 # Bafwangg PCI soundcard probe > > > Then a chipset module might say : > > struct snddriver_module foo_codec = { > foocodec_attach, > SNDD_TYPE_CODEC, > (void *)foocodec_function_switch, > "foo_codec" > } > DATA_SET(snddriver, foo_codec); ... > Does that make more sense? 8) well, this is exactly what I have done! One minor difference, I have used a "struct pnp_device" as follows: static struct pnp_device cs4236 = { "cs4236", cs4236_probe, cs4236_attach, &cs4236_count, NULL, /* shutdown */ &tty_imask /* imask */ }; so that I can easily use a different imask when needed. Maybe I will need more fields in the struct pnp_device to make the mechanism more flexible for other device types. In fact the structure should be the same for ISA/PnP and PCI device, but I understand that support for autoconfiguring devices has been added according to the needs of specific buses and the mechanism is not as clean as it might be. When I am done with the PnP stuff I will talk back to those who implemented the pci things to discuss this item. 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 21 04:21:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA07709 for multimedia-outgoing; Mon, 21 Jul 1997 04:21:54 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA07672; Mon, 21 Jul 1997 04:21:30 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id UAA22939; Mon, 21 Jul 1997 20:41:25 +0930 (CST) From: Michael Smith Message-Id: <199707211111.UAA22939@genesis.atrad.adelaide.edu.au> Subject: Re: sound driver structure and configuration In-Reply-To: <199707211004.MAA20937@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 12:04:22 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Mon, 21 Jul 1997 20:41:25 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, multimedia@FreeBSD.ORG, hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > > > Then a chipset module might say : > > > > struct snddriver_module foo_codec = { > > foocodec_attach, > > SNDD_TYPE_CODEC, > > (void *)foocodec_function_switch, > > "foo_codec" > > } > > DATA_SET(snddriver, foo_codec); > ... > > Does that make more sense? 8) > > well, this is exactly what I have done! One minor difference, I have > used a "struct pnp_device" as follows: Hmm, you are going out further. I think it is not good at all to call this a "PnP" device; I think that the generic PnP support linker set needs more flexibility than this. (But you're on the right track.) > static struct pnp_device cs4236 = { > "cs4236", > cs4236_probe, > cs4236_attach, > &cs4236_count, > NULL, /* shutdown */ > &tty_imask /* imask */ > }; > > so that I can easily use a different imask when needed. > Maybe I will need more fields in the struct pnp_device to make the > mechanism more flexible for other device types. Oops, reading my thoughts. Do you have copies of Doug Rabson's work on cleaning up the ISA autoconfig process? -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Mon Jul 21 04:47:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA08909 for multimedia-outgoing; Mon, 21 Jul 1997 04:47:03 -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 EAA08902; Mon, 21 Jul 1997 04:46:44 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.5/8.6.9) id VAA10007; Mon, 21 Jul 1997 21:33:47 +1000 Date: Mon, 21 Jul 1997 21:33:47 +1000 From: Bruce Evans Message-Id: <199707211133.VAA10007@godzilla.zeta.org.au> To: bde@zeta.org.au, se@FreeBSD.ORG Subject: Re: snd driver attach routine Cc: hackers@FreeBSD.ORG, hasty@rah.star-gate.com, luigi@labinfo.iet.unipi.it, multimedia@FreeBSD.ORG, rhh@ct.picker.com Sender: owner-freebsd-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'. > >I could easily change the return type of >the PCI attach function. Should I ??? If anything is attached above the driver level, then you need a status from the driver attach to decide whether to clean up or attach more. For ISA, only interrupts are attached at a high level, but they shouldn't be, so ISA attach function shouldn't need to return status (but they should clean up if they fail). I'm not sure about PCI. Bruce From owner-freebsd-multimedia Mon Jul 21 04:52:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA09142 for multimedia-outgoing; Mon, 21 Jul 1997 04:52:50 -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 EAA09074; Mon, 21 Jul 1997 04:51:47 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id MAA21030; Mon, 21 Jul 1997 12:48:38 +0200 From: Luigi Rizzo Message-Id: <199707211048.MAA21030@labinfo.iet.unipi.it> Subject: Re: snd driver attach routine To: bde@zeta.org.au (Bruce Evans) Date: Mon, 21 Jul 1997 12:48:38 +0200 (MET DST) Cc: bde@zeta.org.au, se@FreeBSD.ORG, hackers@FreeBSD.ORG, hasty@rah.star-gate.com, multimedia@FreeBSD.ORG, rhh@ct.picker.com In-Reply-To: <199707211133.VAA10007@godzilla.zeta.org.au> from "Bruce Evans" at Jul 21, 97 09:33:28 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-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'. > > > >I could easily change the return type of > >the PCI attach function. Should I ??? > > If anything is attached above the driver level, then you need a status > from the driver attach to decide whether to clean up or attach more. > For ISA, only interrupts are attached at a high level, but they shouldn't > be, so ISA attach function shouldn't need to return status (but they > should clean up if they fail). I'm not sure about PCI. I think this should be done in a bus-independent way, and surely the safest way is to always return an error code. Then you have the freedom or ignoring it or not. 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 21 06:24:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA13214 for multimedia-outgoing; Mon, 21 Jul 1997 06:24: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 GAA13209 for ; Mon, 21 Jul 1997 06:24:38 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id OAA21169; Mon, 21 Jul 1997 14:21:59 +0200 From: Luigi Rizzo Message-Id: <199707211221.OAA21169@labinfo.iet.unipi.it> Subject: snd970721.tgz To: hasty@rah.star-gate.com (Amancio Hasty) Date: Mon, 21 Jul 1997 14:21:58 +0200 (MET DST) Cc: multimedia@freebsd.org In-Reply-To: <199707210747.AAA00376@rah.star-gate.com> from "Amancio Hasty" at Jul 21, 97 00:47:03 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk http://www.iet.unipi.it/~luigi/snd970721.tgz now it survives the i/o on /dev/audio, although it does not play yet (initialization of the sb registers to generate an interrupt is still missing, maybe tonight...) There were some trivial bugs in the previous versions, like swapping variable names etc., now fixed. I am looking at Mike's idea of using DMA_AUTOMODE and a circular buffer, but unfortunately there are no support routines to read the current transfer status from the dma registers and I have to write them myself. This also means that the old sound driver probably did not really work very reliably, and explains why someone was reporting that pieces of sound were repeating multiple times. 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 21 09:20:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA21462 for multimedia-outgoing; Mon, 21 Jul 1997 09:20:07 -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 JAA21437 for ; Mon, 21 Jul 1997 09:20:01 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id JAA04980; Mon, 21 Jul 1997 09:16:58 -0700 (PDT) Message-Id: <199707211616.JAA04980@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: multimedia@freebsd.org Subject: Re: snd970721.tgz In-reply-to: Your message of "Mon, 21 Jul 1997 14:21:58 +0200." <199707211221.OAA21169@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 09:16:57 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Luigi Rizzo : > http://www.iet.unipi.it/~luigi/snd970721.tgz > > now it survives the i/o on /dev/audio, although it does not play yet > (initialization of the sb registers to generate an interrupt is still > missing, maybe tonight...) > > There were some trivial bugs in the previous versions, like swapping > variable names etc., now fixed. > > I am looking at Mike's idea of using DMA_AUTOMODE and a > circular buffer, but unfortunately there are no support routines to > read the current transfer status from the dma registers and I have to > write them myself. This also means that the old sound driver probably > did not really work very reliably, and explains why someone was > reporting that pieces of sound were repeating multiple times. > To be honest the dma routines are working fine however cards such as the SB are missing interrupts or the auto dma algorithm on the sb side is incorrect. Cheers, Amancio From owner-freebsd-multimedia Mon Jul 21 09:57:59 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA24181 for multimedia-outgoing; Mon, 21 Jul 1997 09:57:59 -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 JAA24173; Mon, 21 Jul 1997 09:57:55 -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 JAA05307; Mon, 21 Jul 1997 09:57:51 -0700 (PDT) Message-Id: <199707211657.JAA05307@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: hackers@freebsd.org cc: multimedia@freebsd.org, Luigi Rizzo Subject: auto dma? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 09:57:51 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk luigi@labinfo.iet.unipi.it said: > I am looking at Mike's idea of using DMA_AUTOMODE and a circular > buffer, but unfortunately there are no support routines to read the > current transfer status from the dma registers and I have to write > them myself. This also means that the old sound driver probably did > not really work very reliably, and explains why someone was reporting > that pieces of sound were repeating multiple times. Does anyone know how to read the current number of bytes transferred in in a dma transfer? It will be kind of nice to know as a safe guard for cards which occasionlly fail to generate an interrupt and yes I do have such a card is the SB16... Tnks, Amancio From owner-freebsd-multimedia Mon Jul 21 10:45:08 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA27904 for multimedia-outgoing; Mon, 21 Jul 1997 10:45:08 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA27882; Mon, 21 Jul 1997 10:44:59 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id DAA24577; Tue, 22 Jul 1997 03:14:44 +0930 (CST) From: Michael Smith Message-Id: <199707211744.DAA24577@genesis.atrad.adelaide.edu.au> Subject: Re: auto dma? In-Reply-To: <199707211657.JAA05307@rah.star-gate.com> from Amancio Hasty at "Jul 21, 97 09:57:51 am" To: hasty@rah.star-gate.com (Amancio Hasty) Date: Tue, 22 Jul 1997 03:14:44 +0930 (CST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG, luigi@labinfo.iet.unipi.it X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty stands accused of saying: > > luigi@labinfo.iet.unipi.it said: > > I am looking at Mike's idea of using DMA_AUTOMODE and a circular > > buffer, but unfortunately there are no support routines to read the > > current transfer status from the dma registers and I have to write > > them myself. This also means that the old sound driver probably did > > not really work very reliably, and explains why someone was reporting > > that pieces of sound were repeating multiple times. > > Does anyone know how to read the current number of bytes transferred in > in a dma transfer? > It will be kind of nice to know as a safe guard for cards which > occasionlly fail to generate an interrupt and yes I do have such a card > is the SB16... This was one of the reasons behind my suggesting that a 1/hz timeout should be running whenever the sound output is running. 1/128th of a second is a fairly short glitch for end-of-sample overrun. If you haven't got an answer by tomorrow (my time; mid-afternoon today your time) I will rummage my Intel databook and get back to you on that one. > Amancio -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Mon Jul 21 11:04:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA29639 for multimedia-outgoing; Mon, 21 Jul 1997 11:04:53 -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 LAA29624; Mon, 21 Jul 1997 11:04:40 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id TAA21422; Mon, 21 Jul 1997 19:01:59 +0200 From: Luigi Rizzo Message-Id: <199707211701.TAA21422@labinfo.iet.unipi.it> Subject: Re: auto dma? To: msmith@atrad.adelaide.edu.au (Michael Smith) Date: Mon, 21 Jul 1997 19:01:59 +0200 (MET DST) Cc: hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG In-Reply-To: <199707211744.DAA24577@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Jul 22, 97 03:14:25 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Amancio Hasty stands accused of saying: > > > > luigi@labinfo.iet.unipi.it said: > > > I am looking at Mike's idea of using DMA_AUTOMODE and a circular > > > buffer, but unfortunately there are no support routines to read the ... > > Does anyone know how to read the current number of bytes transferred in > > in a dma transfer? the intel data sheet for the i82371 (also known as PIIX), a PCI chipset which implements a number of standard isa devices including timer and dma controller, is available at the intel site (www.intel.com). Although it probably is not exactly the same as the original 8237, it myght still give some ideas on what to do. The main problem with old peripherals is that they often did not allow a safe reading of 16-bit registers such as counters, which can be incremented while you read the two pieces. I don't know if this affected the original 8237, but sure was a problem with some old PC timer. Apart from this, I'd look in the PIIX data sheet. Finally, if someone is familiar with Linux or NetBSD kernel (specifically for the isa routines) let me know. 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 21 11:22:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA00814 for multimedia-outgoing; Mon, 21 Jul 1997 11:22:46 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA00807; Mon, 21 Jul 1997 11:22:42 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id DAA24761; Tue, 22 Jul 1997 03:51:39 +0930 (CST) From: Michael Smith Message-Id: <199707211821.DAA24761@genesis.atrad.adelaide.edu.au> Subject: Re: auto dma? In-Reply-To: <199707211701.TAA21422@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 21, 97 07:01:59 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Tue, 22 Jul 1997 03:51:38 +0930 (CST) Cc: msmith@atrad.adelaide.edu.au, hasty@rah.star-gate.com, hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > the intel data sheet for the i82371 (also known as PIIX), a PCI chipset > which implements a number of standard isa devices including timer and > dma controller, is available at the intel site (www.intel.com). > > Although it probably is not exactly the same as the original 8237, it > myght still give some ideas on what to do. It almost certainly uses a "real" 8237 macrocell, so it's likely to behave as near to identically as can be expected. > The main problem with old > peripherals is that they often did not allow a safe reading of 16-bit > registers such as counters, which can be incremented while you read the > two pieces. I don't know if this affected the original 8237, but sure > was a problem with some old PC timer. It was? Unless I'm muchly mistaken, even the 8253 supports the counter latch command. Our gear is full of 8254's; I have bad nightmares every time I have to work on the code that manages them, but for all that they're not _that_ bad. > Finally, if someone is familiar with Linux or NetBSD kernel > (specifically for the isa routines) let me know. Uh, "sorta" (NetBSD). Probably not to the level that you are after though. > Luigi -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Mon Jul 21 19:34:38 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA29245 for multimedia-outgoing; Mon, 21 Jul 1997 19:34: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 TAA29240 for ; Mon, 21 Jul 1997 19:34: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 TAA00497 for ; Mon, 21 Jul 1997 19:34:32 -0700 (PDT) Message-Id: <199707220234.TAA00497@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org Subject: ftp://rah.star-gate.com/pub/guspnp11.tar.gz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jul 1997 19:34:32 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk New sound driver release with important signal handling fix. The nagging problem with the SB16 hanging or repeating sound clips at the end is gone. If you want to know more about the fixes that went in see: sound/REAMDE.GUSPNP in the tar ball. Have fun, Amancio From owner-freebsd-multimedia Mon Jul 21 21:02:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA03511 for multimedia-outgoing; Mon, 21 Jul 1997 21:02:03 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA03500 for ; Mon, 21 Jul 1997 21:01:58 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id AAA11479; Tue, 22 Jul 1997 00:01:51 -0400 (EDT) Message-Id: <199707220401.AAA11479@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Amancio Hasty cc: multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz References: <199707220234.TAA00497@rah.star-gate.com> In-reply-to: Your message of "Mon, 21 Jul 1997 19:34:32 PDT." <199707220234.TAA00497@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jul 1997 00:01:51 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Ok, so I'm trying to bring up a Phoneblaster 33.6 PnP board in a 486 box. The Phoneblaster looks like an interal modem and a Soundblaster 16 all on one board. With funny AT commands to modem, you can interconnect the input and output of the soundcard to the telephone line/modem part of the board. First, I had to make a couple of changes to the pnp.c code that Luigi had modified. The Phoneblaster has like 5 different logical devices on board: - the modem - the IDE interface - the game port/joystick - the audio (with 3 I/O address, an interrupt an a couple of DMA channels) - a "reserved" device with one I/O port that does some other secret stuff I don't know about yet. The problem with the pnp.c code is that it marches through the table trying to match the bd_id field (which smells like it's the individual device identifier), rather then the board serial number which should match multiple entries. --- pnp.c~ Sun Jul 20 01:31:46 1997 +++ pnp.c Sun Jul 20 10:37:13 1997 @@ -520,7 +520,7 @@ #if 1 /* configure device basing on a kernel table */ for (ci = cinfo; (int)ci < ((int)cinfo + sizeof (cinfo)); ci++) { - if (ci->bd_id == p->vendor_id) { + if (ci->serial == p->serial) { unsigned int old; printf (" Configuring (Logical Device %x)\n", ci->ldn != -1 ? ci->ldn : 0); Once I got that changed (and added all the entries to the array of structs defining the devices), I was able to "wake up" the devices on the board. I know that the modem component came alive as I was able to tip at it and chat with AT commands at it. I've just got the guspnp11 code that Amancio announced; I got started with the guspnp10 code before this. I'm running the guspnp8 on my Pentium box with a GUS PnP, which is working just great. Here's the relevent kernel config pieces: controller pnp0 device sio2 at isa? port 0x2a0 tty irq 11 vector siointr controller snd0 device sb0 at isa? port 0x280 irq 10 drq 1 conflicts vector sbintr device sbxvi0 at isa? port? irq? drq 5 conflicts device opl0 at isa? port 0x388 conflicts device sbmidi0 at isa? port 0x330 irq? conflicts When the kernel boots, I get messages like this: sio2 at 0x2a0-0x2a7 irq 11 on isa sio2: type 16550A (Ok, so it found the modem/serial port OK. Based on the messages from the PnP code and this, I'm lead to believe the board is being turned on OK). -- sndtable_probe(2) -- installing card 0 -- Driver name 'SoundBlaster' probe 0xf01ca434 Probing sb at 0x00000280 start sb_dsp_detect, base 0x280 irq 10 -- Hardware probed OK sb0 at 0x280 irq 10 drq 1 flags 0xffffffff on isa sndtable_init_card(2) entered Located card - calling attach routine at 0x280 irq 10 dma 1,7 attach routine finished -- sndtable_probe(6) -- installing card 1 -- Driver name 'SoundBlaster16' probe 0xf01ce1e4 -- Hardware probed OK sbxvi0 at ? irq 31 drq 5 flags 0xffffffff on isa sndtable_init_card(6) entered Located card - calling attach routine at 0xffffffff irq -1 dma 5,7 attach routine finished create_intr: requested irq31 too high, limit is 15 -- sndtable_probe(1) -- installing card 2 -- Driver name 'OPL-2/OPL-3 FM' probe 0xf01c8b74 -- Hardware probed OK opl0 at 0x388 irq 31 on isa sndtable_init_card(1) entered Located card - calling attach routine at 0x388 attach routine finished create_intr: requested irq31 too high, limit is 15 -- sndtable_probe(7) -- installing card 3 -- Driver name 'SB16 MIDI' probe 0xf01ce63c -- Hardware probed OK sbmidi0 at 0x330 irq 31 on isa sndtable_init_card(7) entered Located card - calling attach routine at 0x330 irq -1 attach routine finished create_intr: requested irq31 too high, limit is 15 Should I be worried about the -1/31 irq indications here? Also, does this /dev/sndstat look reasonable; compared to the GUS PnP on another box, it looks a little bare: VoxWare Sound Driver:3.5-alpha11-9707221 (Mon Jul 21 18:41:01 PDT 1997 Amancio Hasty@rah.star-gate.com) Config options: Installed drivers: Type 1: OPL-2/OPL-3 FM Type 2: SoundBlaster Type 6: SoundBlaster16 Type 7: SB16 MIDI Card config: SoundBlaster at 0x280 irq 10 drq 1,7 SoundBlaster16 at 0xffffffff irq 1 drq 5,7 OPL-2/OPL-3 FM at 0x388 irq 1 SB16 MIDI at 0x330 irq 1 Audio devices: 0: SoundBlaster 16 4.13 Synth devices: 0: Yamaha OPL-3 Midi devices: 0: SoundBlaster 16 Midi Timers: 0: System clock Mixers: 0: SoundBlaster I'm real excited about the sound driver work; when all this comes together, I expect to have a pretty annoying voice mail system at home :-) louie From owner-freebsd-multimedia Mon Jul 21 22:06:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA06367 for multimedia-outgoing; Mon, 21 Jul 1997 22:06: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 WAA06362 for ; Mon, 21 Jul 1997 22:06:40 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA22271; Tue, 22 Jul 1997 06:04:46 +0200 From: Luigi Rizzo Message-Id: <199707220404.GAA22271@labinfo.iet.unipi.it> Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz To: louie@TransSys.COM (Louis A. Mamakos) Date: Tue, 22 Jul 1997 06:04:46 +0200 (MET DST) Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG In-Reply-To: <199707220401.AAA11479@whizzo.TransSys.COM> from "Louis A. Mamakos" at Jul 22, 97 00:01:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > First, I had to make a couple of changes to the pnp.c code that Luigi > had modified. The Phoneblaster has like 5 different logical devices > on board: > - the modem > - the IDE interface > - the game port/joystick > - the audio (with 3 I/O address, an interrupt an a couple of DMA channels) > - a "reserved" device with one I/O port that does some other secret > stuff I don't know about yet. > > The problem with the pnp.c code is that it marches through the table > trying to match the bd_id field (which smells like it's the individual > device identifier), rather then the board serial number which should > match multiple entries. actually the original code by Sujal used the serial number, but that does not identify the board at all, and many cards have it set to values such as -1, 1, or 0. So you would risk false detections. The bd_id field is supposed to identify the board type, so you should not have false detections (unless you have two boards of the same kind, but for that I actually have a different mechanism, which is now working in the latest version of the PnP code included with my sound driver snapshots). What's wrong with using the bd_id field and put the right one for the board you have ? It is much safer. Also can you run pnpinfo on your board and send me the results ? I would like to add support for it (and other PnP boards) in my code, to test how the new config stuff works with it. > sndtable_init_card(7) entered > Located card - calling attach routine > at 0x330 irq -1 > attach routine finished > > create_intr: requested irq31 too high, limit is 15 > > Should I be worried about the -1/31 irq indications here? Also, does this yes :) the problem is the code does not realize that -1 means no interrupt, and tries to register an interrupt anyways. > Card config: > SoundBlaster at 0x280 irq 10 drq 1,7 > SoundBlaster16 at 0xffffffff irq 1 drq 5,7 > OPL-2/OPL-3 FM at 0x388 irq 1 > SB16 MIDI at 0x330 irq 1 except for the "7" as secondary dma (which should really mean that the board does not have a dma). Probably my fault again, since I thought that no flags specified means flags=0 whereas it seems it is flags=-1 Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Tue Jul 22 01:10:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA15555 for multimedia-outgoing; Tue, 22 Jul 1997 01:10:39 -0700 (PDT) Received: from mail.tamu.edu (mail.tamu.edu [128.194.103.28]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA15532; Tue, 22 Jul 1997 01:10:32 -0700 (PDT) Received: from dropzone.tamu.edu (dropzone.tamu.edu [165.91.210.99]) by mail.tamu.edu (8.8.5/8.8.5) with SMTP id DAA27674; Tue, 22 Jul 1997 03:10:31 -0500 (CDT) Received: from jumprun.tamu.edu by dropzone.tamu.edu (SMI-8.6/SMI-SVR4) id DAA28936; Tue, 22 Jul 1997 03:06:10 -0500 Received: from localhost by jumprun.tamu.edu (SMI-8.6/SMI-SVR4) id DAA03279; Tue, 22 Jul 1997 03:10:40 -0500 Date: Tue, 22 Jul 1997 03:10:40 -0500 (CDT) From: "Jo, SanKu" To: freebsd-multimedia@freebsd.org cc: freebsd-hackers@freebsd.org Subject: VIF : the bandwidth taken by multicasting packet 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 Howdy ! Because I hope to check the Bandwidth taken by the IP multicastingrouter(FreeBSD box), I tried to use iotcl(Channel_descriptor, SIOCGETVIFCNT, struct *sioc_vif_req). I heard this function retruns the input and output Bandwidth. There are two cases for testing. 1. When Host-A is source and Host-B is receiver, the Bandwidth rate value returned by the function is correct. 2. When Host-B is source and Host-A is receiver, the Bandwidth rate value(out_bytes) retruned by the function is wrong. Even the case witout any receiver in Backbone(as Host-A), the function returns the whole bandwidth rate(in_bytes) which is taken by the source, HOST-B. I think the prune function is all right. Below is my configuration with multicast routers denoted by asterisks: ======++=====BackBOne <--in || -->out || HOST-A VIF Research Subnet HOST-B ------++---------- --------------------- || ---------- |sparc* | ethernet | freebsd 2.1 * | || |sparc | | 128.194.169.93 |-----------|169.53 166.4 |---++-------| 166.5 | | 3.8 | | 3.3 | || | | ------------------ --------------------- || ---------- Its' default gateway is freebsd How can I get correct bandwidth for the second case ? Is it possible or not to get it ? And where can I get some information for hacking the multicasting function in FreeBSD ? Any comment will be very appreciated. Thank you for your kind attention ! Best regards, Jo, SanKu Texas A&M University. Http://ee.tamu.edu/~skjo From owner-freebsd-multimedia Tue Jul 22 06:18:23 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id GAA27241 for multimedia-outgoing; Tue, 22 Jul 1997 06:18:23 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id GAA27234 for ; Tue, 22 Jul 1997 06:18:19 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id IAA15852; Tue, 22 Jul 1997 08:59:42 -0400 (EDT) Message-Id: <199707221259.IAA15852@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Luigi Rizzo cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz References: <199707220404.GAA22271@labinfo.iet.unipi.it> In-reply-to: Your message of "Tue, 22 Jul 1997 06:04:46 +0200." <199707220404.GAA22271@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_-17319716660" Date: Tue, 22 Jul 1997 08:59:41 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multipart MIME message. --==_Exmh_-17319716660 Content-Type: text/plain; charset=us-ascii > actually the original code by Sujal used the serial number, but that > does not identify the board at all, and many cards have it set to > values such as -1, 1, or 0. So you would risk false detections. Yeah, I've seen this too. > The bd_id field is supposed to identify the board type, so you > should not have false detections (unless you have two boards of > the same kind, but for that I actually have a different mechanism, > which is now working in the latest version of the PnP code included > with my sound driver snapshots). What's wrong with using the bd_id > field and put the right one for the board you have ? It is much > safer. Ah, perhaps I've confused what the correct contents of the bd_id field ought to be. For some reason (ok, it was late!) I was putting in the logical device ID for the device on the board, rather than the board identifier. At the time, I assumed that was being used, somehow, to tie the entry in the table to the (possibly multiple) devices on the card. Also, I had to change the #ifdef to turn on the code that looked in that table. > Also can you run pnpinfo on your board and send me the results ? I > would like to add support for it (and other PnP boards) in my code, to > test how the new config stuff works with it. Sure, it's included below. > yes :) the problem is the code does not realize that -1 means no > interrupt, and tries to register an interrupt anyways. Fortunately, it fails which makes things work OK :-) > > Card config: > > SoundBlaster at 0x280 irq 10 drq 1,7 > > SoundBlaster16 at 0xffffffff irq 1 drq 5,7 > > OPL-2/OPL-3 FM at 0x388 irq 1 > > SB16 MIDI at 0x330 irq 1 > > except for the "7" as secondary dma (which should really mean that the > board does not have a dma). Probably my fault again, since I thought > that no flags specified means flags=0 whereas it seems it is flags=-1 Hmm. The other thing of concern is the irq 1 associated with the Soundblaster16 device. Oh well, details. I was only able to do a quick "cat foo.au > /dev/audio" test last night, and it seems to be working. I'll beat on it a bit more later tonight. louie --==_Exmh_-17319716660 Content-Type: text/plain ; name="pnp"; charset=us-ascii Content-Description: pnp Content-Disposition: attachment; filename="pnp" Checking for Plug-n-Play devices... Trying Read_Port at 203... Card assigned CSN #1 Board Vendor ID CTL3002, Serial Number 0x00005f7c PnP Version 1.0, Vendor Version 48 Device Description: Creative Phone Blaster 28.8/33.6 Logical Device ID: CTL0031 0x31008c0e #0 Device Description: Audio TAG Start DF Good Configuration IRQ: 5 - only one type (true/edge) DMA: channel(s) 1 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x220, alignment 0x1, len 0x10 [16-bit addr] I/O Range 0x330 .. 0x330, alignment 0x1, len 0x2 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 6 7 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 6 7 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode DMA: channel(s) 5 6 7 16-bit, not a bus master, , count by word, Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] I/O Range 0x388 .. 0x388, alignment 0x1, len 0x4 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 5 7 10 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] I/O Range 0x300 .. 0x330, alignment 0x30, len 0x2 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 5 7 10 11 - only one type (true/edge) DMA: channel(s) 0 1 3 8-bit, not a bus master, count by byte, , Compatibility mode I/O Range 0x220 .. 0x280, alignment 0x20, len 0x10 [16-bit addr] TAG End DF Logical Device ID: CTL2011 0x11208c0e #1 Compatible Device ID: PNP0600 (0006d041) Device Description: IDE TAG Start DF Good Configuration IRQ: 10 - only one type (true/edge) I/O Range 0x168 .. 0x168, alignment 0x1, len 0x8 [16-bit addr] I/O Range 0x36e .. 0x36e, alignment 0x1, len 0x2 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 11 - only one type (true/edge) I/O Range 0x1e8 .. 0x1e8, alignment 0x1, len 0x8 [16-bit addr] I/O Range 0x3ee .. 0x3ee, alignment 0x1, len 0x2 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 10 11 15 - only one type (true/edge) I/O Range 0x180 .. 0x1b8, alignment 0x8, len 0x8 [16-bit addr] I/O Range 0x306 .. 0x33e, alignment 0x8, len 0x2 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 15 - only one type (true/edge) I/O Range 0x170 .. 0x170, alignment 0x1, len 0x8 [16-bit addr] I/O Range 0x376 .. 0x376, alignment 0x1, len 0x1 [16-bit addr] TAG End DF Logical Device ID: CTL7fff 0xff7f8c0e #2 Device Description: Reserved I/O Range 0x304 .. 0x33c, alignment 0x8, len 0x1 [16-bit addr] Logical Device ID: CTL7001 0x01708c0e #3 Device Description: Game I/O Range 0x200 .. 0x200, alignment 0x1, len 0x8 [16-bit addr] Logical Device ID: CTL3001 0x01308c0e #4 Device Description: COM TAG Start DF Good Configuration IRQ: 3 4 5 7 10 11 15 - only one type (true/edge) I/O Range 0x3e8 .. 0x3e8, alignment 0x1, len 0x8 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 3 4 5 7 10 11 15 - only one type (true/edge) I/O Range 0x2e8 .. 0x2e8, alignment 0x1, len 0x8 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 3 - only one type (true/edge) I/O Range 0x2f8 .. 0x2f8, alignment 0x1, len 0x8 [16-bit addr] TAG Start DF Acceptable Configuration IRQ: 4 - only one type (true/edge) I/O Range 0x3f8 .. 0x3f8, alignment 0x1, len 0x8 [16-bit addr] TAG Start DF Sub-optimal Configuration IRQ: 3 4 5 7 10 11 15 - only one type (true/edge) I/O Range 0x2a0 .. 0x2d8, alignment 0x8, len 0x8 [16-bit addr] TAG End DF End Tag Successfully got 89 resources, 5 logical fdevs -- card select # 0x0001 Logical device #0 IO: 0x0280 0x0330 0x0388 0x0000 0x0000 0x0000 0x0000 0x0000 IRQ 10 0 DMA 1 5 IO range check 0x00 activate 0x01 Logical device #1 IO: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x00 Logical device #2 IO: 0x0320 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x01 Logical device #3 IO: 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 IRQ 0 0 DMA 4 4 IO range check 0x00 activate 0x00 Logical device #4 IO: 0x02a0 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 0x0000 IRQ 11 0 DMA 4 4 IO range check 0x00 activate 0x01 --==_Exmh_-17319716660-- From owner-freebsd-multimedia Tue Jul 22 07:45:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02405 for multimedia-outgoing; Tue, 22 Jul 1997 07:45:50 -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 HAA01892; Tue, 22 Jul 1997 07:38:14 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA22798; Tue, 22 Jul 1997 15:32:17 +0200 From: Luigi Rizzo Message-Id: <199707221332.PAA22798@labinfo.iet.unipi.it> Subject: polling the status of a dma channel To: hackers@freebsd.org, multimedia@freebsd.org Date: Tue, 22 Jul 1997 15:32:17 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Recently I and others had a need to poll the status of a dma channel to determine if a transfer was proceeding or not. I came out with the following function which I placed in /sys/i386/isa/isa.c -- the place I believe it belongs to. Maybe we should consider adding this function to isa.c ? It would be useful for the sound driver and probably other drivers as well. Cheers Luigi ------------- /* * isa_dmapoll returns the number of pending bytes for a dma transfer * on the given channel. */ int isa_dmapoll(int chan) { u_long phy = 0 ; u_long cnt = 0 ; u_long flags ; int waport; if (dma_inuse & (1 << chan) == 0) { printf("chan %d not acquired\n", chan); return -1 ; } if (dma_busy & (1 << chan) == 0) { printf("chan %d not busy\n", chan); return -2 ; } flags = splhigh(); if ((chan & 4) == 0) { /* 8-bit channel */ outb(DMA1_FFC, 0); waport = DMA1_CHN(chan); phy= inb(waport) + (inb(waport) <<8) + (inb(dmapageport[chan]) <<16 ); cnt = inb(waport+1) + (inb(waport+1)<<8) +1; cnt &= 0xffff ; } else { outb(DMA2_FFC, 0); waport = DMA2_CHN(chan - 4); phy= inb(waport) + (inb(waport) <<8) + (inb(dmapageport[chan]) <<16 ); cnt = inb(waport+1) + (inb(waport+1)<<8) + 1; phy <<= 1; cnt <<= 1; cnt &= 0x1ffff ; } splx(flags); return cnt ; } Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Tue Jul 22 09:27:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA09087 for multimedia-outgoing; Tue, 22 Jul 1997 09:27: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 JAA09082 for ; Tue, 22 Jul 1997 09:27: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 JAA05004; Tue, 22 Jul 1997 09:26:34 -0700 (PDT) Message-Id: <199707221626.JAA05004@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Louis A. Mamakos" cc: Luigi Rizzo , multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz In-reply-to: Your message of "Tue, 22 Jul 1997 08:59:41 EDT." <199707221259.IAA15852@whizzo.TransSys.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 22 Jul 1997 09:26:34 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of "Louis A. Mamakos" : > > yes :) the problem is the code does not realize that -1 means no > > interrupt, and tries to register an interrupt anyways. > > Fortunately, it fails which makes things work OK :-) Hi, I started to smooth that part out last nite and will be done tonite. Cheers, Amancio From owner-freebsd-multimedia Tue Jul 22 11:09:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA15703 for multimedia-outgoing; Tue, 22 Jul 1997 11:09:55 -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 LAA15697 for ; Tue, 22 Jul 1997 11:09:52 -0700 (PDT) Received: from sister.ludd.luth.se (dateck@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id UAA26558 for ; Tue, 22 Jul 1997 20:09:46 +0200 From: Tomas Klockar Received: (dateck@localhost) by sister.ludd.luth.se (8.6.11/8.6.11) id UAA00802 for multimedia@FreeBSD.ORG; Tue, 22 Jul 1997 20:09:39 +0200 Message-Id: <199707221809.UAA00802@sister.ludd.luth.se> Subject: problems with guspnp pro & vat To: multimedia@FreeBSD.ORG Date: Tue, 22 Jul 1997 20:09:39 +0200 (MET DST) X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi! I have a small problem. When I use vat i can't send anything. I have just compiled in guspnp11.tar.gz in my kernel. It haven't worked before and it's still not working. My sound card is a Real GUS PnP Pro. Dvs I bought it this way. I have 8MB ram on it. I have Their mic and its plugged in to the soundcard. Is this a vat problem or are anything broken in guspnp11 ? I would guess vat but... Version of vat 4.0b2 Playing works perfect. Here's cat /dev/sndstat VoxWare Sound Driver:3.5-alpha11-9707221 (Mon Jul 21 18:41:01 PDT 1997 Amancio Hasty@rah.star-gate.com) Config options: Installed drivers: Type 4: Gravis Ultrasound Card config: Gravis Ultrasound at 0x220 irq 5 drq 3,1 Audio devices: 0: GUS PNP (CS4231) (DUPLEX) 1: Gravis UltraSound (DUPLEX) Synth devices: 0: Gravis PNP (1024k) Midi devices: 0: Gravis UltraSound Midi Timers: 0: System clock 1: GUS Mixers: 0: AD1848/CS4248/CS4231 1: Gravis Ultrasound and dmesg avail memory = 18411520 (17980K bytes) Probing for devices on the ISA bus: sc0 at 0x60-0x6f irq 1 on motherboard sc0: VGA color <16 virtual consoles, flags=0x0> sio0 at 0x3f8-0x3ff irq 4 on isa sio0: type 16450 sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16450 lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface mse0: disabled, not probed. psm0: disabled, not probed. fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: NEC 765 fd0: 1.44MB 3.5in wdc0 at 0x1f0-0x1f7 irq 14 flags 0x80ff80ff on isa wdc0: unit 0 (wd0): , multi-block-16 wd0: 2446MB (5009760 sectors), 4970 cyls, 16 heads, 63 S/T, 512 B/S wdc0: unit 1 (wd1): , multi-block-16 wd1: 520MB (1065456 sectors), 1057 cyls, 16 heads, 63 S/T, 512 B/S wdc1 not found at 0x170 aic0 at 0x140-0x15f irq 11 on isa (aic0:5:0): "IOMEGA ZIP 100 N*32" type 0 removable SCSI 2 sd0(aic0:5:0): Direct-Access sd0(aic0:5:0): ILLEGAL REQUEST asc:24,0 Invalid field in CDB sd0 could not mode sense (4). Using ficticious geometry 96MB (196608 512 byte sectors) 1 3C5x9 board(s) on ISA found at 0x300 ep0 at 0x300-0x30f irq 10 on isa ep0: aui/utp/bnc[*UTP*] address 00:20:af:42:ee:33 npx0 on motherboard npx0: INT 16 interface joy0 at 0x201 on isa joy0: joystick -- sndtable_probe(4) -- installing card 0 -- Driver name 'Gravis Ultrasound' probe 0xf01d1888 Checking for GUS Plug-n-Play ... Board Vendor ID: GRV0001 Board Serial Number: 00000001 -- Hardware probed OK gus0 at 0x220 irq 5 drq 3 flags 0x101 on isa sndtable_init_card(4) entered Located card - calling attach routine ad1848_detect(32c) ad1848_detect() - step A ad1848_detect() - step B, test indirect register ad1848_detect() - step C ad1848_detect() - step D, last 4 bits of I12 readonly ad1848: detect - chip revision 0x0a ad1848_detect() - step F ad1848_detect() - step G ad1848_detect() - step H ad1848_detect() - step I ad1848_detect() - step I ad1848_detect() - step K ad1848_detect() - step L ad1848_detect() - Detected OK ad1848_detect(32c) at 0x32c dma 1,3 at 0x220 irq 5 dma 3,1 attach routine finished isa_dmastart: channel 3 busy isa_dmastart: channel 3 busy isa_dmastart: channel 1 busy Suggestions, comments, questions? I would realy like to know whats not working. Thank you. /Tomas -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se Mob: +46-70-664 33 26 | qtxtkl@etxb.ericsson.se From owner-freebsd-multimedia Tue Jul 22 14:23:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA29392 for multimedia-outgoing; Tue, 22 Jul 1997 14:23:45 -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 OAA29384; Tue, 22 Jul 1997 14:23:42 -0700 (PDT) Received: from x14.mi.uni-koeln.de (annexr2-45.slip.Uni-Koeln.DE) by Octopussy.MI.Uni-Koeln.DE with SMTP id AA19139 (5.67b/IDA-1.5); Tue, 22 Jul 1997 23:23:00 +0200 Received: (from se@localhost) by x14.mi.uni-koeln.de (8.8.6/8.6.9) id XAA17852; Tue, 22 Jul 1997 23:22:02 +0200 (CEST) X-Face: " Date: Tue, 22 Jul 1997 23:22:01 +0200 From: Stefan Esser To: Bruce Evans Cc: hackers@FreeBSD.ORG, luigi@labinfo.iet.unipi.it, multimedia@FreeBSD.ORG, rhh@ct.picker.com Subject: Re: snd driver attach routine References: <199707211133.VAA10007@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.74 In-Reply-To: <199707211133.VAA10007@godzilla.zeta.org.au>; from Bruce Evans on Mon, Jul 21, 1997 at 09:33:47PM +1000 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Jul 21, Bruce Evans wrote: > >I could easily change the return type of > >the PCI attach function. Should I ??? > > If anything is attached above the driver level, then you need a status > from the driver attach to decide whether to clean up or attach more. > For ISA, only interrupts are attached at a high level, but they shouldn't > be, so ISA attach function shouldn't need to return status (but they > should clean up if they fail). I'm not sure about PCI. Ok. I'll make the PCI code in -current expect the drivers' attach() functions to return a success indication, but will for now leave the code in 2.2 alone ... Don't know when I'll get around to adding the new PCI probe/attach framework, so don't hold your your breath :) Regards, STefan From owner-freebsd-multimedia Tue Jul 22 16:01:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA04915 for multimedia-outgoing; Tue, 22 Jul 1997 16:01:36 -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 QAA04909 for ; Tue, 22 Jul 1997 16:01:32 -0700 (PDT) Received: from sister.ludd.luth.se (dateck@sister.ludd.luth.se [130.240.16.77]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id BAA01881; Wed, 23 Jul 1997 01:01:23 +0200 From: Tomas Klockar Received: (dateck@localhost) by sister.ludd.luth.se (8.6.11/8.6.11) id BAA01899; Wed, 23 Jul 1997 01:01:17 +0200 Message-Id: <199707222301.BAA01899@sister.ludd.luth.se> Subject: Re: problems with guspnp pro & vat To: dateck@ludd.luth.se (Tomas Klockar) Date: Wed, 23 Jul 1997 01:01:16 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199707221809.UAA00802@sister.ludd.luth.se> from Tomas Klockar at "Jul 22, 97 08:09:39 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry for bladdering. I were in a hurry. What I meant were recording/sending with vat doesn't work. Can anyone please help me with this? /Tomas -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se Mob: +46-70-664 33 26 | qtxtkl@etxb.ericsson.se From owner-freebsd-multimedia Tue Jul 22 18:41:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA14316 for multimedia-outgoing; Tue, 22 Jul 1997 18:41:22 -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 SAA14166 for ; Tue, 22 Jul 1997 18:39:46 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Tue, 22 Jul 1997 21:38:03 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA09814; Tue, 22 Jul 97 21:36:49 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id VAA08310; Tue, 22 Jul 1997 21:34:24 -0400 Message-Id: <19970722213424.11237@ct.picker.com> Date: Tue, 22 Jul 1997 21:34:24 -0400 From: Randall Hopper To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz References: <199707220234.TAA00497@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707220234.TAA00497@rah.star-gate.com>; from Amancio Hasty on Mon, Jul 21, 1997 at 07:34:32PM -0700 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk |New sound driver release with important signal handling fix. |The nagging problem with the SB16 hanging or repeating |sound clips at the end is gone. | |If you want to know more about the fixes that went in see: |sound/REAMDE.GUSPNP in the tar ball. Just got a chance to pull it and run it past all the audio tests I can think of with my SB32. Here's the results: 1) Thanks for the good work on repeating and close() hanging fix! Did not hear any repeats, and when I allowed audio play apps to finish playing and terminate normally, I never saw them hang on close(). The only time I saw a hang was when I Ctrl-Ced the app in the middle of playback (e.g. mpg123); not all the time--sporatically as before. So as far as this specific problem goes (hanging), this driver is better than the checked-in version. 2) Load pops on start/end of AU playback. Still there. Don't see this with the checked-in driver. 3) Attempts to record 16-bit samples gives "Input/Output Error" now instead of the "Interrupted system call" before. For each failure, I get one of these in my console: Sound: DMA (input) timed out - IRQ/DRQ config error? 16-bit record works with the checked-in driver. 4) I think Louis or you mentioned this, but I also see probe output that's a little strange. Looks fine except for that dma 7 in there. Could this be related to the DMA error doing 16-bit record? Probing sb at 0x00000220 start sb_dsp_detect, base 0x220 irq 5 -- Hardware probed OK sb0 at 0x220 irq 5 drq 1 flags 0xffffffff on isa sndtable_init_card(2) entered Located card - calling attach routine at 0x220 irq 5 dma 1,7 <-------------------- attach routine finished ... -- Driver name 'SoundBlaster16' probe 0xf01e9098 -- Hardware probed OK sbxvi0 at 0x0 drq 5 flags 0xffffffff on isa sndtable_init_card(6) entered Located card - calling attach routine at 0x000 irq -1 dma 5,7 <-------------------- attach routine finished That's about it. Hope this helps, and thanks for the hard work! Randall From owner-freebsd-multimedia Tue Jul 22 20:58:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA21868 for multimedia-outgoing; Tue, 22 Jul 1997 20:58:48 -0700 (PDT) Received: from netcom2.netcom.com (hasty@netcom2.netcom.com [192.100.81.108]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id UAA21858 for ; Tue, 22 Jul 1997 20:58:45 -0700 (PDT) Received: (from hasty@localhost) by netcom2.netcom.com (8.6.13/Netcom) id UAA09240; Tue, 22 Jul 1997 20:58:44 -0700 Date: Tue, 22 Jul 1997 20:58:44 -0700 From: hasty@netcom.com (Amancio Hasty Jr) Message-Id: <199707230358.UAA09240@netcom2.netcom.com> To: multimedia@freebsd.org Subject: T1 to my ISP is down Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I hope that the line comes up soon. Cheers, Amancio From owner-freebsd-multimedia Tue Jul 22 23:21:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA27447 for multimedia-outgoing; Tue, 22 Jul 1997 23:21:46 -0700 (PDT) Received: from upsmot03.msn.com (upsmot03.msn.com [204.95.110.85]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA27442 for ; Tue, 22 Jul 1997 23:21:44 -0700 (PDT) Received: from upmajb04.msn.com ([204.95.110.81]) by upsmot03.msn.com (8.6.8.1/Configuration 4) with SMTP id XAA18381 for ; Tue, 22 Jul 1997 23:16:46 -0700 Date: Wed, 23 Jul 97 06:13:46 UT From: "Yuuichi Itakura" Message-Id: To: multimedia@freebsd.org Subject: Inquiry Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi, I found your homepage via Magellan Search. I recently purchased a vi deo capture board with a bt848 chip. Although the device is recogniz ed 'working properly' in the Device Manager of W95, the Microsoft Vid Cap returns "Cannot initialize the device". How do I cope with this? Do I need a new driver? Please advice. Thank you very much. By the way, was Brooktree acqui red by Rockwell Semiconductors? From owner-freebsd-multimedia Wed Jul 23 01:16:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA03361 for multimedia-outgoing; Wed, 23 Jul 1997 01:16:17 -0700 (PDT) Received: from genesis.atrad.adelaide.edu.au (genesis.atrad.adelaide.edu.au [129.127.96.120]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id BAA03355; Wed, 23 Jul 1997 01:16:14 -0700 (PDT) Received: (from msmith@localhost) by genesis.atrad.adelaide.edu.au (8.8.5/8.7.3) id RAA08097; Wed, 23 Jul 1997 17:44:32 +0930 (CST) From: Michael Smith Message-Id: <199707230814.RAA08097@genesis.atrad.adelaide.edu.au> Subject: Re: polling the status of a dma channel In-Reply-To: <199707221332.PAA22798@labinfo.iet.unipi.it> from Luigi Rizzo at "Jul 22, 97 03:32:17 pm" To: luigi@labinfo.iet.unipi.it (Luigi Rizzo) Date: Wed, 23 Jul 1997 17:44:31 +0930 (CST) Cc: hackers@FreeBSD.ORG, multimedia@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL28 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo stands accused of saying: > > I came out with the following function which I placed in > /sys/i386/isa/isa.c -- the place I believe it belongs to. > > Maybe we should consider adding this function to isa.c ? It would be > useful for the sound driver and probably other drivers as well. It looks pretty good to me. If there are no objections, I'll commit it tonight... > Cheers -- ]] Mike Smith, Software Engineer msmith@gsoft.com.au [[ ]] Genesis Software genesis@gsoft.com.au [[ ]] High-speed data acquisition and (GSM mobile) 0411-222-496 [[ ]] realtime instrument control. (ph) +61-8-8267-3493 [[ ]] Unix hardware collector. "Where are your PEZ?" The Tick [[ From owner-freebsd-multimedia Wed Jul 23 01:49:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA05048 for multimedia-outgoing; Wed, 23 Jul 1997 01:49: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 BAA05043 for ; Wed, 23 Jul 1997 01:49: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 BAA01079; Wed, 23 Jul 1997 01:49:41 -0700 (PDT) Message-Id: <199707230849.BAA01079@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz In-reply-to: Your message of "Tue, 22 Jul 1997 21:34:24 EDT." <19970722213424.11237@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 01:49:41 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tnks. My ISP's T1 is back up again. Just finished cleaning up all the debugging messages and we now have proper reporting. The hang on close is still with us however the process will exit after 10 seconds. The problem is this in sb16_dsp:dsp_output_block ... sb_dsp_command(0x41); sb_dsp_command((u_char) ((dsp_current_speed >> 8) & 0xff)); sb_dsp_command((u_char) (dsp_current_speed & 0xff)); sb_dsp_command((u_char) (dsp_16bit ? 0xb6 : 0xc6)); dsp_count = cnt; sb_dsp_command((u_char) ((dsp_stereo ? 0x20 : 0) + (dsp_16bit ? 0x10 : 0))); sb_dsp_command01((u_char) (cnt & 0xff)); sb_dsp_command((u_char) (cnt >> 8)); Does anyone know how to initiate a partial dma request while doing auto dma for a SB16 ? I don't know the SB chipset .... ... I will try to track down the click and pops and why 16 bit recording is not working. The latter one should not be too hard to track down . The click and pop at the beginning of a sound stream is an interesting problem . I have a quick idea on how to get rid of so with a little luck should have another driver ready tomorrow. Regards, Amancio >From The Desk Of Randall Hopper : > |New sound driver release with important signal handling fix. > |The nagging problem with the SB16 hanging or repeating > |sound clips at the end is gone. > | > |If you want to know more about the fixes that went in see: > |sound/REAMDE.GUSPNP in the tar ball. > > Just got a chance to pull it and run it past all the audio tests I can > think of with my SB32. Here's the results: > > 1) Thanks for the good work on repeating and close() hanging fix! Did > not hear any repeats, and when I allowed audio play apps to finish > playing and terminate normally, I never saw them hang on close(). > > The only time I saw a hang was when I Ctrl-Ced the app in the middle > of playback (e.g. mpg123); not all the time--sporatically as before. > > So as far as this specific problem goes (hanging), this driver is better > than the checked-in version. > > 2) Load pops on start/end of AU playback. Still there. Don't see this > with the checked-in driver. > > 3) Attempts to record 16-bit samples gives "Input/Output Error" now instead of the "Interrupted system call" before. For each failure, I get one of > these in my console: > > Sound: DMA (input) timed out - IRQ/DRQ config error? > > 16-bit record works with the checked-in driver. > > 4) I think Louis or you mentioned this, but I also see probe output that's > a little strange. Looks fine except for that dma 7 in there. Could this > be related to the DMA error doing 16-bit record? > > > Probing sb at 0x00000220 > start sb_dsp_detect, base 0x220 irq 5 > -- Hardware probed OK > sb0 at 0x220 irq 5 drq 1 flags 0xffffffff on isa > sndtable_init_card(2) entered > Located card - calling attach routine > at 0x220 irq 5 dma 1,7 <-------------------- > attach routine finished > > ... > > -- Driver name 'SoundBlaster16' probe 0xf01e9098 > -- Hardware probed OK > sbxvi0 at 0x0 drq 5 flags 0xffffffff on isa > sndtable_init_card(6) entered > Located card - calling attach routine > at 0x000 irq -1 dma 5,7 <-------------------- > attach routine finished > > > That's about it. Hope this helps, and thanks for the hard work! > > Randall From owner-freebsd-multimedia Wed Jul 23 04:52:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA12173 for multimedia-outgoing; Wed, 23 Jul 1997 04:52:06 -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 EAA12166 for ; Wed, 23 Jul 1997 04:52:04 -0700 (PDT) Received: from father.ludd.luth.se (dateck@father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id NAA11136; Wed, 23 Jul 1997 13:52:00 +0200 From: Tomas Klockar Received: (dateck@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id NAA03247; Wed, 23 Jul 1997 13:52:06 +0200 Message-Id: <199707231152.NAA03247@father.ludd.luth.se> Subject: Re: problems with guspnp pro & vat To: dwhite@resnet.uoregon.edu Date: Wed, 23 Jul 1997 13:52:06 +0200 (MET DST) Cc: dateck@ludd.luth.se, multimedia@FreeBSD.ORG In-Reply-To: from Doug White at "Jul 22, 97 07:47:20 pm" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Doug White: > On Wed, 23 Jul 1997, Tomas Klockar wrote: > > > Sorry for bladdering. > > I were in a hurry. > > What I meant were recording/sending with vat doesn't work. > > Can anyone please help me with this? > > It works OK with guspnp6. Yeah, I'm behind the times, but if it works, > don't fix it. :) > I had this problem before so I have tried guspnp4 guspnp5 guspnp6 guspnp11 with the same result. I used to think this were because there were no full duplex, but that doesn't matter, so I am starting to belive that the guspnp isn't properly initilized. You see I have no Plag-and-Pray bios. I used to use the pnp patch to freebsd to initilize my plug and play devices. That patch doesn't work with the guspnp sound packet. The reason is that they used the same names for the plug and play devices. I can fix this by changing the names, but that still doesn't fix my problem. I bet all of you have plug-and-pray bios. I think it would be nice to fix this and I would try to help if I can. You know I'm an engineer so if it's not broken it doesn't have enough features yet :) Sincerely, /Tomas -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se Mob: +46-70-664 33 26 | qtxtkl@etxb.ericsson.se From owner-freebsd-multimedia Wed Jul 23 08:57:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA26486 for multimedia-outgoing; Wed, 23 Jul 1997 08:57:06 -0700 (PDT) Received: from bessie.eunet.fi (bessie.eunet.fi [192.26.119.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id IAA26479 for ; Wed, 23 Jul 1997 08:57:01 -0700 (PDT) Received: from savolai.fi (voxware.pp.fi [193.66.8.57]) by bessie.eunet.fi (8.8.5/8.8.3) with ESMTP id SAA19470; Wed, 23 Jul 1997 18:56:51 +0300 (EDT) Received: from localhost (hannu@localhost) by savolai.fi (8.8.3/8.7.3) with SMTP id SAA00709; Wed, 23 Jul 1997 18:19:08 +0300 X-Authentication-Warning: voxware.savolai.fi: hannu owned process doing -bs Date: Wed, 23 Jul 1997 18:19:08 +0300 (EET DST) From: Hannu Savolainen X-Sender: hannu@voxware To: "J. Utz" cc: hannu@voxware.pp.fi, multimedia@freebsd.org Subject: Re: use of maui.c from uss/lite permission? In-Reply-To: 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 On Sat, 19 Jul 1997, J. Utz wrote: > 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. The driver is GPLed so you have freedom to use the code as long as it doesn't violate the rules defined by GPL. Unfortunately I can't give permission to use it under different copying conditions (this may be possible sometimes next year but not now). Best regards, Hannu ----- Hannu Savolainen (hannu@voxware.pp.fi, hannu@4front-tech.com) http://www.4Front-Tech.com/oss.html (Open Sound System (OSS)) http://personal.eunet.fi/pp/voxware (OSS Free/TASD/VoxWare) From owner-freebsd-multimedia Wed Jul 23 09:40:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA28912 for multimedia-outgoing; Wed, 23 Jul 1997 09:40: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 JAA28907 for ; Wed, 23 Jul 1997 09:40: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 JAA05816; Wed, 23 Jul 1997 09:40:20 -0700 (PDT) Message-Id: <199707231640.JAA05816@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Tomas Klockar cc: dwhite@resnet.uoregon.edu, multimedia@FreeBSD.ORG Subject: Re: problems with guspnp pro & vat In-reply-to: Your message of "Wed, 23 Jul 1997 13:52:06 +0200." <199707231152.NAA03247@father.ludd.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 23 Jul 1997 09:40:20 -0700 From: Amancio Hasty Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id JAA28908 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The guspnp sound driver works on non PnP bios in fact that was the whole motivation for providing builtin support for the gus pnp pro. Do you have a gus pnp or a gus pnp pro? The difference is that that the gus pnp does not come with memory and the gus pnp pro comes with 512kb. Also I am curious as to if you can record on DOS or Win95... Tnks, Amancio >From The Desk Of Tomas Klockar : > According to Doug White: > > On Wed, 23 Jul 1997, Tomas Klockar wrote: > > > > > Sorry for bladdering. > > > I were in a hurry. > > > What I meant were recording/sending with vat doesn't work. > > > Can anyone please help me with this? > > > > It works OK with guspnp6. Yeah, I'm behind the times, but if it works, > > don't fix it. :) > > > I had this problem before so I have tried guspnp4 guspnp5 guspnp6 > guspnp11 with the same result. I used to think this were because > there were no full duplex, but that doesn't matter, so I am starting > to belive that the guspnp isn't properly initilized. > You see I have no Plag-and-Pray bios. I used to use the pnp patch to > freebsd to initilize my plug and play devices. That patch doesn't > work with the guspnp sound packet. The reason is that they used the > same names for the plug and play devices. I can fix this by changing > the names, but that still doesn't fix my problem. > I bet all of you have plug-and-pray bios. > I think it would be nice to fix this and I would try to help if I can. > > You know I'm an engineer so if it's not broken it doesn't have enough > features yet :) > > Sincerely, > > /Tomas > > -- > Tomas Klockar can be found at the following adresses: > > Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se > 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se > Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se > Mob: +46-70-664 33 26 | qtxtkl@etxb.ericsson.se From owner-freebsd-multimedia Wed Jul 23 09:54:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29569 for multimedia-outgoing; Wed, 23 Jul 1997 09:54: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 JAA29564 for ; Wed, 23 Jul 1997 09:54: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 JAA05973 for ; Wed, 23 Jul 1997 09:54:47 -0700 (PDT) Message-Id: <199707231654.JAA05973@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org Subject: ftp://rah.star-gate.com/pub/guspnp12.tar.gz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 09:54:46 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I fixed audio recording for the SB16 cards so if you have a SB16 please download the driver and please let me know how it works. Also I stripped away all the debugging output which was being printed during the probe/attach phase. Enjoy, Amancio From owner-freebsd-multimedia Wed Jul 23 09:56:11 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA29733 for multimedia-outgoing; Wed, 23 Jul 1997 09:56: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 JAA29728 for ; Wed, 23 Jul 1997 09:56: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 JAA06005; Wed, 23 Jul 1997 09:55:55 -0700 (PDT) Message-Id: <199707231655.JAA06005@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Hannu Savolainen cc: "J. Utz" , hannu@voxware.pp.fi, multimedia@FreeBSD.ORG Subject: Re: use of maui.c from uss/lite permission? In-reply-to: Your message of "Wed, 23 Jul 1997 18:19:08 +0300." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 09:55:54 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tnks Hannu! Amancio >From The Desk Of Hannu Savolainen : > On Sat, 19 Jul 1997, J. Utz wrote: > > > 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. > The driver is GPLed so you have freedom to use the code as long as it > doesn't violate the rules defined by GPL. Unfortunately I can't give > permission to use it under different copying conditions (this may be > possible sometimes next year but not now). > > Best regards, > > Hannu > ----- > Hannu Savolainen (hannu@voxware.pp.fi, hannu@4front-tech.com) > http://www.4Front-Tech.com/oss.html (Open Sound System (OSS)) > http://personal.eunet.fi/pp/voxware (OSS Free/TASD/VoxWare) > From owner-freebsd-multimedia Wed Jul 23 10:49:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA02723 for multimedia-outgoing; Wed, 23 Jul 1997 10:49:49 -0700 (PDT) Received: from icicle.winternet.com (adm@icicle.winternet.com [198.174.169.13]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA02716 for ; Wed, 23 Jul 1997 10:49:43 -0700 (PDT) Received: (from adm@localhost) by icicle.winternet.com (8.7.5/8.7.5) id MAA14761 for ; Wed, 23 Jul 1997 12:49:36 -0500 (CDT) Posted-Date: Wed, 23 Jul 1997 12:49:36 -0500 (CDT) Received: from tundra.winternet.com(198.174.169.11) by icicle.winternet.com via smap (V2.0) id xma014707; Wed, 23 Jul 97 12:49:02 -0500 Received: from localhost (mestery@localhost) by tundra.winternet.com (8.8.4/8.8.4) with SMTP id MAA29485 for ; Wed, 23 Jul 1997 12:49:01 -0500 (CDT) X-Authentication-Warning: tundra.winternet.com: mestery owned process doing -bs Date: Wed, 23 Jul 1997 12:49:00 -0500 (CDT) From: Kyle Mestery To: freebsd-multimedia@freebsd.org Subject: Web hardware interface 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 Hi, I was wondering what the current status of the web interface for keeping track of hardware interafaces is, or if it is even being used. I am looking at doing something similar for the SMP list. Thanks. Kyle Mestery StorageTek's Network Systems Group 7600 Boone Ave. N., Brooklyn Park, MN 55428 mesteka@anubis.network.com, mestery@winternet.com From owner-freebsd-multimedia Wed Jul 23 14:57:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA17587 for multimedia-outgoing; Wed, 23 Jul 1997 14:57:15 -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 OAA17579; Wed, 23 Jul 1997 14:57:12 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Wed, 23 Jul 1997 17:56:10 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA12763; Wed, 23 Jul 97 17:56:07 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id RAA17677; Wed, 23 Jul 1997 17:53:55 -0400 Message-Id: <19970723175354.25643@ct.picker.com> Date: Wed, 23 Jul 1997 17:53:54 -0400 From: Randall Hopper To: razzle dazzle root beer Cc: questions@freebsd.org, multimedia@freebsd.org Subject: Re: SoundBlaster 16 questions References: <199707231033.GAA06479@foo.notwork.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707231033.GAA06479@foo.notwork.net>; from razzle dazzle root beer on Wed, Jul 23, 1997 at 06:33:34AM -0400 Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Hi. I'm forwarding this on over to the multimedia list since it's more likely to be noticed by a person that can help you there. Maybe someone has used Sujal Patel's ISA PnP tools to help config their SB16-compatible card. In any case, the sound driver is in the process of being updated by Amancio, Luigi, and the gang, and there's been mention of adding PnP support to this revised driver, so you may want to subscribe to the multimedia list, help out by trying the latest drivers, and express an interest in the plug and pray support. BTW, the latest cut of the driver's are on Amancio's FTP site: ftp://rah.star-gate.com/pub/guspnp12.tar.gz Ignore the filename -- its confusing. It's intended for a wider audience than just GUS owners. In case it helps, I have a SB32 non-PnP and am using the same driver configuration you are, with the exception that my sb0 is on IRQ 5, not 7, and I don't have the "conflicts" specified. I'd try that if you can. If no luck there, your problems are likely PnP-related. Randall Hopper razzle dazzle root beer: |Hi, I've got a Pentium 90/64MB ram running 2.2.2-rel with a soundblaster |awe32. I'm trying to get the audio to work, but it keeps breaking up in |wierd ways. | |I get some wierd error messages too: | |aud write: Resource temporarily unavailable |aud write: Resource temporarily unavailable |aud write: Resource temporarily unavailable | |over and over again until i stop trying to play audio. ... |This is my dmesg output ... | |sb0 at 0x220 irq 7 drq 1 on isa |sb0: |sbxvi0 at 0x0 drq 5 on isa |sbxvi0: |sbmidi0 at 0x330 on isa | |opl0 at 0x388 on isa |opl0: |Sound: DMA timed out - IRQ/DRQ config error? |Sound: DMA timed out - IRQ/DRQ config error? |Sound: DMA timed out - IRQ/DRQ config error? |[repeats] | |What am I doing wrong? This is a plug-and-pray card and I cant seem to |find my bible. From owner-freebsd-multimedia Wed Jul 23 16:13:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA21795 for multimedia-outgoing; Wed, 23 Jul 1997 16:13:57 -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 QAA21788; Wed, 23 Jul 1997 16:13:52 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Wed, 23 Jul 1997 19:12:49 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA13974; Wed, 23 Jul 97 19:12:47 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id TAA17889; Wed, 23 Jul 1997 19:10:35 -0400 Message-Id: <19970723191035.04021@ct.picker.com> Date: Wed, 23 Jul 1997 19:10:35 -0400 From: Randall Hopper To: Dmitry Kohmanyuk Cc: freebsd-hardware@freebsd.org, multimedia@freebsd.org Subject: Re: gus ISA pnp, 2.2-STABLE - doesn't work References: <19970723152301.07199@genesyslab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970723152301.07199@genesyslab.com>; from Dmitry Kohmanyuk on Wed, Jul 23, 1997 at 03:23:01PM -0700 Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk (Forwarding this over to the multimedia list where you're more likely to find some help). I have a Sound Blaster 32 myself so I can't speak from experience, but Amancio Hasty's added GUS PnP support to a Voxware 3.5 revision of the sound driver. In fact, the multimedia group is in the process of beating on this latest driver on all soundcards to do a wholesale replacement/upgrade of the driver checked into 3.0-current. The driver also builds/runs on 2.2.1+ as well -- I can attest to that. A few kinks in the sound code for SB cards still, but those are being worked through. Anyway, the URL (Amancio's FTP site): ftp://rah.star-gate.com/pub/guspnp12.tar.gz And feel free to post any comments/questions to the multimedia list regarding the sound driver (which is the current hot topic on the list) and your sure to get replies. Hope this helps. Randall Hopper Dmitry Kohmanyuk: |I have installed GUS PnP (ISA) in my workstation. |I am running 2.2-STABLE (make world past 2.2.2-RELEASE). | |I cannot get neither playback nor recording to work. | |dmesg: ... |gus0 at 0x220 irq 5 drq 1 on isa |gus0: ... |isa_dmastart: channel 1 busy |Sound: DMA timed out - IRQ/DRQ config error? | |the last 2 messages are when I type `cat /bin/sh > /dev/audio' and |`cat < /dev/audio', respectively. | |I have 2 Mb installed in it (2 1M SIMMs, 60ns). | |I have started DOS program from floppy disk and it shows me menu with |options to disable and enable, all is enabled except ATAPI interface. | |Any thoughts? | |Is there any GUS PnP support in 2.2 at all? From owner-freebsd-multimedia Wed Jul 23 16:55:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA24059 for multimedia-outgoing; Wed, 23 Jul 1997 16:55:13 -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 QAA24054 for ; Wed, 23 Jul 1997 16:55:11 -0700 (PDT) Received: from father.ludd.luth.se (dateck@father.ludd.luth.se [130.240.16.18]) by zed.ludd.luth.se (8.8.5/8.8.5) with ESMTP id BAA22453; Thu, 24 Jul 1997 01:54:59 +0200 From: Tomas Klockar Received: (dateck@localhost) by father.ludd.luth.se (8.6.11/8.6.11) id BAA20738; Thu, 24 Jul 1997 01:55:06 +0200 Message-Id: <199707232355.BAA20738@father.ludd.luth.se> Subject: Re: problems with guspnp pro & vat To: hasty@rah.star-gate.com (Amancio Hasty) Date: Thu, 24 Jul 1997 01:55:05 +0200 (MET DST) Cc: dateck@ludd.luth.se, dwhite@resnet.uoregon.edu, multimedia@FreeBSD.ORG In-Reply-To: <199707231640.JAA05816@rah.star-gate.com> from Amancio Hasty at "Jul 23, 97 09:40:20 am" X-Mailer: ELM [version 2.4ME+ PL15 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Amancio Hasty: > The guspnp sound driver works on non PnP bios in fact that was the > whole motivation for providing builtin support for the gus pnp pro. > > Do you have a gus pnp or a gus pnp pro? The difference is that > that the gus pnp does not come with memory and the gus pnp pro > comes with 512kb. > > Also I am curious as to if you can record on DOS or Win95... > > Tnks, > Amancio > I can record in Win95 perfect. Yes I heard that they sad that, but I think Pro also are delivered with a microphone, but I can be mistaken :) Anyway it's a Pro card which I added 2 4MB ram sims. I know that I have very little use of that in freebsd but I can take that :) 8.5 MB isn't suported by the card either so I'm curently using 8MB ram. I need to init the other things on the card like the IDE/ATAPI interface for my cdrom. Right now I'm not using that patch. Sincerly, /Tomas -- Tomas Klockar can be found at the following adresses: Kårhusvägen 4:23 | Furuvägen 102 | dateck@ludd.luth.se 977 54 Luleå | 871 52 Härnösand | dateck@solace.mh.se Tel: +46-920-231335 | Tel: +46-611-13393 | d94-tkl@sm.luth.se Mob: +46-70-664 33 26 | qtxtkl@etxb.ericsson.se From owner-freebsd-multimedia Wed Jul 23 19:05:35 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00257 for multimedia-outgoing; Wed, 23 Jul 1997 19:05:35 -0700 (PDT) Received: from rah.star-gate.com (rah.star-gate.com [204.188.121.18]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA00233; Wed, 23 Jul 1997 19:05: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 TAA08292; Wed, 23 Jul 1997 19:05:19 -0700 (PDT) Message-Id: <199707240205.TAA08292@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 to: razzle dazzle root beer cc: questions@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: SoundBlaster 16 questions In-reply-to: Your message of "Wed, 23 Jul 1997 17:53:54 EDT." <19970723175354.25643@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 19:05:19 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, Our support for 2.2 is minimal and we are focusing on 3.0 -current. Check your lpt IRQ assignment make sure that it does not conflict with your sb16. This is what I have for my SB16 PnP: controller snd0 device sb0 at isa? port 0x220 irq 10 conflicts drq 3 vector sbintr device sbxvi0 at isa? port? irq? drq 5 conflicts device opl0 at isa? port 0x388 conflicts device sbmidi0 at isa? port 0x300 irq? conflicts My bios inits my sb16 to those values or I can re progam the irq assigment with Sujal Patel's PnP setup: ftp://rah.star-gate.com/pub/FreeBSD-ISA_PnP_June8.tar.gz Have fun, Amancio >From The Desk Of Randall Hopper : > Hi. I'm forwarding this on over to the multimedia list since it's > more likely to be noticed by a person that can help you there. Maybe > someone has used Sujal Patel's ISA PnP tools to help config their > SB16-compatible card. > > In any case, the sound driver is in the process of being updated by > Amancio, Luigi, and the gang, and there's been mention of adding PnP > support to this revised driver, so you may want to subscribe to the > multimedia list, help out by trying the latest drivers, and express an > interest in the plug and pray support. > > BTW, the latest cut of the driver's are on Amancio's FTP site: > > ftp://rah.star-gate.com/pub/guspnp12.tar.gz > > Ignore the filename -- its confusing. It's intended for a wider audience > than just GUS owners. > > In case it helps, I have a SB32 non-PnP and am using the same driver > configuration you are, with the exception that my sb0 is on IRQ 5, not 7, > and I don't have the "conflicts" specified. I'd try that if you can. If > no luck there, your problems are likely PnP-related. > > Randall Hopper > > razzle dazzle root beer: > |Hi, I've got a Pentium 90/64MB ram running 2.2.2-rel with a soundblaster > |awe32. I'm trying to get the audio to work, but it keeps breaking up in > |wierd ways. > | > |I get some wierd error messages too: > | > |aud write: Resource temporarily unavailable > |aud write: Resource temporarily unavailable > |aud write: Resource temporarily unavailable > | > |over and over again until i stop trying to play audio. > ... > |This is my dmesg output > ... > | > |sb0 at 0x220 irq 7 drq 1 on isa > |sb0: > |sbxvi0 at 0x0 drq 5 on isa > |sbxvi0: > |sbmidi0 at 0x330 on isa > | > |opl0 at 0x388 on isa > |opl0: > |Sound: DMA timed out - IRQ/DRQ config error? > |Sound: DMA timed out - IRQ/DRQ config error? > |Sound: DMA timed out - IRQ/DRQ config error? > |[repeats] > | > |What am I doing wrong? This is a plug-and-pray card and I cant seem to > |find my bible. From owner-freebsd-multimedia Wed Jul 23 19:10:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00678 for multimedia-outgoing; Wed, 23 Jul 1997 19:10: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 TAA00662 for ; Wed, 23 Jul 1997 19:10:53 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Wed, 23 Jul 1997 22:09:47 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA16284; Wed, 23 Jul 97 22:09:46 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id WAA18547; Wed, 23 Jul 1997 22:07:32 -0400 Message-Id: <19970723220732.54270@ct.picker.com> Date: Wed, 23 Jul 1997 22:07:32 -0400 From: Randall Hopper To: Luigi Rizzo Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver References: <19970720010235.26253@pobox.com> <199707200711.JAA19743@labinfo.iet.unipi.it> <19970720204439.26980@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970720204439.26980@pobox.com>; from Brian Campbell on Sun, Jul 20, 1997 at 08:44:39PM -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Few days late on jumping in on this thread but here's my 2 cents. I'm also all-for simplification if we don't sacrifice anything. The two main issues on my mind WRT the proposed change are: - Response Time - Compatibility (Linux and FreeBSD apps) Response Time: To the first, if with the proposed mods, a read() of N bytes of data from /dev/dsp always takes the same or less amount of time as in the current drivers doing a "SETFRAGMENT N" and read()ing N bytes, and ditto for write(), I'm sold on this point. So e.g. for reads, the size of the request would need to be completely decoupled from internal buffering sizes in terms of "filling one up" before data could be returned so small read requests of N bytes could always be services very quickly if at least N bytes were available. Having recently had to use SETFRAGMENT myself to solve delay problems recording interleaved audio and video to disk for Fxtv, I know it's very useful with the current drivers to have this control. With a default buffer size of 32K for the sbxvi driver, the reads take __WAY__ too long to keep a multitasking event loop spinning. But with 1K buffers, it works very well. I've noticed that mtv (Linux MPEG system stream player) sets 1K buffers as well for the same reason during interleaved audio and video playback (checking with GETOSPACE to see when a buffer frees up). Compatibility: To the second point, Linux compatibility is pretty important, and avoiding having to report FreeBSD stuff is a plus as well. Of course, the ioctls that tie into this are SETFRAGMENT, GETISPACE, and GETOSPACE, allowing the client to set the internal buffer size and request a number of buffers, as well as fetch back the driver's adjusted buffer size and determine free buffer counts before doing reads and writes. Without maintaining a client-settable "buffer size", I guess GETISPACE and GETOSPACE could be dummied up to satisfy the coded assumptions of existing Linux and FreeBSD/Linux sound clients. Hmmm. Guess the sound driver could keep track of the requested FRAGMENT size, and then return the amount of free buffers and buffer size using this originally-requested buffer size, virtualizing the whole thing. Anyway, the compatibility aspect sounds doable. If the response time is a sure-thing as well, it sound like a good change to me! Randall Brian Campbell: |Similarly for recording. Sometimes you'll want to use a low number |of small buffers for sampling -- say for some sort of recognition |function, or frequency analyzer. You want to get hold of the |samples as soon as possible and if your processing time on those |samples means the recording "stalls" and you miss a buffer or three |then you just want to continue with what's happening "now". ... |The point being that you probably can't chose a "best" number or |size of DMA buffers. You probably also can't solve all latency |problems (unless there's a gross one that exists that I'm unaware |of) for all uses. Luigi Rizzo: |> On Sat, Jul 19, 1997 at 04:37:50PM +0200, Luigi Rizzo wrote: |> > I have planned to rewrite the dma buffer handling routines for |> > the sound driver as follows. |> |> There is a mechanism for setting the size and number of DMA buffers, |> is there not? Will this be removed, or the settings simply ignored? | |i forgot to say that all current ioctls will remain valid (for |backward compatibility reasons). If they are really useful, they |will have the same effect. If they become useless (e.g. in the case |of SNDCTL_DSP_SETFRAGMENT, because the new implementation implicitly |solves the problem), they might become a nop, or they will just |maintain a fake state variable. From owner-freebsd-multimedia Wed Jul 23 19:12:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA00755 for multimedia-outgoing; Wed, 23 Jul 1997 19:12: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 TAA00750; Wed, 23 Jul 1997 19:12: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 TAA08322; Wed, 23 Jul 1997 19:12:49 -0700 (PDT) Message-Id: <199707240212.TAA08322@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Dmitry Kohmanyuk cc: freebsd-hardware@FreeBSD.ORG, multimedia@FreeBSD.ORG Subject: Re: gus ISA pnp, 2.2-STABLE - doesn't work In-reply-to: Your message of "Wed, 23 Jul 1997 19:10:35 EDT." <19970723191035.04021@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 19:12:49 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tnks Randall for forwarding the request to the multimedia mailing list. The gus pnp pro is supported . To configure your sound card using the guspnp sound driver which is really the linux sound 3.5 plus enhancements: controller snd0 device gus0 at isa? vector gusintr If the pnp initialization fails: controller snd0 device gus0 at isa? port 0x220 irq 11 drq 5 flags 0x7 vector gusintr Well, you have to chose your port, irq and dma channels As Ranall mentioned the latest sound driver is at: ftp://rah.star-gate.com/pub/guspnp12.tar.gz Our goal is to submit the driver to 3.0 -current as soon as the driver is fully stabilized for non gus cards . Additionally , Luigi is leading the effort to completly re-vamp the sound driver. Enjoy, Amancio >From The Desk Of Randall Hopper : > (Forwarding this over to the multimedia list where you're more likely to > find some help). > > I have a Sound Blaster 32 myself so I can't speak from experience, but > Amancio Hasty's added GUS PnP support to a Voxware 3.5 revision of the > sound driver. In fact, the multimedia group is in the process of beating > on this latest driver on all soundcards to do a wholesale > replacement/upgrade of the driver checked into 3.0-current. The driver > also builds/runs on 2.2.1+ as well -- I can attest to that. A few kinks in > the sound code for SB cards still, but those are being worked through. > > Anyway, the URL (Amancio's FTP site): > > ftp://rah.star-gate.com/pub/guspnp12.tar.gz > > And feel free to post any comments/questions to the multimedia list > regarding the sound driver (which is the current hot topic on the list) and > your sure to get replies. > > Hope this helps. > > Randall Hopper > > > Dmitry Kohmanyuk: > |I have installed GUS PnP (ISA) in my workstation. > |I am running 2.2-STABLE (make world past 2.2.2-RELEASE). > | > |I cannot get neither playback nor recording to work. > | > |dmesg: > ... > |gus0 at 0x220 irq 5 drq 1 on isa > |gus0: > ... > |isa_dmastart: channel 1 busy > |Sound: DMA timed out - IRQ/DRQ config error? > | > |the last 2 messages are when I type `cat /bin/sh > /dev/audio' and > |`cat < /dev/audio', respectively. > | > |I have 2 Mb installed in it (2 1M SIMMs, 60ns). > | > |I have started DOS program from floppy disk and it shows me menu with > |options to disable and enable, all is enabled except ATAPI interface. > | > |Any thoughts? > | > |Is there any GUS PnP support in 2.2 at all? From owner-freebsd-multimedia Wed Jul 23 19:38:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA01893 for multimedia-outgoing; Wed, 23 Jul 1997 19:38:32 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id TAA01888 for ; Wed, 23 Jul 1997 19:38:29 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id WAA06470; Wed, 23 Jul 1997 22:37:45 -0400 (EDT) Message-Id: <199707240237.WAA06470@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Amancio Hasty cc: multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707231654.JAA05973@rah.star-gate.com> In-reply-to: Your message of "Wed, 23 Jul 1997 09:54:46 PDT." <199707231654.JAA05973@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 22:37:45 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Could someone else check to see if the /usr/bin/mixer program is working with the new sound driver? With guspnp11, I don't get anything listed when I invoke it without arguments to get the current levels. This is a 3.0-current system, with a SB-16/Phoneblaster sound card. The mixer command was built with a much earlier version of the sound driver; guspnp8 or so (I think). louie From owner-freebsd-multimedia Wed Jul 23 19:44:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id TAA02215 for multimedia-outgoing; Wed, 23 Jul 1997 19:44: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 TAA02191 for ; Wed, 23 Jul 1997 19:44:01 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id TAA08628; Wed, 23 Jul 1997 19:40:57 -0700 (PDT) Message-Id: <199707240240.TAA08628@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Louis A. Mamakos" cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-reply-to: Your message of "Wed, 23 Jul 1997 22:37:45 EDT." <199707240237.WAA06470@whizzo.TransSys.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 19:40:57 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is what it the stock 3.0 -current mixer and a SB16 PnP: {hasty} uname -a FreeBSD cioloco.star-gate.com 3.0-970522-SNAP FreeBSD 3.0-970522-SNAP ... {hasty} mixer Mixer vol is currently set to 90:90 Mixer bass is currently set to 75:75 Mixer treble is currently set to 75:75 Mixer synth is currently set to 75:75 Mixer pcm is currently set to 75:75 Mixer speaker is currently set to 75:75 Mixer line is currently set to 75:75 Mixer mic is currently set to 16:16 Mixer cd is currently set to 75:75 Mixer igain is currently set to 75:75 Mixer ogain is currently set to 75:75 Cheers, Amancio >From The Desk Of "Louis A. Mamakos" : > Could someone else check to see if the /usr/bin/mixer program is working > with the new sound driver? With guspnp11, I don't get anything listed > when I invoke it without arguments to get the current levels. > > This is a 3.0-current system, with a SB-16/Phoneblaster sound card. The > mixer command was built with a much earlier version of the sound driver; > guspnp8 or so (I think). > > louie > > From owner-freebsd-multimedia Wed Jul 23 20:11:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA03812 for multimedia-outgoing; Wed, 23 Jul 1997 20:11:57 -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 UAA03792 for ; Wed, 23 Jul 1997 20:11:51 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id EAA25526; Thu, 24 Jul 1997 04:10:36 +0200 From: Luigi Rizzo Message-Id: <199707240210.EAA25526@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: rhh@ct.picker.com (Randall Hopper) Date: Thu, 24 Jul 1997 04:10:36 +0200 (MET DST) Cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: <19970723220732.54270@ct.picker.com> from "Randall Hopper" at Jul 23, 97 10:07:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Few days late on jumping in on this thread but here's my 2 cents. > > I'm also all-for simplification if we don't sacrifice anything. The > two main issues on my mind WRT the proposed change are: > > - Response Time > - Compatibility (Linux and FreeBSD apps) > > Response Time: > > To the first, if with the proposed mods, a read() of N bytes of data > from /dev/dsp always takes the same or less amount of time as in the > current drivers doing a "SETFRAGMENT N" and read()ing N bytes, and ditto > for write(), I'm sold on this point. So e.g. for reads, the size of the yes this is the goal. But I still plan to provide a SETFRAGMENT ioctl. same for compatibility, I plan to support all linux ioctl's (provided I can find out what they do :) ) Knowing which ioctl's are used by apps (commercial and not) would certainly help to prioritize the work on some rather than others. Cheers Luigi -----------------------------+-------------------------------------- Luigi Rizzo | Dip. di Ingegneria dell'Informazione email: luigi@iet.unipi.it | Universita' di Pisa tel: +39-50-568533 | via Diotisalvi 2, 56126 PISA (Italy) fax: +39-50-568522 | http://www.iet.unipi.it/~luigi/ _____________________________|______________________________________ From owner-freebsd-multimedia Wed Jul 23 20:27:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA04435 for multimedia-outgoing; Wed, 23 Jul 1997 20:27:55 -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 UAA04428 for ; Wed, 23 Jul 1997 20:27:52 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Wed, 23 Jul 1997 23:26:48 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA17317; Wed, 23 Jul 97 23:26:46 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id XAA18599; Wed, 23 Jul 1997 23:24:32 -0400 Message-Id: <19970723232432.47587@ct.picker.com> Date: Wed, 23 Jul 1997 23:24:32 -0400 From: Randall Hopper To: Luigi Rizzo Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver References: <19970723220732.54270@ct.picker.com> <199707240210.EAA25526@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707240210.EAA25526@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Jul 24, 1997 at 04:10:36AM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo: |Knowing which ioctl's are used by apps (commercial and not) would |certainly help to prioritize the work on some rather than others. Ok. Well, the only commercial app I have this info for is the MpegTV's Linux mtv, since I buzzed it out when debugging the no-audio problem (before dumping it for the FreeBSD version). Here's the /dev/dsp ioctls it uses: SETUP: DSP_SETFMT PCM_WRITE_CHANNELS PCM_WRITE_RATE DSP_SETFMT DSP_STEREO DSP_SETFRAGMENT (requests 127 buffers, each 1024 bytes each) (driver keeps 1024 buffer size, but adjusts requested number of buffers down to 64 since 64k is all the mem that's available) ... MAIN PLAY LOOP: DSP_GETOSPACE - reflects free space across 64 bufs, each 1024bytes write() - if space ON MUTE OR EXIT: DSP_RESET Randall From owner-freebsd-multimedia Wed Jul 23 21:21:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA06679 for multimedia-outgoing; Wed, 23 Jul 1997 21:21:30 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA06674 for ; Wed, 23 Jul 1997 21:21:24 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id AAA07516; Thu, 24 Jul 1997 00:21:18 -0400 (EDT) Message-Id: <199707240421.AAA07516@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Amancio Hasty cc: multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707240240.TAA08628@rah.star-gate.com> In-reply-to: Your message of "Wed, 23 Jul 1997 19:40:57 PDT." <199707240240.TAA08628@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 1997 00:21:18 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Well, that's weird that your mixer works. I'm going to look inside of mixer, and see what it's getting back from the kernel. Does this /dev/sndstat look OK? : bash-2.00$ cat /dev/sndstat VoxWare Sound Driver:3.5-alpha11-9707223 (Wed Jul 23 3:00:00 PDT 1997 Amancio Hasty@rah.star-gate.com) Config options: Installed drivers: Type 1: OPL-2/OPL-3 FM Type 2: SoundBlaster Type 6: SoundBlaster16 Type 7: SB16 MIDI Card config: SoundBlaster at 0x280 irq 10 drq 1 SoundBlaster16 at 0x280 irq 10 drq 5 OPL-2/OPL-3 FM at 0x388 irq 1 SB16 MIDI at 0x330 irq 10 Audio devices: 0: SoundBlaster 16 4.13 Synth devices: 0: Yamaha OPL-3 Midi devices: 0: SoundBlaster 16 Midi Timers: 0: System clock Mixers: 0: SoundBlaster bash-2.00$ I'm now getting these messages at boot time: sb0 at 0x280 irq 10 drq 1 on isa at 0x280 irq 10 dma 1 sbxvi0 at 0x280 irq 10 drq 5 on isa at 0x280 irq 10 dma 5 device combination doesn't support shared irq10 intr_connect(irq10) failed, result=-1 opl0 at 0x388 irq 31 on isa at 0x388 create_intr: requested irq31 too high, limit is 15 sbmidi0 at 0x330 irq 10 on isa at 0x330 irq 10 device combination doesn't support shared irq10 intr_connect(irq10) failed, result=-1 From owner-freebsd-multimedia Wed Jul 23 21:32:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA07126 for multimedia-outgoing; Wed, 23 Jul 1997 21:32:41 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA07121 for ; Wed, 23 Jul 1997 21:32:38 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id AAA07708; Thu, 24 Jul 1997 00:32:35 -0400 (EDT) Message-Id: <199707240432.AAA07708@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Amancio Hasty cc: multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707240240.TAA08628@rah.star-gate.com> In-reply-to: Your message of "Wed, 23 Jul 1997 19:40:57 PDT." <199707240240.TAA08628@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 1997 00:32:34 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I looked closer at the mixer command, and it's getting all zeros returned from the SOUND_MIXER_READ_DEVMASK, SOUND_MIXER_READ_RECMASK, and SOUND_MIXER_READ_RECSRC ioctls. I am able to play audio on the /dev/audio device, so it's mostly working. It's getting a little late for me, so I'll pick this back up tomorrow. louie From owner-freebsd-multimedia Wed Jul 23 22:00:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA08647 for multimedia-outgoing; Wed, 23 Jul 1997 22:00: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 WAA08640 for ; Wed, 23 Jul 1997 22:00: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 WAA09277; Wed, 23 Jul 1997 22:00:03 -0700 (PDT) Message-Id: <199707240500.WAA09277@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Louis A. Mamakos" cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-reply-to: Your message of "Thu, 24 Jul 1997 00:21:18 EDT." <199707240421.AAA07516@whizzo.TransSys.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 23 Jul 1997 22:00:03 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Okay, I will fix the driver over here. Just a little confused at the moment with the SB16 thingies. Regards, Amancio >From The Desk Of "Louis A. Mamakos" : > Well, that's weird that your mixer works. I'm going to look inside of > mixer, and see what it's getting back from the kernel. > > Does this /dev/sndstat look OK? : > > bash-2.00$ cat /dev/sndstat > VoxWare Sound Driver:3.5-alpha11-9707223 (Wed Jul 23 3:00:00 PDT 1997 Amancio > Hasty@rah.star-gate.com) > Config options: > > Installed drivers: > Type 1: OPL-2/OPL-3 FM > Type 2: SoundBlaster > Type 6: SoundBlaster16 > Type 7: SB16 MIDI > > > Card config: > SoundBlaster at 0x280 irq 10 drq 1 > SoundBlaster16 at 0x280 irq 10 drq 5 > OPL-2/OPL-3 FM at 0x388 irq 1 > SB16 MIDI at 0x330 irq 10 > > Audio devices: > 0: SoundBlaster 16 4.13 > > Synth devices: > 0: Yamaha OPL-3 > > Midi devices: > 0: SoundBlaster 16 Midi > > Timers: > 0: System clock > > Mixers: > 0: SoundBlaster > bash-2.00$ > > I'm now getting these messages at boot time: > > sb0 at 0x280 irq 10 drq 1 on isa > at 0x280 irq 10 dma 1 > sbxvi0 at 0x280 irq 10 drq 5 on isa > at 0x280 irq 10 dma 5 > device combination doesn't support shared irq10 > intr_connect(irq10) failed, result=-1 > opl0 at 0x388 irq 31 on isa > at 0x388 > create_intr: requested irq31 too high, limit is 15 > sbmidi0 at 0x330 irq 10 on isa > at 0x330 irq 10 > device combination doesn't support shared irq10 > intr_connect(irq10) failed, result=-1 > > From owner-freebsd-multimedia Wed Jul 23 23:10:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA11284 for multimedia-outgoing; Wed, 23 Jul 1997 23:10:19 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id XAA11279 for ; Wed, 23 Jul 1997 23:10:16 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA25745; Thu, 24 Jul 1997 07:08:53 +0200 From: Luigi Rizzo Message-Id: <199707240508.HAA25745@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: rhh@ct.picker.com (Randall Hopper) Date: Thu, 24 Jul 1997 07:08:53 +0200 (MET DST) Cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: <19970723232432.47587@ct.picker.com> from "Randall Hopper" at Jul 23, 97 11:24:13 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo: > |Knowing which ioctl's are used by apps (commercial and not) would > |certainly help to prioritize the work on some rather than others. > > Ok. Well, the only commercial app I have this info for is the MpegTV's > Linux mtv, since I buzzed it out when debugging the no-audio problem > (before dumping it for the FreeBSD version). Here's the /dev/dsp ioctls it > uses: Thanks for the detailed list. I am looking at the DSP_SETFRAGMENT thing, and while I have no problem to implement it with the required features, it sounds quite odd that the application requires many small buffers. If they are small it means the app wants low latency, so why ask for many ? Luigi From owner-freebsd-multimedia Thu Jul 24 00:30:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA15104 for multimedia-outgoing; Thu, 24 Jul 1997 00:30:29 -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 AAA15099 for ; Thu, 24 Jul 1997 00:30:26 -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 JAA28658; Thu, 24 Jul 1997 09:30:20 +0200 Date: Thu, 24 Jul 1997 09:30:11 +0200 (MET DST) From: Johan Larsson To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-Reply-To: <199707231654.JAA05973@rah.star-gate.com> 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 Well, i tried this with my sb16pnp card and i didn't get it to work at all. Perhaps i have missed something in the configuration or in the readme-files. Of course i forgot to do a 'cat /dev/sndstat', but i will do that as soon as i come home tonight (i'm at work now). The kernelversion i'm running is 3.0-970209-SNAP, it should work with this right?.. And my bios does not have pnp support. Should i use Sujal's pnpfix? I am doing it now. Then i tried to do a 'cat /dev/audio > test.au' it just said "/device not configured".. And then i tried the rattool it just said "/dev/dsp: no such device", i might remember wrong, but something like this it is anyway. >From my configfile: # Sound Cards controller snd0 options "SBC_IRQ=5" device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr device sbxvi0 at isa? drq 5 device sbmidi0 at isa? port 0x330 device opl0 at isa? port 0x388 conflicts >From kernellog: Jul 24 00:36:09 moon /kernel.pnp12: sb0 at 0x220 irq 5 drq 1 on isa Jul 24 00:36:09 moon /kernel.pnp12: SoundBlaster 16 4.13> at 0x220 irq 5 dma 1 Jul 24 00:36:09 moon /kernel.pnp12: sbxvi0 at 0x220 irq 5 drq 5 on isa Jul 24 00:36:09 moon /kernel.pnp12: sbxvi0 not probed due to I/O address conflict with sb0 at 0x220 Jul 24 00:36:09 moon /kernel.pnp12: sbmidi0 at 0x330 irq 5 on isa Jul 24 00:36:09 moon /kernel.pnp12: sbmidi0 not probed due to irq conflict with sb0 at 5 Jul 24 00:36:09 moon /kernel.pnp12: opl0 at 0x388 on isa Jul 24 00:36:09 moon /kernel.pnp12: Yamaha OPL3 FM> at 0x388 Jul 24 00:36:37 moon /kernel.pnp12: PCM device 0 not installed. Jul 24 00:37:49 moon /kernel.pnp12: PCM device 0 not installed. If good sbsupport get's into freebsd i know i'm not the only one that will be very happy :-) And i'm willing to test things to get it good. I'm sorry for the lack of information right now, but it got a bit late last night and i didn't have time to test the driver more right then. Hopefully i have more information later tonight :) johan PS Isn't a namechange of the package in it's place by now? DS PPS I tried the new rattool from mice for freebsd with the sounddriver that is originally on my system, and the sound is perfect(ok almost), but not at all as clicky as the vattool gets. But the volumecontrol doesn't work on neither of the tools, suggestions? DDS On Wed, 23 Jul 1997, Amancio Hasty wrote: > > I fixed audio recording for the SB16 cards so if you have a > SB16 please download the driver and please let me know how it works. > > Also I stripped away all the debugging output which was being > printed during the probe/attach phase. > > Enjoy, > Amancio > > > > -- * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * * finger gozer@mother.ludd.luth.se for more information... +-+-+ * * Powered by FreeBSD. http://www.se.freebsd.org/ +-+-+ The REAL OS * From owner-freebsd-multimedia Thu Jul 24 03:50:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA22099 for multimedia-outgoing; Thu, 24 Jul 1997 03:50:22 -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 DAA22091 for ; Thu, 24 Jul 1997 03:50:18 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 24 Jul 1997 6:45:51 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA23119; Thu, 24 Jul 97 06:45:49 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id GAA18950; Thu, 24 Jul 1997 06:43:35 -0400 Message-Id: <19970724064335.01827@ct.picker.com> Date: Thu, 24 Jul 1997 06:43:35 -0400 From: Randall Hopper To: Luigi Rizzo Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver References: <19970723232432.47587@ct.picker.com> <199707240508.HAA25745@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707240508.HAA25745@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Jul 24, 1997 at 07:08:53AM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo: |Randall Hopper: |> Ok. Well, the only commercial app I have this info for is the MpegTV's |> Linux mtv, since I buzzed it out when debugging the no-audio problem |> (before dumping it for the FreeBSD version). Here's the /dev/dsp ioctls it |> uses: | |Thanks for the detailed list. | |I am looking at the DSP_SETFRAGMENT thing, and while I have no problem |to implement it with the required features, it sounds quite odd that |the application requires many small buffers. If they are small it means |the app wants low latency, so why ask for many ? Small buffers gets it low latency on write()s. Many buffers minimizes the chance that the driver will have played everything by the time that it gets around to feeding it again. Randall From owner-freebsd-multimedia Thu Jul 24 03:57:01 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id DAA22327 for multimedia-outgoing; Thu, 24 Jul 1997 03:57:01 -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 DAA22322 for ; Thu, 24 Jul 1997 03:56:58 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 24 Jul 1997 6:56:21 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA23237; Thu, 24 Jul 97 06:56:19 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id GAA18979; Thu, 24 Jul 1997 06:54:05 -0400 Message-Id: <19970724065405.37511@ct.picker.com> Date: Thu, 24 Jul 1997 06:54:05 -0400 From: Randall Hopper To: Stan Brown Cc: Free BSD Multimedia List Subject: Re: Simple two way audio on local network. References: <199707201607.JAA21796@hub.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707201607.JAA21796@hub.freebsd.org>; from Stan Brown on Sun, Jul 20, 1997 at 12:07:37PM -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Stan Brown: | I have a small network of computers in my house. Among these I have a | FreeBSD 2.2.2 machine downstairs with a GUS PnP, and an HP 735 | upstairs. Both of these have quite nice audio, with speakers and cheap | mikes. | | I would like to set up to be able to use these as a simple intercom from | upstairs to downstairs. | | Could someone point me to the tight tool(s) to set up to accomplish | this? Check out rplay. As I recall, it does what you're talking about. Making it easy to set up a "network intercom". Randall rplay is a flexible network audio system that allows sounds to be played to and from local and remote systems. The rplay audio server currently supports SunOS 4.1.X, Solaris 2.X, Linux, SGI IRIX 4 & 5, HP9000/705, HP9000/710 and now FreeBSD. The rplay clients and client library should work on any system that supports Berkeley sockets. X Windows is not required. Version 3.2.0beta ------------------- * Supported systems include SunOS 4.1.X, Solaris 2.x, FreeBSD, Linux, SGI IRIX 4 and IRIX 5, and HP9000/710. * 8-bit & 16-bit audio input and output. * All audio sample rates. * .au, .snd, .aiff, .wav, .voc, .ub, .ul, G.721 4-bit, G.723 3-bit, and G.723 5-bit audio files. * Stereo input and output. (2 channels) * Sounds can be played at any sample rate. * Compile rplayd with -DTEST_FLANGE for some fun. * Flexible audio configuration using the following long-named options: --audio-device, --audio-bufsize, --audio-bits, --audio-channels, --audio-close, --audio-flush, --audio-format, --audio-match, --audio-port, --audio-rate, --audio-sample-rate, and no-audio. (See `rplayd --help' for more details) * HTML documentation. From owner-freebsd-multimedia Thu Jul 24 04:04:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA22617 for multimedia-outgoing; Thu, 24 Jul 1997 04:04: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 EAA22612 for ; Thu, 24 Jul 1997 04:04:51 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 24 Jul 1997 7:04:19 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA23344; Thu, 24 Jul 97 07:03:55 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA19002; Thu, 24 Jul 1997 07:01:41 -0400 Message-Id: <19970724070141.55255@ct.picker.com> Date: Thu, 24 Jul 1997 07:01:41 -0400 From: Randall Hopper To: Bill Fenner Cc: multimedia@FreeBSD.ORG Subject: Re: /dev/sequencer and gmod-3.0.6? References: <97Jul20.193551pdt.177512@crevenia.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <97Jul20.193551pdt.177512@crevenia.parc.xerox.com>; from Bill Fenner on Sun, Jul 20, 1997 at 07:35:46PM -0800 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Bill Fenner: | I'm trying to update our port of gmod to 3.0.6 . The UI seems to work |just peachy, but when it tries to go and play the mod file, it locks up. |A ktrace seems to show that it's writing a ton of data to /dev/sequencer. | | I've got no clue what it might be doing. If anyone with a GUS feels |like trying to figure out what's going on, my new port is at | |http://www.freebsd.org/~fenner/new-gmod.tar.gz When I ported 3.01 to use the latest AWE driver, I observed the same behavior. Port at: multiverse.com/~rhh/awedrv. As I recall, the old 2.0x port of gmod did the same thing. Didn't dig into it at the time, but I wonder if it's blocked writing the sequencer device. If so, I wonder if Linux does something different that supports attempts to avoid blocking. Randall From owner-freebsd-multimedia Thu Jul 24 04:19:16 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA23215 for multimedia-outgoing; Thu, 24 Jul 1997 04:19:16 -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 EAA23210 for ; Thu, 24 Jul 1997 04:19:12 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 24 Jul 1997 7:18:10 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA23662; Thu, 24 Jul 97 07:18:09 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA19069; Thu, 24 Jul 1997 07:15:52 -0400 Message-Id: <19970724071551.54552@ct.picker.com> Date: Thu, 24 Jul 1997 07:15:51 -0400 From: Randall Hopper To: "Louis A. Mamakos" Cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707231654.JAA05973@rah.star-gate.com> <199707240237.WAA06470@whizzo.TransSys.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707240237.WAA06470@whizzo.TransSys.COM>; from Louis A. Mamakos on Wed, Jul 23, 1997 at 10:37:45PM -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Louis A. Mamakos: |Could someone else check to see if the /usr/bin/mixer program is working |with the new sound driver? With guspnp11, I don't get anything listed |when I invoke it without arguments to get the current levels. | |This is a 3.0-current system, with a SB-16/Phoneblaster sound card. The |mixer command was built with a much earlier version of the sound driver; |guspnp8 or so (I think). Can't speak to the old pnp8 code, but the mixer on versions 10-12 worked OK for me on a SB32. There have been other problems with the DSP though. Randall From owner-freebsd-multimedia Thu Jul 24 04:28:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA23490 for multimedia-outgoing; Thu, 24 Jul 1997 04:28: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 EAA23485 for ; Thu, 24 Jul 1997 04:28:56 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 24 Jul 1997 7:28:22 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA23901; Thu, 24 Jul 97 07:28:20 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id HAA19083; Thu, 24 Jul 1997 07:26:05 -0400 Message-Id: <19970724072605.26661@ct.picker.com> Date: Thu, 24 Jul 1997 07:26:05 -0400 From: Randall Hopper To: Johan Larsson Cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707231654.JAA05973@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: ; from Johan Larsson on Thu, Jul 24, 1997 at 09:30:11AM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Johan Larsson: |Well, i tried this with my sb16pnp card and i didn't get it to work at |all. Perhaps i have missed something in the configuration or in the |readme-files. ... |device sb0 at isa? port 0x220 irq 5 drq 1 vector sbintr |device sbxvi0 at isa? drq 5 ... |Jul 24 00:36:09 moon /kernel.pnp12: sb0 at 0x220 irq 5 drq 1 on isa |Jul 24 00:36:09 moon /kernel.pnp12: SoundBlaster 16 4.13> at 0x220 irq 5 dma 1 |Jul 24 00:36:09 moon /kernel.pnp12: sbxvi0 at 0x220 irq 5 drq 5 on isa |Jul 24 00:36:09 moon /kernel.pnp12: sbxvi0 not probed due to I/O address conflict with sb0 at 0x220 |Jul 24 00:36:09 moon /kernel.pnp12: sbmidi0 at 0x330 irq 5 on isa |Jul 24 00:36:09 moon /kernel.pnp12: sbmidi0 not probed due to irq conflict with sb0 at 5 I got the same results on my SB32 non-PnP. Appears the problem is that several of the sound devices think they're on IRQ 5. pnp11 didn't have this problem and in fact was pretty close to being perfect (no 16-bit record was the only major thing -- see below); something changed between pnp11 and pnp12 to cause this to crop up. |On Wed, 23 Jul 1997, Amancio Hasty wrote: |> I fixed audio recording for the SB16 cards so if you have a |> SB16 please download the driver and please let me know how it works. |> |> Also I stripped away all the debugging output which was being |> printed during the probe/attach phase. Randall Date: Tue, 22 Jul 1997 21:34:24 -0400 From: Randall Hopper To: Amancio Hasty Subject: Re: ftp://rah.star-gate.com/pub/guspnp11.tar.gz |New sound driver release with important signal handling fix. |The nagging problem with the SB16 hanging or repeating |sound clips at the end is gone. | |If you want to know more about the fixes that went in see: |sound/REAMDE.GUSPNP in the tar ball. Just got a chance to pull it and run it past all the audio tests I can think of with my SB32. Here's the results: 1) Thanks for the good work on repeating and close() hanging fix! Did not hear any repeats, and when I allowed audio play apps to finish playing and terminate normally, I never saw them hang on close(). The only time I saw a hang was when I Ctrl-Ced the app in the middle of playback (e.g. mpg123); not all the time--sporatically as before. So as far as this specific problem goes (hanging), this driver is better than the checked-in version. 2) Load pops on start/end of AU playback. Still there. Don't see this with the checked-in driver. 3) Attempts to record 16-bit samples gives "Input/Output Error" now instead of the "Interrupted system call" before. For each failure, I get one of these in my console: Sound: DMA (input) timed out - IRQ/DRQ config error? 16-bit record works with the checked-in driver. 4) I think Louis or you mentioned this, but I also see probe output that's a little strange. Looks fine except for that dma 7 in there. Could this be related to the DMA error doing 16-bit record? ... From owner-freebsd-multimedia Thu Jul 24 05:39:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA25681 for multimedia-outgoing; Thu, 24 Jul 1997 05:39:31 -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 FAA25676 for ; Thu, 24 Jul 1997 05:39:29 -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 OAA03558; Thu, 24 Jul 1997 14:39:20 +0200 Date: Thu, 24 Jul 1997 14:39:13 +0200 (MET DST) From: Johan Larsson To: Randall Hopper cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-Reply-To: <19970724072605.26661@ct.picker.com> 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 On Thu, 24 Jul 1997, Randall Hopper wrote: > I got the same results on my SB32 non-PnP. Appears the problem is that > several of the sound devices think they're on IRQ 5. pnp11 didn't have > this problem and in fact was pretty close to being perfect (no 16-bit > record was the only major thing -- see below); something changed between > pnp11 and pnp12 to cause this to crop up. Hmm okie. I was home during lunch and got the following output from 'cat /dev/sndstat': VoxWare Sound Driver:3.5-alpha11-9707223 (Wed Jul 23 3:00:00 PDT 1997 Amancio Hasty@rah.star-gate.com) Config options: Installed drivers: Type 1: OPL-2/OPL-3 FM Type 2: SoundBlaster Type 6: SoundBlaster16 Type 7: SB16 MIDI Card config: SoundBlaster at 0x220 irq 5 drq 1 SoundBlaster16 at 0x0 irq 1 drq 5 SB16 MIDI at 0x330 irq 1 OPL-2/OPL-3 FM at 0x388 irq 1 Audio devices: Synth devices: 0: Yamaha OPL-3 Midi devices: Timers: 0: System clock Mixers: 0: SoundBlaster playmidi works but it has some problems playing on the right channel(left/right). Sometime it starts on the left and another on the right. But that's maybe a playmidi bug. And it uses the synth that seems to be probed correctly ./johan -- * mailto:gozer@ludd.luth.se * http://www.ludd.luth.se/users/gozer/ * * finger gozer@mother.ludd.luth.se for more information... +-+-+ * * Powered by FreeBSD. http://www.se.freebsd.org/ +-+-+ The REAL OS * From owner-freebsd-multimedia Thu Jul 24 07:05:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA29744 for multimedia-outgoing; Thu, 24 Jul 1997 07:05:12 -0700 (PDT) Received: from internet.milkyway.com (milkyway.com [198.53.167.2]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id HAA29739 for ; Thu, 24 Jul 1997 07:05:07 -0700 (PDT) Received: id JAA00704; Thu, 24 Jul 1997 09:55:02 -0400 Received: by gateway id JAA00742 for ; Thu, 24 Jul 1997 09:22:09 -0400 Received: by gateway id AA09874; Thu, 24 Jul 97 09:25:58 EDT Message-Id: <19970724092558.31924@milkyway.com> Date: Thu, 24 Jul 1997 09:25:58 -0400 From: Brian Campbell To: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver References: <19970723232432.47587@ct.picker.com> <199707240508.HAA25745@labinfo.iet.unipi.it> <19970724064335.01827@ct.picker.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <19970724064335.01827@ct.picker.com>; from Randall Hopper on Thu, Jul 24, 1997 at 06:43:35AM -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Jul 24, 1997 at 06:43:35AM -0400, Randall Hopper wrote: > Luigi Rizzo: > |Randall Hopper: > |> Ok. Well, the only commercial app I have this info for is the MpegTV's > |> Linux mtv, since I buzzed it out when debugging the no-audio problem > |> (before dumping it for the FreeBSD version). Here's the /dev/dsp ioctls it > |> uses: > | > |Thanks for the detailed list. > | > |I am looking at the DSP_SETFRAGMENT thing, and while I have no problem > |to implement it with the required features, it sounds quite odd that > |the application requires many small buffers. If they are small it means > |the app wants low latency, so why ask for many ? > > Small buffers gets it low latency on write()s. Many buffers minimizes the > chance that the driver will have played everything by the time that it gets > around to feeding it again. In addition, many small buffers allow applications do occasional large write()s and not have to worry about waiting for several buffers to empty before the write() can return. From owner-freebsd-multimedia Thu Jul 24 07:48:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02378 for multimedia-outgoing; Thu, 24 Jul 1997 07:48:15 -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 HAA02373 for ; Thu, 24 Jul 1997 07:48:09 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA26145; Thu, 24 Jul 1997 15:38:55 +0200 From: Luigi Rizzo Message-Id: <199707241338.PAA26145@labinfo.iet.unipi.it> Subject: Re: dma handling in the sound driver To: brianc@milkyway.com (Brian Campbell) Date: Thu, 24 Jul 1997 15:38:55 +0200 (MET DST) Cc: freebsd-multimedia@FreeBSD.ORG In-Reply-To: <19970724092558.31924@milkyway.com> from "Brian Campbell" at Jul 24, 97 09:25:39 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > |Thanks for the detailed list. > > | > > |I am looking at the DSP_SETFRAGMENT thing, and while I have no problem > > |to implement it with the required features, it sounds quite odd that > > |the application requires many small buffers. If they are small it means > > |the app wants low latency, so why ask for many ? > > > > Small buffers gets it low latency on write()s. Many buffers minimizes the > > chance that the driver will have played everything by the time that it gets > > around to feeding it again. > > In addition, many small buffers allow applications do occasional large > write()s and not have to worry about waiting for several buffers to > empty before the write() can return. Well my point was that that way of requesting buffers is vstrictly related to the particular implementation. I believe the correct request should be 'I want X bytes of total buffering, and be guaranteed that the chunk size is at most Y bytes'. Of course I can assume X = Y*n_buffers. As a matter of fact, I believe that the small buffer size is really important on reads, not on writes, since the chunk size (Y) determines how long an already scheduled dma operation will take, and this is only critical for a read. If you do a short write, either there is no pending data, and you can start a dma op with the correct size, or there is a pending dma transfer, and you have no other choice of queueing the data and waiting. In the read case, a short read with no pending dma transfer can request the exact number of bytes, but a if a dma read has already been started, you are stuck with whatever size was requested before, unless you can poll the status of a dma transfer (which we can now :> ) and invoke tsleep() to wait for data to arrive. BTW the new driver is progressing fast. Yesterday I could hear my PnP CS4236 play audio using SB emulation, and as soon as I get a few spare hours for testing other modes should be ready. 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 Thu Jul 24 07:49:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id HAA02421 for multimedia-outgoing; Thu, 24 Jul 1997 07:49: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 HAA02301 for ; Thu, 24 Jul 1997 07:47:44 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id PAA26156; Thu, 24 Jul 1997 15:43:15 +0200 From: Luigi Rizzo Message-Id: <199707241343.PAA26156@labinfo.iet.unipi.it> Subject: sb16 request To: rhh@ct.picker.com (Randall Hopper) Date: Thu, 24 Jul 1997 15:43:15 +0200 (MET DST) Cc: louie@TransSys.COM, multimedia@FreeBSD.ORG In-Reply-To: <19970724071551.54552@ct.picker.com> from "Randall Hopper" at Jul 24, 97 07:15:32 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi, I am looking at the sb16 operation in full duplex using dual dma (one 8-bit, the other 16-bit): Which one fo the following approaches people prefers: 1. always use 16-bit for play, 8-bit for record; 2. always use 16-bit for record, 8-bit for play; 3. allocate the 16-bit channel to the first type of request (read or write) and use the 8-bit channel for the other one. or 4. define a new ioctl to chose which channel gets the 16-bit dma and which one gets the 8-bit dma, with some default camong those described before. Cheers Luigi P.S. I don't have an SB16 so I will then need someone to help with testing... -----------------------------+-------------------------------------- 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 Thu Jul 24 08:33:25 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA04998 for multimedia-outgoing; Thu, 24 Jul 1997 08:33:25 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id IAA04992 for ; Thu, 24 Jul 1997 08:33:22 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA12404; Thu, 24 Jul 1997 08:31:54 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id LAA25743; Thu, 24 Jul 1997 11:31:53 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id LAA25104; Thu, 24 Jul 1997 11:31:52 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id KAA03007; Thu, 24 Jul 1997 10:31:46 -0500 (CDT) Date: Thu, 24 Jul 1997 10:31:46 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707241531.KAA03007@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: luigi@labinfo.iet.unipi.it Cc: rhh@ct.picker.com, louie@TransSys.COM, multimedia@FreeBSD.ORG Subject: sb16 request References: <19970724071551.54552@ct.picker.com> <199707241343.PAA26156@labinfo.iet.unipi.it> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Luigi Rizzo on Thu, 24 July: : 2. always use 16-bit for record, 8-bit for play; Definitely. (Recording can be replayed a thousand times, but play only happens once. The more permanent product should get the benefit of quality.) : 4. define a new ioctl to chose which channel gets the 16-bit dma and : which one gets the 8-bit dma, with some default camong those : described before. This is 2 with sprinkles, and sprinkles are nice, if you can afford the extra dime. From owner-freebsd-multimedia Thu Jul 24 08:44:36 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA05886 for multimedia-outgoing; Thu, 24 Jul 1997 08:44: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 IAA05873 for ; Thu, 24 Jul 1997 08:44:30 -0700 (PDT) Received: from ct.picker.com by whqvax.picker.com with SMTP; Thu, 24 Jul 1997 11:39:24 -0400 (EDT) Received: from elmer.ct.picker.com ([144.54.57.34]) by ct.picker.com (4.1/SMI-4.1) id AA04499; Thu, 24 Jul 97 11:39:21 EDT Received: by elmer.ct.picker.com (SMI-8.6/SMI-SVR4) id LAA21713; Thu, 24 Jul 1997 11:37:06 -0400 Message-Id: <19970724113706.51706@ct.picker.com> Date: Thu, 24 Jul 1997 11:37:06 -0400 From: Randall Hopper To: Luigi Rizzo Cc: multimedia@FreeBSD.ORG Subject: Re: sb16 request References: <19970724071551.54552@ct.picker.com> <199707241343.PAA26156@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707241343.PAA26156@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Jul 24, 1997 at 03:43:15PM +0200 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Luigi Rizzo: |I am looking at the sb16 operation in full duplex using dual dma (one |8-bit, the other 16-bit): Hey, cool! |Which one fo the following approaches people prefers: | |1. always use 16-bit for play, 8-bit for record; |2. always use 16-bit for record, 8-bit for play; |3. allocate the 16-bit channel to the first type of request (read or | write) and use the 8-bit channel for the other one. | |or | |4. define a new ioctl to chose which channel gets the 16-bit dma and | which one gets the 8-bit dma, with some default camong those | described before. 4. sounds like the most flexible to me. Selectable, but with a default. For the interface, can the 8-bit/16-bit under-the-hood be hidden? That is, the client opens dsp and selects 8-bit or 16-bit, and the recorded samples fed to the driver as well as the played samples read back from the driver are both in that format. I.e. have the driver convert the 8-bit to 16 if 16-bit selected, or the 16-bit down to 8 if 8-bit selected. I'd be concerned about driver overhead with this suggestion, but there's no math involved and it's a very cheap conversion so it might be worth it to abstract implementation tricks under the hood. Would make it easier to use existing full-duplex apps. Also, I'm curious. For full-duplex, does the client open /dev/dsp with O_RDWR instead of O_RDONLY and O_WRONLY, and then interleaved reads and writes are both valid on that descriptor? That would be pretty simple. |P.S. I don't have an SB16 so I will then need someone to help with |testing... Be glad to. Just let me know. Randall From owner-freebsd-multimedia Thu Jul 24 09:19:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08016 for multimedia-outgoing; Thu, 24 Jul 1997 09:19:12 -0700 (PDT) Received: from gdi.uoregon.edu (cisco-ts14-line1.uoregon.edu [128.223.150.167]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id JAA08009 for ; Thu, 24 Jul 1997 09:19:07 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id JAA01408; Thu, 24 Jul 1997 09:19:01 -0700 (PDT) Date: Thu, 24 Jul 1997 09:19:00 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Yuuichi Itakura cc: multimedia@FreeBSD.ORG Subject: Re: Inquiry In-Reply-To: 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 On Wed, 23 Jul 1997, Yuuichi Itakura wrote: > I found your homepage via Magellan Search. I recently purchased a vi > deo capture board with a bt848 chip. Although the device is recogniz > ed 'working properly' in the Device Manager of W95, the Microsoft Vid > Cap returns "Cannot initialize the device". How do I cope with this? > Do I need a new driver? You've found information regarding the use of the bt848-based capture boards with FreeBSD, a UNIX-style operating system. We don't support Windoze drivers here, sorry. You need to contact the manufacturer of your board for driver support. > Please advice. Thank you very much. By the way, was Brooktree acqui > red by Rockwell Semiconductors? I hadn't heard anything, but I generally don't keep track of that sort of thing. :) 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 Thu Jul 24 09:24:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08361 for multimedia-outgoing; Thu, 24 Jul 1997 09:24: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 JAA08316 for ; Thu, 24 Jul 1997 09:23: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 JAA14076; Thu, 24 Jul 1997 09:23:33 -0700 (PDT) Message-Id: <199707241623.JAA14076@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: rhh@ct.picker.com (Randall Hopper), louie@TransSys.COM, multimedia@FreeBSD.ORG Subject: Re: sb16 request In-reply-to: Your message of "Thu, 24 Jul 1997 15:43:15 +0200." <199707241343.PAA26156@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 1997 09:23:33 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Luigi Rizzo : > Hi, > > I am looking at the sb16 operation in full duplex using dual dma (one > 8-bit, the other 16-bit): > > Which one fo the following approaches people prefers: > > 1. always use 16-bit for play, 8-bit for record; > 2. always use 16-bit for record, 8-bit for play; > 3. allocate the 16-bit channel to the first type of request (read or > write) and use the 8-bit channel for the other one. > > or > > 4. define a new ioctl to chose which channel gets the 16-bit dma and > which one gets the 8-bit dma, with some default camong those > described before. I prefer an ioctl to chose which channel is for 16 bit . If I had to hardwired the choice , I would chose , 16 bit for recording and 8 bit for playback. Amancio From owner-freebsd-multimedia Thu Jul 24 09:27:48 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id JAA08810 for multimedia-outgoing; Thu, 24 Jul 1997 09:27: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 JAA08798 for ; Thu, 24 Jul 1997 09:27:42 -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 JAA14155 for ; Thu, 24 Jul 1997 09:27:45 -0700 (PDT) Message-Id: <199707241627.JAA14155@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: multimedia@freebsd.org Subject: guspnp12 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 1997 09:27:45 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I just pulled out guspnp12 out of my ftp site till I fix the configuration problems for the sb cards. Cheers, Amancio From owner-freebsd-multimedia Thu Jul 24 10:01:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11358 for multimedia-outgoing; Thu, 24 Jul 1997 10:01: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 KAA11350 for ; Thu, 24 Jul 1997 10:01:01 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id KAA14496; Thu, 24 Jul 1997 10:00:47 -0700 (PDT) Message-Id: <199707241700.KAA14496@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Doug White cc: Yuuichi Itakura , multimedia@FreeBSD.ORG Subject: Re: Inquiry In-reply-to: Your message of "Thu, 24 Jul 1997 09:19:00 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 1997 10:00:46 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Doug, Most of us know that we are not about Win95 so a simple mail to the sender is sufficient. Since you have time to post , how is the latest sound driver behaving for your GUS PnP? Regards, Amancio >From The Desk Of Doug White : > On Wed, 23 Jul 1997, Yuuichi Itakura wrote: > > > I found your homepage via Magellan Search. I recently purchased a vi > > deo capture board with a bt848 chip. Although the device is recogniz > > ed 'working properly' in the Device Manager of W95, the Microsoft Vid > > Cap returns "Cannot initialize the device". How do I cope with this? > > Do I need a new driver? > > You've found information regarding the use of the bt848-based capture > boards with FreeBSD, a UNIX-style operating system. We don't support > Windoze drivers here, sorry. You need to contact the manufacturer of your > board for driver support. > > > Please advice. Thank you very much. By the way, was Brooktree acqui > > red by Rockwell Semiconductors? > > I hadn't heard anything, but I generally don't keep track of that sort of > thing. :) > > 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 Thu Jul 24 10:05:15 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA11728 for multimedia-outgoing; Thu, 24 Jul 1997 10:05:15 -0700 (PDT) Received: from gdi.uoregon.edu (cisco-ts14-line1.uoregon.edu [128.223.150.167]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA11722 for ; Thu, 24 Jul 1997 10:05:11 -0700 (PDT) Received: from localhost (dwhite@localhost) by gdi.uoregon.edu (8.8.5/8.8.5) with SMTP id KAA01519; Thu, 24 Jul 1997 10:05:03 -0700 (PDT) Date: Thu, 24 Jul 1997 10:05:03 -0700 (PDT) From: Doug White X-Sender: dwhite@localhost Reply-To: Doug White To: Amancio Hasty cc: multimedia@FreeBSD.ORG Subject: Re: Inquiry In-Reply-To: <199707241700.KAA14496@rah.star-gate.com> 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 On Thu, 24 Jul 1997, Amancio Hasty wrote: > Most of us know that we are not about Win95 so a simple mail to the > sender is sufficient. Sorry, standard habit is to cc: the list so it ends up in the archives and so everyone knows it's been answered. > Since you have time to post , how is the latest sound driver behaving > for your GUS PnP? I've been scared to try it since my existing system works soo well. I could swipe my office's zip drive, stash a functioning copy of my kernel on it, and work from there, if you want another data point. 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 Thu Jul 24 11:17:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA16267 for multimedia-outgoing; Thu, 24 Jul 1997 11:17: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 LAA16259 for ; Thu, 24 Jul 1997 11:17:13 -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 LAA14884; Thu, 24 Jul 1997 11:17:15 -0700 (PDT) Message-Id: <199707241817.LAA14884@rah.star-gate.com> To: Doug White cc: multimedia@FreeBSD.ORG Subject: Re: Inquiry In-reply-to: Your message of "Thu, 24 Jul 1997 10:05:03 PDT." Date: Thu, 24 Jul 1997 11:17:15 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sorry I don't buy this sort of argument. This group is generally well behave so please don't start spoiling it . As it is I am extremely busy and if the group turns into a circus I will find something else to do. As for the archive you can kill it , the search tool is barely useful. As for trying out new sound drivers , we do need more feedback. Amancio >From The Desk Of Doug White : > On Thu, 24 Jul 1997, Amancio Hasty wrote: > > > Most of us know that we are not about Win95 so a simple mail to the > > sender is sufficient. > > Sorry, standard habit is to cc: the list so it ends up in the archives and > so everyone knows it's been answered. > > > Since you have time to post , how is the latest sound driver behaving > > for your GUS PnP? > > I've been scared to try it since my existing system works soo well. I > could swipe my office's zip drive, stash a functioning copy of my kernel > on it, and work from there, if you want another data point. > > 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 Thu Jul 24 12:19:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA18756 for multimedia-outgoing; Thu, 24 Jul 1997 12:19:32 -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 MAA18736 for ; Thu, 24 Jul 1997 12:19:24 -0700 (PDT) Received: (from hasty@localhost) by rah.star-gate.com (8.8.5/8.8.5) id MAA15151 for multimedia@freebsd.org; Thu, 24 Jul 1997 12:19:29 -0700 (PDT) Date: Thu, 24 Jul 1997 12:19:29 -0700 (PDT) From: Amancio Hasty Message-Id: <199707241919.MAA15151@rah.star-gate.com> To: multimedia@freebsd.org Subject: Posting prefix Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk I am thinking about turning up the developement activity on the group. A simple way of quickly identifying a project or main activity thread is to prefix the subject line. For instance, sound driver related stuff "subj: [snddrv] new supper dupper feature" "subj: [video] new enhanced dvd support in fxtv" We don't have to rigorously enforced this rule however if we start adopting it will go a long way for carrying out multiple development projects. Thinking about projects , anyone has a cool idea for a multimedia project? (Driver, procedure, application, a feature for XYZ program, etc...) Enjoy, Amancio From owner-freebsd-multimedia Thu Jul 24 13:12:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA21491 for multimedia-outgoing; Thu, 24 Jul 1997 13:12:52 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA21483 for ; Thu, 24 Jul 1997 13:12:46 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id XAA29566; Thu, 24 Jul 1997 23:12:29 +0300 (EEST) Date: Thu, 24 Jul 1997 23:12:29 +0300 (EEST) Message-Id: <199707242012.XAA29566@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Posting prefix In-Reply-To: <199707241919.MAA15151@rah.star-gate.com> References: <199707241919.MAA15151@rah.star-gate.com> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > > I am thinking about turning up the developement activity on the group. > A simple way of quickly identifying a project or main activity thread > is to prefix the subject line. For instance, sound driver related > stuff "subj: [snddrv] new supper dupper feature" > "subj: [video] new enhanced dvd support in fxtv" > > We don't have to rigorously enforced this rule however if we start > adopting it will go a long way for carrying out multiple development > projects. > > Thinking about projects , anyone has a cool idea for a multimedia project? > (Driver, procedure, application, a feature for XYZ program, etc...) > I would say networked TV with interactive shows, pay-per-view, etc... Should keep you busy for a while. :-) Pete From owner-freebsd-multimedia Thu Jul 24 13:45:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id NAA23063 for multimedia-outgoing; Thu, 24 Jul 1997 13:45:51 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id NAA23057 for ; Thu, 24 Jul 1997 13:45:46 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA19148; Thu, 24 Jul 1997 13:45:14 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id QAA28627; Thu, 24 Jul 1997 16:45:12 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id QAA04912; Thu, 24 Jul 1997 16:45:09 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id PAA03915; Thu, 24 Jul 1997 15:45:09 -0500 (CDT) Date: Thu, 24 Jul 1997 15:45:09 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707242045.PAA03915@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hasty@rah.star-gate.com Cc: multimedia@FreeBSD.ORG Subject: Posting prefix References: <199707241919.MAA15151@rah.star-gate.com> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Amancio Hasty on Thu, 24 July: : A simple way of quickly identifying a project or main activity thread : is to prefix the subject line. For instance, sound driver related : stuff "subj: [snddrv] new supper dupper feature" : "subj: [video] new enhanced dvd support in fxtv" : : We don't have to rigorously enforced this rule however if we start : adopting it will go a long way for carrying out multiple development : projects. Why not just make a project-specific mailing list? : Thinking about projects , anyone has a cool idea for a multimedia project? : (Driver, procedure, application, a feature for XYZ program, etc...) What hardware MPEG-2 codecs are cheap? From owner-freebsd-multimedia Thu Jul 24 14:09:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24235 for multimedia-outgoing; Thu, 24 Jul 1997 14:09:45 -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 OAA24230 for ; Thu, 24 Jul 1997 14:09: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 OAA15542; Thu, 24 Jul 1997 14:09:43 -0700 (PDT) Message-Id: <199707242109.OAA15542@rah.star-gate.com> To: Petri Helenius cc: multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-reply-to: Your message of "Thu, 24 Jul 1997 23:12:29 +0300." <199707242012.XAA29566@silver.sms.fi> Date: Thu, 24 Jul 1997 14:09:42 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Sounds very interesting if we could only get hold of a h323 then such a project should be a "piece of cake" 8) Tnks! Amancio >From The Desk Of Petri Helenius : > Amancio Hasty writes: > > > > I am thinking about turning up the developement activity on the group. > > A simple way of quickly identifying a project or main activity thread > > is to prefix the subject line. For instance, sound driver related > > stuff "subj: [snddrv] new supper dupper feature" > > "subj: [video] new enhanced dvd support in fxtv" > > > > We don't have to rigorously enforced this rule however if we start > > adopting it will go a long way for carrying out multiple development > > projects. > > > > Thinking about projects , anyone has a cool idea for a multimedia project? > > (Driver, procedure, application, a feature for XYZ program, etc...) > > > I would say networked TV with interactive shows, pay-per-view, etc... > > Should keep you busy for a while. :-) > > Pete From owner-freebsd-multimedia Thu Jul 24 14:13:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24423 for multimedia-outgoing; Thu, 24 Jul 1997 14:13: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 OAA24415 for ; Thu, 24 Jul 1997 14:13: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 OAA15573; Thu, 24 Jul 1997 14:13:26 -0700 (PDT) Message-Id: <199707242113.OAA15573@rah.star-gate.com> To: Anthony.Kimball@East.Sun.COM cc: multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-reply-to: Your message of "Thu, 24 Jul 1997 15:45:09 CDT." <199707242045.PAA03915@compound.east.sun.com> Date: Thu, 24 Jul 1997 14:13:25 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk mpeg2 now thats another cool idea with the advent of writable dvds a project to support mpeg2 will be most cool . The missing link right now is a cheap mpeg2 hardware codec --- anyone got a lead? Tnks, Amancio >From The Desk Of Tony Kimball : > Quoth Amancio Hasty on Thu, 24 July: > : A simple way of quickly identifying a project or main activity thread > : is to prefix the subject line. For instance, sound driver related > : stuff "subj: [snddrv] new supper dupper feature" > : "subj: [video] new enhanced dvd support in fxtv" > : > : We don't have to rigorously enforced this rule however if we start > : adopting it will go a long way for carrying out multiple development > : projects. > > Why not just make a project-specific mailing list? > > : Thinking about projects , anyone has a cool idea for a multimedia project? > : (Driver, procedure, application, a feature for XYZ program, etc...) > > What hardware MPEG-2 codecs are cheap? > > > > > > > > From owner-freebsd-multimedia Thu Jul 24 14:21:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA24864 for multimedia-outgoing; Thu, 24 Jul 1997 14:21:53 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA24859 for ; Thu, 24 Jul 1997 14:21:50 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id AAA21100; Fri, 25 Jul 1997 00:21:40 +0300 (EEST) Date: Fri, 25 Jul 1997 00:21:40 +0300 (EEST) Message-Id: <199707242121.AAA21100@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Digital-TV-is-here-today: prefix In-Reply-To: <199707242109.OAA15542@rah.star-gate.com> References: <199707242012.XAA29566@silver.sms.fi> <199707242109.OAA15542@rah.star-gate.com> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > Sounds very interesting if we could only get hold of a h323 then > such a project should be a "piece of cake" 8) > If you mean where you get the specification, surf to www.itu.ch, but I'm not sure why do you need to do h323 for this? Wouldn't RTP, RSVP and RSTP do the trick just fine (with the addition of some HTTP?) Pete > Tnks! > Amancio > From The Desk Of Petri Helenius : > > Amancio Hasty writes: > > > > > > I am thinking about turning up the developement activity on the group. > > > A simple way of quickly identifying a project or main activity thread > > > is to prefix the subject line. For instance, sound driver related > > > stuff "subj: [snddrv] new supper dupper feature" > > > "subj: [video] new enhanced dvd support in fxtv" > > > > > > We don't have to rigorously enforced this rule however if we start > > > adopting it will go a long way for carrying out multiple development > > > projects. > > > > > > Thinking about projects , anyone has a cool idea for a multimedia project? > > > (Driver, procedure, application, a feature for XYZ program, etc...) > > > > > I would say networked TV with interactive shows, pay-per-view, etc... > > > > Should keep you busy for a while. :-) > > > > Pete From owner-freebsd-multimedia Thu Jul 24 14:28:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA25178 for multimedia-outgoing; Thu, 24 Jul 1997 14:28: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 OAA25173 for ; Thu, 24 Jul 1997 14:28: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 OAA15640; Thu, 24 Jul 1997 14:28:48 -0700 (PDT) Message-Id: <199707242128.OAA15640@rah.star-gate.com> To: Petri Helenius cc: multimedia@FreeBSD.ORG Subject: Re: Digital-TV-is-here-today: prefix In-reply-to: Your message of "Fri, 25 Jul 1997 00:21:40 +0300." <199707242121.AAA21100@silver.sms.fi> Date: Thu, 24 Jul 1997 14:28:48 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You are correct that the existing tools such as vic , vat, sdr are sufficient to kick off the project . Not sure when it is was posted however a little while ago there was posting from the Berkeley group about a "remote control" package for vic , vat and hopefully for sdr. The 323 stack would be cool to have to appeal to the 28.8 modem crowd. Now this sounds a like a cool project! Anyone interested in taking the lead on this one and start hammering out the overall approach? If someone decides to take the lead , one of the thinks that I would like to see done is to add an http link to the multimedia web page at freebsd.org pointing to the main project web page. Cool, Amancio >From The Desk Of Petri Helenius : > Amancio Hasty writes: > > Sounds very interesting if we could only get hold of a h323 then > > such a project should be a "piece of cake" 8) > > > If you mean where you get the specification, surf to www.itu.ch, but > I'm not sure why do you need to do h323 for this? Wouldn't RTP, RSVP > and RSTP do the trick just fine (with the addition of some HTTP?) > > Pete > > > Tnks! > > Amancio > > From The Desk Of Petri Helenius : > > > Amancio Hasty writes: > > > > > > > > I am thinking about turning up the developement activity on the group . > > > > A simple way of quickly identifying a project or main activity thread > > > > is to prefix the subject line. For instance, sound driver related > > > > stuff "subj: [snddrv] new supper dupper feature" > > > > "subj: [video] new enhanced dvd support in fxtv" > > > > > > > > We don't have to rigorously enforced this rule however if we start > > > > adopting it will go a long way for carrying out multiple development > > > > projects. > > > > > > > > Thinking about projects , anyone has a cool idea for a multimedia pro ject? > > > > (Driver, procedure, application, a feature for XYZ program, etc...) > > > > > > > I would say networked TV with interactive shows, pay-per-view, etc... > > > > > > Should keep you busy for a while. :-) > > > > > > Pete From owner-freebsd-multimedia Thu Jul 24 15:59:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA29755 for multimedia-outgoing; Thu, 24 Jul 1997 15:59:27 -0700 (PDT) Received: from pobox.com (ott-on3-16.netcom.ca [207.181.90.144]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA29750 for ; Thu, 24 Jul 1997 15:59:23 -0700 (PDT) Received: (from brianc@localhost) by pobox.com (8.8.5/8.8.5) id SAA00642; Thu, 24 Jul 1997 18:59:07 -0400 (EDT) Message-ID: <19970724185907.39493@pobox.com> Date: Thu, 24 Jul 1997 18:59:07 -0400 From: Brian Campbell To: freebsd-multimedia@FreeBSD.org Subject: Re: sb16 request References: <19970724071551.54552@ct.picker.com> <199707241343.PAA26156@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707241343.PAA26156@labinfo.iet.unipi.it>; from Luigi Rizzo on Thu, Jul 24, 1997 at 03:43:15PM +0200 Sender: owner-freebsd-multimedia@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk On Thu, Jul 24, 1997 at 03:43:15PM +0200, Luigi Rizzo wrote: > I am looking at the sb16 operation in full duplex using dual dma (one > 8-bit, the other 16-bit): > > Which one fo the following approaches people prefers: > > 1. always use 16-bit for play, 8-bit for record; > 2. always use 16-bit for record, 8-bit for play; > 3. allocate the 16-bit channel to the first type of request (read or > write) and use the 8-bit channel for the other one. > > or > > 4. define a new ioctl to chose which channel gets the 16-bit dma and > which one gets the 8-bit dma, with some default camong those > described before. There's already a mechanism to specify the number of bits used for playback/record and its format. The default on open() is 8-bit (I think) and I suppose it should remain that way. If either playback or record wants 16-bit then the appropriate ioctl should be used. If the other channel requested it first, the second will fail. I'm assuming two descriptors are in use, one RDONLY the other WRONLY. From owner-freebsd-multimedia Thu Jul 24 16:58:14 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA03127 for multimedia-outgoing; Thu, 24 Jul 1997 16:58:14 -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 QAA03111 for ; Thu, 24 Jul 1997 16:58: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 QAA16379; Thu, 24 Jul 1997 16:57:33 -0700 (PDT) Message-Id: <199707242357.QAA16379@rah.star-gate.com> To: Brian Campbell cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: sb16 request In-reply-to: Your message of "Thu, 24 Jul 1997 18:59:07 EDT." <19970724185907.39493@pobox.com> Date: Thu, 24 Jul 1997 16:57:32 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Currently on 3.5 based sound drivers , only one descriptor is used for read and write and I want to keep it that way given that most decent api's already support that mechanism --- sun and sgi . There is an ioctl to specify the number of bits perhaps it will be just as easy to extend it to support both read and write channels sample size . If I am not mistaken the current mechanism only uses a byte to specify 8 or 16 so a simple extension could be to specify the read channel bit size on the second half of the word. If not then the default should be that it applies to both read and write if the card supports full duplex operation;otherwise, it should only apply to the the read or write channel. Cheers, Amancio >From The Desk Of Brian Campbell : > On Thu, Jul 24, 1997 at 03:43:15PM +0200, Luigi Rizzo wrote: > > I am looking at the sb16 operation in full duplex using dual dma (one > > 8-bit, the other 16-bit): > > > > Which one fo the following approaches people prefers: > > > > 1. always use 16-bit for play, 8-bit for record; > > 2. always use 16-bit for record, 8-bit for play; > > 3. allocate the 16-bit channel to the first type of request (read or > > write) and use the 8-bit channel for the other one. > > > > or > > > > 4. define a new ioctl to chose which channel gets the 16-bit dma and > > which one gets the 8-bit dma, with some default camong those > > described before. > > There's already a mechanism to specify the number of bits used for > playback/record and its format. The default on open() is 8-bit (I > think) and I suppose it should remain that way. If either playback > or record wants 16-bit then the appropriate ioctl should be used. > If the other channel requested it first, the second will fail. > I'm assuming two descriptors are in use, one RDONLY the other > WRONLY. From owner-freebsd-multimedia Thu Jul 24 17:30:47 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA04671 for multimedia-outgoing; Thu, 24 Jul 1997 17:30:47 -0700 (PDT) Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA04665 for ; Thu, 24 Jul 1997 17:30:44 -0700 (PDT) Received: (from arg@localhost) by arg1.demon.co.uk (8.8.5/8.8.5) id BAA03132; Fri, 25 Jul 1997 01:29:04 +0100 (BST) Date: Fri, 25 Jul 1997 01:29:03 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Amancio Hasty cc: multimedia@freebsd.org Subject: Re: Posting prefix In-Reply-To: <199707242113.OAA15573@rah.star-gate.com> 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 On Thu, 24 Jul 1997, Amancio Hasty wrote: > mpeg2 now thats another cool idea with the advent of writable dvds > a project to support mpeg2 will be most cool . The missing link > right now is a cheap mpeg2 hardware codec --- anyone got a lead? I haven't found cheap mpeg2 (and I've been looking), but mpeg1 encoders seem to be getting cheap(er) at last. http://www.mpeg.co.uk/ quotes a hardware mpeg1 encoder for GBP400 ($650) http://www.visiblelight.com/mall/espresso/index.htp another one at $595 http://vitechts.com/dev.htm quotes chips in OEM quantities at $50. There's a list of assorted products at: http://www.visiblelight.com/mpeg/products/p_enc.htm There's also the Digital 21230 chip; I believe there are a number of products around using this, but I seem to have lost references to them. My dream device is a box that continuously records all channels (with about 24hrs memory) so that I never miss a programme and don't have to bother remembering to set the VCR! Since we have only 4 channels here, the hardware is just approaching a price at which this becomes plausible (and when we get more channels in a couple of years' time with digital transmission, they will arrive already MPEG encoded anyhow). From owner-freebsd-multimedia Thu Jul 24 21:14:02 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA12633 for multimedia-outgoing; Thu, 24 Jul 1997 21:14:02 -0700 (PDT) Received: from pobox.com (ott-on4-08.netcom.ca [207.181.90.200]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA12625 for ; Thu, 24 Jul 1997 21:13:56 -0700 (PDT) Received: (from brianc@localhost) by pobox.com (8.8.5/8.8.5) id AAA00806; Fri, 25 Jul 1997 00:13:44 -0400 (EDT) Message-ID: <19970725001344.59756@pobox.com> Date: Fri, 25 Jul 1997 00:13:44 -0400 From: Brian Campbell To: freebsd-multimedia@FreeBSD.ORG Subject: Re: sb16 request References: <19970724185907.39493@pobox.com> <199707242357.QAA16379@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76 In-Reply-To: <199707242357.QAA16379@rah.star-gate.com>; from Amancio Hasty on Thu, Jul 24, 1997 at 04:57:32PM -0700 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Thu, Jul 24, 1997 at 04:57:32PM -0700, Amancio Hasty wrote: > Currently on 3.5 based sound drivers , only one descriptor is used > for read and write and I want to keep it that way given that most > decent api's already support that mechanism --- sun and sgi . While I suppose the application can carefully interleave its reads and writes, it would seem to be more "full duplex" if one application could be reading while another is writing. I'm hoping the O_RDWR case doesn't preclude the read-only + write-only case. > There is an ioctl to specify the number of bits perhaps it will be > just as easy to extend it to support both read and write channels > sample size . If I am not mistaken the current mechanism only uses > a byte to specify 8 or 16 so a simple extension could be to specify > the read channel bit size on the second half of the word. If not > then the default should be that it applies to both read and write > if the card supports full duplex operation;otherwise, it should > only apply to the the read or write channel. I agree that if the card supports 16-bit playback and record simultaneously that specifying 16-bit sample size could apply to both. However, in the case of the SB16, the ioctl would have to fail. Or claim success and not actually change the sample size of either the record/playback channel. The question would then be, which channel actually got changed? I'd say if you open the device read/write then setting the sample size to 16-bit is ambiguous and should fail unless both the read/write directions support 16-bit simultaneously. If you want to mix 16-bit with 8-bit you can open the device twice. From owner-freebsd-multimedia Thu Jul 24 22:02:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA14505 for multimedia-outgoing; Thu, 24 Jul 1997 22:02:54 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14500 for ; Thu, 24 Jul 1997 22:02:47 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id IAA29406; Fri, 25 Jul 1997 08:02:28 +0300 (EEST) Date: Fri, 25 Jul 1997 08:02:28 +0300 (EEST) Message-Id: <199707250502.IAA29406@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Amancio Hasty Cc: Anthony.Kimball@East.Sun.COM, multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-Reply-To: <199707242113.OAA15573@rah.star-gate.com> References: <199707242045.PAA03915@compound.east.sun.com> <199707242113.OAA15573@rah.star-gate.com> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > mpeg2 now thats another cool idea with the advent of writable dvds > a project to support mpeg2 will be most cool . The missing link > right now is a cheap mpeg2 hardware codec --- anyone got a lead? > Are you speaking of encoder or decoder? The encoders are not cheap nor likely to be in the immediate future but for decoding, Matrox is coming up with a board which is supposed to be fairly inexpensive and the Creative DVD-ROM package already includes a decoder board too. Pete From owner-freebsd-multimedia Thu Jul 24 22:05:18 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA14637 for multimedia-outgoing; Thu, 24 Jul 1997 22:05:18 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id WAA14632 for ; Thu, 24 Jul 1997 22:05:12 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id IAA29597; Fri, 25 Jul 1997 08:05:01 +0300 (EEST) Date: Fri, 25 Jul 1997 08:05:01 +0300 (EEST) Message-Id: <199707250505.IAA29597@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Amancio Hasty Cc: multimedia@FreeBSD.ORG Subject: Re: Digital-TV-is-here-today: prefix In-Reply-To: <199707242128.OAA15640@rah.star-gate.com> References: <199707242121.AAA21100@silver.sms.fi> <199707242128.OAA15640@rah.star-gate.com> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > > The 323 stack would be cool to have to appeal to the 28.8 modem crowd. > Personally, I couldn't care less of sub-512kbps speeds :-) Pete From owner-freebsd-multimedia Thu Jul 24 22:47:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id WAA15703 for multimedia-outgoing; Thu, 24 Jul 1997 22:47:24 -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 WAA15698 for ; Thu, 24 Jul 1997 22:47:21 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA27161; Fri, 25 Jul 1997 06:46:18 +0200 From: Luigi Rizzo Message-Id: <199707250446.GAA27161@labinfo.iet.unipi.it> Subject: Re: sb16 request To: rhh@ct.picker.com (Randall Hopper) Date: Fri, 25 Jul 1997 06:46:17 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <19970724113706.51706@ct.picker.com> from "Randall Hopper" at Jul 24, 97 11:36:47 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Luigi Rizzo: > |I am looking at the sb16 operation in full duplex using dual dma (one > |8-bit, the other 16-bit): > > |Which one fo the following approaches people prefers: > | > |1. always use 16-bit for play, 8-bit for record; ... to clarify: I am making the assumption that 16-bit data cannot be transferred using an 8-bit channel and vice-versa when using full-duplex. This might be a wrong assumption, in which case life is much easier since you can use high quality audio on both directions. > For the interface, can the 8-bit/16-bit under-the-hood be hidden? That is, to some extent, yes. But 8-bit is really poor quality and I'd rather use 16-bit (e.g. when converting from/to uLAW) if possible. > Also, I'm curious. For full-duplex, does the client open /dev/dsp with > O_RDWR instead of O_RDONLY and O_WRONLY, and then interleaved reads and > writes are both valid on that descriptor? That would be pretty simple. This is another, more general, issue. Right now, in the new sound driver, I am using only one descriptor, and either the client interleaves reads and writes, or it forks and then the two process can do i/o concurrently (I have two separate busy flags, one for reading the other for writing, and one 'global' busy flag to aviod two opens). However my final plan is to support up to two descriptors (i.e. opens) on the same device. That way you can settle a phone-type application with cat /dev/audio | rsh remotehost cat > /dev/audio & rsh remotehost cat < /dev/audio | cat > /dev/audio & which is quite nice (I have done it in the past using the Audioserver software on a DEC). The two-descriptors solution should not break anything (Amancio was concerned with backward compatibility). Cheers Luigi From owner-freebsd-multimedia Thu Jul 24 23:24:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA16954 for multimedia-outgoing; Thu, 24 Jul 1997 23:24: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 XAA16949 for ; Thu, 24 Jul 1997 23:24: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 XAA17813; Thu, 24 Jul 1997 23:23:35 -0700 (PDT) Message-Id: <199707250623.XAA17813@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: rhh@ct.picker.com (Randall Hopper), multimedia@FreeBSD.ORG Subject: Re: sb16 request In-reply-to: Your message of "Fri, 25 Jul 1997 06:46:17 +0200." <199707250446.GAA27161@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 24 Jul 1997 23:23:34 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of Luigi Rizzo : > > Luigi Rizzo: > > |I am looking at the sb16 operation in full duplex using dual dma (one > > |8-bit, the other 16-bit): > > > > |Which one fo the following approaches people prefers: > > | > > |1. always use 16-bit for play, 8-bit for record; > ... > > to clarify: I am making the assumption that 16-bit data cannot be > transferred using an 8-bit channel and vice-versa when using > full-duplex. > This might be a wrong assumption, in which case life is much easier > since you can use high quality audio on both directions. > > > For the interface, can the 8-bit/16-bit under-the-hood be hidden? That is, > > to some extent, yes. But 8-bit is really poor quality and I'd rather > use 16-bit (e.g. when converting from/to uLAW) if possible. > > > Also, I'm curious. For full-duplex, does the client open /dev/dsp with > > O_RDWR instead of O_RDONLY and O_WRONLY, and then interleaved reads and > > writes are both valid on that descriptor? That would be pretty simple. > > This is another, more general, issue. > > Right now, in the new sound driver, I am using only one descriptor, and > either the client interleaves reads and writes, or it forks and then > the two process can do i/o concurrently (I have two separate busy > flags, one for reading the other for writing, and one 'global' busy > flag to aviod two opens). > > However my final plan is to support up to two descriptors (i.e. opens) > on the same device. That way you can settle a phone-type application > with > > cat /dev/audio | rsh remotehost cat > /dev/audio & > rsh remotehost cat < /dev/audio | cat > /dev/audio & > > which is quite nice (I have done it in the past using the Audioserver > software on a DEC). > > The two-descriptors solution should not break anything (Amancio was > concerned with backward compatibility). > > Cheers > Luigi Yes , it break existing solutions and it does make porting of other sound apps from traditional sound api such as from sgi, sun or hp harder . If you want to multiplex sound streams then I suggest people do it via some mechanism such as NCD's Network audio . Last but not least we will not be compatible with the linux audio ioctl api and at least to me that is far more important given that the group as whole is not into writing sound apps. Do whatever you can with the SB thingies we know its limitations if people want better quality we can then recommend superior sound cards. Amancio From owner-freebsd-multimedia Fri Jul 25 00:07:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18543 for multimedia-outgoing; Fri, 25 Jul 1997 00:07:46 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA18538 for ; Fri, 25 Jul 1997 00:07:42 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA27097; Fri, 25 Jul 1997 00:06:38 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id DAA26913; Fri, 25 Jul 1997 03:06:36 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id DAA15616; Fri, 25 Jul 1997 03:06:36 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id CAA03136; Fri, 25 Jul 1997 02:06:28 -0500 (CDT) Date: Fri, 25 Jul 1997 02:06:28 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707250706.CAA03136@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: pete@sms.fi Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG Subject: Re: Posting prefix References: <199707242045.PAA03915@compound.east.sun.com> <199707242113.OAA15573@rah.star-gate.com> <199707250502.IAA29406@silver.sms.fi> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Petri Helenius on Fri, 25 July: : Are you speaking of encoder or decoder? The encoders are not cheap nor : likely to be in the immediate future Is the mpeg2 format documented online? I understand that conventional wisdom requires hardware assist, but that just represents an algorithmic challenge.... From owner-freebsd-multimedia Fri Jul 25 00:09:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18618 for multimedia-outgoing; Fri, 25 Jul 1997 00:09:46 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA18613 for ; Fri, 25 Jul 1997 00:09:43 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA27495; Fri, 25 Jul 1997 00:09:09 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id DAA27184; Fri, 25 Jul 1997 03:09:07 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id DAA15690; Fri, 25 Jul 1997 03:09:06 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id CAA03154; Fri, 25 Jul 1997 02:08:59 -0500 (CDT) Date: Fri, 25 Jul 1997 02:08:59 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707250708.CAA03154@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: luigi@labinfo.iet.unipi.it Cc: rhh@ct.picker.com, multimedia@FreeBSD.ORG Subject: Re: sb16 request References: <19970724113706.51706@ct.picker.com> <199707250446.GAA27161@labinfo.iet.unipi.it> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Luigi Rizzo on Fri, 25 July: : to clarify: I am making the assumption that 16-bit data cannot be : transferred using an 8-bit channel and vice-versa when using : full-duplex. : This might be a wrong assumption, in which case life is much easier : since you can use high quality audio on both directions. I would like to advocate the solution of Randall Hopper, that the 8-bit channel should support a 16-bit data stream interface. From owner-freebsd-multimedia Fri Jul 25 00:12:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA18877 for multimedia-outgoing; Fri, 25 Jul 1997 00:12:43 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA18870 for ; Fri, 25 Jul 1997 00:12:38 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id KAA14579; Fri, 25 Jul 1997 10:12:33 +0300 (EEST) Date: Fri, 25 Jul 1997 10:12:33 +0300 (EEST) Message-Id: <199707250712.KAA14579@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Anthony.Kimball@East.Sun.COM Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-Reply-To: <199707250706.CAA03136@compound.east.sun.com> References: <199707242045.PAA03915@compound.east.sun.com> <199707242113.OAA15573@rah.star-gate.com> <199707250502.IAA29406@silver.sms.fi> <199707250706.CAA03136@compound.east.sun.com> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tony Kimball writes: > Quoth Petri Helenius on Fri, 25 July: > : Are you speaking of encoder or decoder? The encoders are not cheap nor > : likely to be in the immediate future > > Is the mpeg2 format documented online? I understand that conventional > wisdom requires hardware assist, but that just represents an > algorithmic challenge.... > I didn't attend the demonstration myself but there are multiple sources claiming that MPEG-2 decode can be done at the ballpark power of 233-266 Pentium_II (using MMX extensions) Pete From owner-freebsd-multimedia Fri Jul 25 00:15:49 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19114 for multimedia-outgoing; Fri, 25 Jul 1997 00:15: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 AAA19108 for ; Fri, 25 Jul 1997 00:15: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 AAA18199; Fri, 25 Jul 1997 00:15:42 -0700 (PDT) Message-Id: <199707250715.AAA18199@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Anthony.Kimball@East.Sun.COM cc: pete@sms.fi, multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-reply-to: Your message of "Fri, 25 Jul 1997 02:06:28 CDT." <199707250706.CAA03136@compound.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 1997 00:15:42 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk You got a point specially with MMX instructions now days at least I don't think that we require hardware assist for mpeg2 with MMX and a P166. The real challenge is software mpeg2 encoding ... I don't think that the mpeg2 standard is online. Anyone got a pointer? Tnks, Amancio >From The Desk Of Tony Kimball : > Quoth Petri Helenius on Fri, 25 July: > : Are you speaking of encoder or decoder? The encoders are not cheap nor > : likely to be in the immediate future > > Is the mpeg2 format documented online? I understand that conventional > wisdom requires hardware assist, but that just represents an > algorithmic challenge.... > From owner-freebsd-multimedia Fri Jul 25 00:26:22 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19408 for multimedia-outgoing; Fri, 25 Jul 1997 00:26:22 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19402 for ; Fri, 25 Jul 1997 00:26:19 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA29657; Fri, 25 Jul 1997 00:25:13 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id DAA27608; Fri, 25 Jul 1997 03:25:12 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id DAA16029; Fri, 25 Jul 1997 03:25:12 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id CAA03287; Fri, 25 Jul 1997 02:25:02 -0500 (CDT) Date: Fri, 25 Jul 1997 02:25:02 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707250725.CAA03287@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hasty@rah.star-gate.com Cc: Anthony.Kimball@East.Sun.COM, pete@sms.fi, multimedia@FreeBSD.ORG Subject: Re: Posting prefix References: <199707250706.CAA03136@compound.east.sun.com> <199707250715.AAA18199@rah.star-gate.com> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Amancio Hasty on Fri, 25 July: : : I don't think that the mpeg2 standard is online. Anyone got a pointer? : The best info I've found since my last post is at http://www-inria-graphlib.inria.fr:8000/Faq From owner-freebsd-multimedia Fri Jul 25 00:27:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19452 for multimedia-outgoing; Fri, 25 Jul 1997 00:27:10 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id AAA19446 for ; Fri, 25 Jul 1997 00:27:05 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id KAA19998; Fri, 25 Jul 1997 10:26:58 +0300 (EEST) Date: Fri, 25 Jul 1997 10:26:58 +0300 (EEST) Message-Id: <199707250726.KAA19998@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: Amancio Hasty Cc: Anthony.Kimball@East.Sun.COM, multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-Reply-To: <199707250715.AAA18199@rah.star-gate.com> References: <199707250706.CAA03136@compound.east.sun.com> <199707250715.AAA18199@rah.star-gate.com> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty writes: > You got a point specially with MMX instructions now days at least I don't > think that we require hardware assist for mpeg2 with MMX and a P166. > The real challenge is software mpeg2 encoding ... > > > I don't think that the mpeg2 standard is online. Anyone got a pointer? > A good starting point (though requires more surfing from there on) is http://www.mpeg.org/ Pete From owner-freebsd-multimedia Fri Jul 25 00:34:46 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19728 for multimedia-outgoing; Fri, 25 Jul 1997 00:34:46 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA19722 for ; Fri, 25 Jul 1997 00:34:43 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA00874; Fri, 25 Jul 1997 00:34:10 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id DAA27872; Fri, 25 Jul 1997 03:34:09 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id DAA16080; Fri, 25 Jul 1997 03:34:09 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id CAA03326; Fri, 25 Jul 1997 02:34:03 -0500 (CDT) Date: Fri, 25 Jul 1997 02:34:03 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707250734.CAA03326@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: brianc@pobox.com Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: sb16 request References: <19970724185907.39493@pobox.com> <199707242357.QAA16379@rah.star-gate.com> <19970725001344.59756@pobox.com> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Brian Campbell on Fri, 25 July: : ...However, in the case of the SB16, the ioctl would have to : fail. Or claim success and not actually change the sample size of : either the record/playback channel. The question would then be, : which channel actually got changed? I would prefer, as Randall Hopper's post suggested, to think of the ioctl as changing the data stream from 8-bit to 16-bit. Let the driver interface abstract away from the hardware. When only 8-bit is supported in hardware, extend it. When only 16-bit is supported in hardware, round it. When two descriptors are being used, there is no ambiguity, and the programmer has perfect control. If Luigi does produce a driver which supports two descriptors, this resolves the problem of which channel to allocate, for the programmer can issue the ioctls to each descriptor independently. I think the only way to provide the ability to control the allocation, i.e. to change it from default, in the single-descriptor interface is to extend the interface. That would be nice, but I think that having a duplex capability is the first step: I shan't worry about getting desert until the entre is on the table. From owner-freebsd-multimedia Fri Jul 25 00:36:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA19853 for multimedia-outgoing; Fri, 25 Jul 1997 00:36:52 -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 AAA19846 for ; Fri, 25 Jul 1997 00:36:49 -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 AAA18371; Fri, 25 Jul 1997 00:36:49 -0700 (PDT) Message-Id: <199707250736.AAA18371@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Petri Helenius cc: Anthony.Kimball@East.Sun.COM, multimedia@FreeBSD.ORG Subject: Re: Posting prefix In-reply-to: Your message of "Fri, 25 Jul 1997 10:26:58 +0300." <199707250726.KAA19998@silver.sms.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 1997 00:36:49 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi Guys, We will need access to the official mpeg documents in order to really attempt to work on a very fast decoder or encoder. Cheers, Amancio >From The Desk Of Petri Helenius : > Amancio Hasty writes: > > You got a point specially with MMX instructions now days at least I don't > > think that we require hardware assist for mpeg2 with MMX and a P166. > > The real challenge is software mpeg2 encoding ... > > > > > > I don't think that the mpeg2 standard is online. Anyone got a pointer? > > > A good starting point (though requires more surfing from there on) is > http://www.mpeg.org/ > > Pete From owner-freebsd-multimedia Fri Jul 25 00:57:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id AAA20718 for multimedia-outgoing; Fri, 25 Jul 1997 00:57:06 -0700 (PDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by hub.freebsd.org (8.8.5/8.8.5) with SMTP id AAA20713 for ; Fri, 25 Jul 1997 00:57:04 -0700 (PDT) Received: from East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA03753; Fri, 25 Jul 1997 00:55:58 -0700 Received: from suneast.East.Sun.COM by East.Sun.COM (SMI-8.6/SMI-5.3) id DAA28202; Fri, 25 Jul 1997 03:55:57 -0400 Received: from compound.east.sun.com by suneast.East.Sun.COM (SMI-8.6/SMI-SVR4) id DAA16172; Fri, 25 Jul 1997 03:55:57 -0400 Received: (from alk@localhost) by compound.east.sun.com (8.8.6/8.7.3) id CAA03415; Fri, 25 Jul 1997 02:55:50 -0500 (CDT) Date: Fri, 25 Jul 1997 02:55:50 -0500 (CDT) Reply-To: Anthony.Kimball@East.Sun.COM Message-Id: <199707250755.CAA03415@compound.east.sun.com> From: Tony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: hasty@rah.star-gate.com Cc: pete@sms.fi, multimedia@FreeBSD.ORG Subject: Re: Posting prefix References: <199707250726.KAA19998@silver.sms.fi> <199707250736.AAA18371@rah.star-gate.com> X-Face: O9M"E%K;(f-Go/XDxL+pCxI5*gr[=FN@Y`cl1.Tn Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Quoth Amancio Hasty on Fri, 25 July: : Hi Guys, : : We will need access to the official mpeg documents in order to : really attempt to work on a very fast decoder or encoder. : Cheers, : Amancio : There is a broken link for an mpeg2 video codec at the www.mpeg.org site. However, mpeg2vidcodec_v12.tar.gz is in the FreeBSD distfiles and so I imagine has a port. The document is ISO/IEC 13818-2, ITU-T H.262. It costs 96 Swiss Francs at http://www.itu.int/itudoc/itu-t/rec/h/h262_30161.html I haven't got any of those, though:) From owner-freebsd-multimedia Fri Jul 25 01:41:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id BAA22434 for multimedia-outgoing; Fri, 25 Jul 1997 01:41: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 BAA22429 for ; Fri, 25 Jul 1997 01:41: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 BAA19430; Fri, 25 Jul 1997 01:41:57 -0700 (PDT) Message-Id: <199707250841.BAA19430@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Anthony.Kimball@East.Sun.COM cc: brianc@pobox.com, freebsd-multimedia@FreeBSD.ORG Subject: Re: sb16 request In-reply-to: Your message of "Fri, 25 Jul 1997 02:34:03 CDT." <199707250734.CAA03326@compound.east.sun.com> Date: Fri, 25 Jul 1997 01:41:57 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk We have full duplex capability for symetric channels . A bit of programming must be done to support 16 bit one way and 8 bit the other way. The defined formats are: # define AFMT_QUERY 0x00000000 /* Return current fmt */ # define AFMT_MU_LAW 0x00000001 # define AFMT_A_LAW 0x00000002 # define AFMT_IMA_ADPCM 0x00000004 # define AFMT_U8 0x00000008 # define AFMT_S16_LE 0x00000010 /* Little endian signed 16*/ # define AFMT_S16_BE 0x00000020 /* Big endian signed 16 */ # define AFMT_S8 0x00000040 # define AFMT_U16_LE 0x00000080 /* Little endian U16 */ # define AFMT_U16_BE 0x00000100 /* Big endian U16 */ # define AFMT_MPEG 0x00000200 /* MPEG (2) audio */ # We can use IOCTL SNDCTL_DSP_SAMPLESIZE to set the input, output or both channels . Given that the input argument for SNDCTL_DSP_SAMPLESIZE is an "int" we have enough room to specify both input and output channels. The SB module will have to be tweaked a little bit to support full duplex and the audio module (audio.c) will have to be modify to support translation from 8 to 16 bit or vice-versa as for the rest of the sound driver it already supports full duplex dma operations and is currently being used for cards such as the gus pnp or audiotrix pro. The other stumbling block for the SB cards is the accuracy of its clock for audio conferencing tools such as vat which depend on the sound card to derive its timing information . I guess we will have to wait till we have full duplex capability to find out if the more recent versions of the SB cards have a decent clock on them or not. It will not surprise if their clock nowdays is better given that Microsoft is recommending high accuracy clocks for sound cards . Enjoy, Amancio >From The Desk Of Tony Kimball : > Quoth Brian Campbell on Fri, 25 July: > : ...However, in the case of the SB16, the ioctl would have to > : fail. Or claim success and not actually change the sample size of > : either the record/playback channel. The question would then be, > : which channel actually got changed? > > I would prefer, as Randall Hopper's post suggested, to think of the > ioctl as changing the data stream from 8-bit to 16-bit. Let the > driver interface abstract away from the hardware. When only 8-bit is > supported in hardware, extend it. When only 16-bit is supported in > hardware, round it. > > When two descriptors are being used, there is no ambiguity, and > the programmer has perfect control. If Luigi does produce a driver > which supports two descriptors, this resolves the problem of > which channel to allocate, for the programmer can issue the ioctls > to each descriptor independently. > > I think the only way to provide the ability to control the allocation, > i.e. to change it from default, in the single-descriptor interface is > to extend the interface. That would be nice, but I think that having > a duplex capability is the first step: I shan't worry about getting > desert until the entre is on the table. > > > > > > > > > From owner-freebsd-multimedia Fri Jul 25 08:05:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id IAA07057 for multimedia-outgoing; Fri, 25 Jul 1997 08:05:04 -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 IAA07041 for ; Fri, 25 Jul 1997 08:04:59 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id QAA27683 for multimedia@freebsd.org; Fri, 25 Jul 1997 16:00:58 +0200 From: Luigi Rizzo Message-Id: <199707251400.QAA27683@labinfo.iet.unipi.it> Subject: partially working snap of the new sound code To: multimedia@freebsd.org Date: Fri, 25 Jul 1997 16:00:58 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk A partially working snapshot of the new sound code is available at http://www.iet.unipi.it/~luigi/snd970725,tgz Soundblaster input and output seem to work (at least in u-law and 8-bit mode). I am not sure how input from /dev/audio works. mss-mode output is starting to work, although there are still some bugs in the initialization of the card. There is not yet /dev/mixer support, so you are stuck with mic input and no volume control. If someone wants to test the code, feel free to report any success or problem. I am particularly interested to know if, in soundblaster mode, input from /dev/audio and /dev/dsp (using the microphone) works. Cheers Luigi From owner-freebsd-multimedia Fri Jul 25 11:35:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA17415 for multimedia-outgoing; Fri, 25 Jul 1997 11:35:52 -0700 (PDT) Received: from mach3.polbox.pl (root@mach3.polbox.pl [195.116.5.8]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA17408 for ; Fri, 25 Jul 1997 11:35:48 -0700 (PDT) Received: from lizard (rap1-cen175.opole.tpnet.pl [194.204.146.175]) by mach3.polbox.pl (8.8.2/8.6.9) with SMTP id TAA07542 for ; Fri, 25 Jul 1997 19:38:52 +0200 Reply-To: potok@free.polbox.pl Message-Id: <199707251738.TAA07542@mach3.polbox.pl> Comments: Authenticated sender is From: "Mariusz Potocki" Organization: Ovita - Nutricia Poland To: freebsd-multimedia@FreeBSD.ORG Date: Fri, 25 Jul 1997 20:45:49 +0100 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: 8 bit soundcard and Doom Priority: normal X-mailer: Pegasus Mail for Windows (v2.42a) Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Hi. Is it possible to get a sound using 8 bit SB clone and running Doom? I read something in readme file about kernel patches and device nodes to install, but it was about Linux system. If someone can explain me how to do it? Please cc me, I'm currently not subscribing this list. P.S. I'm running 2.2.1R and Xfree3.2 I compiled my kernel with snd0 and sb0 devices, so I can playback some sound from MOD and S3 files. TIA Mariusz From owner-freebsd-multimedia Fri Jul 25 17:10:55 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id RAA03630 for multimedia-outgoing; Fri, 25 Jul 1997 17:10:55 -0700 (PDT) Received: from george.arc.nasa.gov (george.arc.nasa.gov [128.102.194.142]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA03625 for ; Fri, 25 Jul 1997 17:10:52 -0700 (PDT) From: lamaster@george.arc.nasa.gov Received: by george.arc.nasa.gov (8.8.6/1.35) id RAA15761; Fri, 25 Jul 1997 17:09:00 -0700 (PDT) Date: Fri, 25 Jul 1997 17:09:00 -0700 (PDT) Message-Id: <199707260009.RAA15761@george.arc.nasa.gov> To: freebsd-multimedia@FreeBSD.ORG Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tony, Kimball, writes: >> > Quoth Petri Helenius on Fri, 25 July: >> > : Are you speaking of encoder or decoder? The encoders are not cheap nor >> > : likely to be in the immediate future >> > >> > Is the mpeg2 format documented online? I understand that conventional >> > wisdom requires hardware assist, but that just represents an >> > algorithmic challenge.... >> > >> I didn't attend the demonstration myself but there are multiple >> sources claiming that MPEG-2 decode can be done at the ballpark >> power of 233-266 Pentium_II (using MMX extensions) I didn't see a followup which answered the specifics here, so, I hope the following may help muddy the water. *Realtime* MPEG-2 *encoding* remains an expensive proposition, with *quality* MPEG-2 realtime hardware encoders costing > $50K U.S. or more. MPEG-2 is not symmetrical at all in terms of the amount of work it takes to encode versus decode. Encoding is much more expensive, and the higher quality you want [ie the better the image for a given bandwidth] the more expensive it gets. Broadcast-quality encoders are available from only a few vendors. Of course, it may be possible to do a simple lower-quality H/W encoder that doesn't do B-frames, etc., for - a few $K U.S. perhaps, but, I haven't seen it yet. Realtime MPEG-2 decoding, OTOH, should be just about within reach now on the latest processors from several vendors. MPEG-2 decoding has been demonstrated realtime on a modified PPro-200 (some boards like this were floating around about a year ago, with the details secret - but, I saw a non-secret *demo* of the capability), or, presumably, on a Pentium II - 266 using MMX, which should be roughly equivalent to the demo'd PPro 200. Not to mention 300 MHz Ultra 2's, 200 MHz SGI R10k-based systems, etc., using old-fashioned (efficient) programming. MPEG-1 decoding, for example, takes roughly a Pentium-166, a 75 MHz, SuperSPARC, or an R4600-133 MHz, with the minimum requirements then being SPECint92 of > ~110 perhaps, and memory bandwidth > ~60 MB/sec. on these systems. In fact, presumably it can be done with even less CPU power if using certain MPEG-1 assist-capable boards (e.g. supposedly the ATI Mach64 boards can somehow assist MPEG-1 decode with the correct API/library/drivers.) Getting back to MPEG-II decode, it should be is roughly 4X the MPEG-1 requirment, plus more for audio, so, very roughly, on the newer systems, SPECint95 > ~9, and B/W > ~240 MB/sec. This would be a 300 MHz Sun Ultra-3, an SGI Octane, etc., or, a 266 MHz Intel Pentium II, perhaps. That is, the integer performance is there, especially with MMX as a boost, although it may come up a little short on memory bandwidth. In any case, these processors are in the ballpark for doing MPEG-2 decode in software. However, it does take careful optimization of performance-critical loops. "Multimedia" instructions, such as MMX on Intel, but also available on HP, Sun, and eventually on SGI, will help with certain of these performance-critical functions (e.g. conversion from the MPEG-2 color space to RGB). See the IEEE Micro article last year on Multimedia instruction sets. Just to get a vague idea of what a FreeBSD/XFree86/PentiumPro200 system can do, for example, I have tested the H.261 software codec at various combinations of ~1 Mbps, at various H.261 quality levels, at frame rates of 10 fps, 20 fps, 24 fps, etc., and the PPro200 (ASUS Natoma, FreeBSD 3.0-current, XFree86 3.3, vic2.8, 352x288 image, doubled in size on the display side) uses about 20-33% of a PPro-200 CPU, total, for everything, including network overhead. Screen updates at 640x480 are handled OK, but, use much more of the CPU than they could/should (e.g. XF86_S3 using 8% of the CPU at 4 fps, 16% at 8 fps, for full-screen updates - extrapolating to 30 fps, it could use 60% of the CPU.). The H.261 codec is computationally friendly, so the system can handle it, but MPEG-2 decode will want most of the CPU, so it would be nice if the X server were better optimized for painting video images in a window. To summarize, software MPEG-2 decoding should be just within reach now on the fastest commodity microprocessor systems. In order to make it happen, highly optimized MPEG-2 software decoders, and (X Window System) servers are required, but most of the other software components already exist. [Things missing: e.g. I'm not sure if the MPEG-2 RTP encapsulation definition is complete&final.] -Hugh LaMaster Hugh LaMaster, M/S 258-5, ASCII Email: hlamaster@mail.arc.nasa.gov NASA Ames Research Center Or: lamaster@nas.nasa.gov Moffett Field, CA 94035-1000 No Junkmail: USC 18 section 2701 Phone: 415/604-1056 Disclaimer: Unofficial, personal *opinion*. From owner-freebsd-multimedia Fri Jul 25 18:43:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id SAA07808 for multimedia-outgoing; Fri, 25 Jul 1997 18:43: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 SAA07802 for ; Fri, 25 Jul 1997 18:43:51 -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 SAA00696; Fri, 25 Jul 1997 18:43:46 -0700 (PDT) Message-Id: <199707260143.SAA00696@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: lamaster@george.arc.nasa.gov cc: freebsd-multimedia@FreeBSD.ORG In-reply-to: Your message of "Fri, 25 Jul 1997 17:09:00 PDT." <199707260009.RAA15761@george.arc.nasa.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Jul 1997 18:43:46 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >From The Desk Of lamaster@george.arc.nasa.gov : > friendly, so the system can handle it, but MPEG-2 decode will want > most of the CPU, so it would be nice if the X server were better > optimized for painting video images in a window. With respect to the X server and additional functionality needed to support high speed mpeg decoding what we need is: 1. yuv to rgb in hardware . matrox and s3 cards support such functionality 2. scaling with antialising. matrox and s3 cards support such functionality 4. Direct Memory access is already provided by DGA and is proving to be useful for cool video apps such as fxtv . 3. For Pentium Pros and Pentium II enable write combining for the frame buffer. This can boost the memory bandwith to the frame buffer by a factor or 5 so . Typically, when write combining is not enabled the thruput to a PCI frame buffer is around 20MBs or so when when write combining is enable the thruput for a decent video adapter jumps to 80MB/sec to 90MB/sec. You can easily test this assumption by dowloading the DOS utility fastvid. I managed to write something similar so if anyone is interested just e-mail me. On Win95 and WinNT the above functionality is readily available at least the first two via directdraw so we should come up with a cool api to do the same thing 8) Also anyone with a databook for a modern graphic adapter should be able to code up a simple api . That, Thats, All Folks 8) Amancio From owner-freebsd-multimedia Sat Jul 26 12:45:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA16170 for multimedia-outgoing; Sat, 26 Jul 1997 12:45:09 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA16161 for ; Sat, 26 Jul 1997 12:45:05 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id PAA00779; Sat, 26 Jul 1997 15:44:56 -0400 (EDT) Message-Id: <199707261944.PAA00779@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Amancio Hasty cc: multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707240240.TAA08628@rah.star-gate.com> In-reply-to: Your message of "Wed, 23 Jul 1997 19:40:57 PDT." <199707240240.TAA08628@rah.star-gate.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 15:44:55 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I think that I may be on to why the 'mixer' command has stopped working. When installing the new sound drivers, I've been replacing the soundcard.h file with the on included in the sound driver distribution. What I noticed is that programs which worked before I recompiled them would stop working after they were built. Firing up gdb on old and new binaries, I see that the ioctl() system call is being passed different commands. Looking at header files, I see: #define IOCPARM_MASK 0x7f /* parameters must be < 128 bytes */ #define IOC_VOID 0x00000000 /* no parameters */ #define IOC_OUT 0x20000000 /* copy out parameters */ #define IOC_IN 0x40000000 /* copy in parameters */ #define IOC_INOUT (IOC_IN|IOC_OUT) /* the 0x20000000 is so we can distinguish new ioctl's from old */ #define _IO(x,y) ((int)(IOC_VOID|(x<<8)|y)) #define _IOR(x,y,t) ((int)(IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)) #define _IOW(x,y,t) ((int)(IOC_IN|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)) /* this should be _IORW, but stdio got there first */ #define _IOWR(x,y,t) ((int)(IOC_INOUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)) in the soundcard.h file, but looking at /usr/include/sys/ioccom.h: #define IOCPARM_MASK 0x1fff /* parameter length, at most 13 bits */ #define IOCPARM_LEN(x) (((x) >> 16) & IOCPARM_MASK) #define IOCBASECMD(x) ((x) & ~(IOCPARM_MASK << 16)) #define IOCGROUP(x) (((x) >> 8) & 0xff) #define IOCPARM_MAX PAGE_SIZE /* max size of ioctl, mult. of PAGE_SIZE */ #define IOC_VOID 0x20000000 /* no parameters */ #define IOC_OUT 0x40000000 /* copy out parameters */ #define IOC_IN 0x80000000 /* copy in parameters */ #define IOC_INOUT (IOC_IN|IOC_OUT) #define IOC_DIRMASK 0xe0000000 /* mask for IN/OUT/VOID */ #define _IOC(inout,group,num,len) \ (inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num)) #define _IO(g,n) _IOC(IOC_VOID, (g), (n), 0) #define _IOR(g,n,t) _IOC(IOC_OUT, (g), (n), sizeof(t)) #define _IOW(g,n,t) _IOC(IOC_IN, (g), (n), sizeof(t)) /* this should be _IORW, but stdio got there first */ #define _IOWR(g,n,t) _IOC(IOC_INOUT, (g), (n), sizeof(t)) Notice how IOC_OUT, IOC_IN, IOC_VOID are different between the two. I think that soundcard.h should just #include if _IOR isn't defined, rather than doing its own thing like this. I'm going to try rebuilding stuff with this change and see what happens. louie From owner-freebsd-multimedia Sat Jul 26 12:50:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA16587 for multimedia-outgoing; Sat, 26 Jul 1997 12:50:07 -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 MAA16582 for ; Sat, 26 Jul 1997 12:50:05 -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 MAA10679; Sat, 26 Jul 1997 12:49:49 -0700 (PDT) Message-Id: <199707261949.MAA10679@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Louis A. Mamakos" cc: multimedia@FreeBSD.ORG Subject: [snddrv] Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-reply-to: Your message of "Sat, 26 Jul 1997 15:44:55 EDT." <199707261944.PAA00779@whizzo.TransSys.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 12:49:49 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk "Sounds" mighty good to me !! Currently, I trying to figured out why the SB16 is generating a click at the start and stop of a sound stream with the guspnp12 driver. It is a weird problem :( Tnks! Amancio >From The Desk Of "Louis A. Mamakos" : > > I think that I may be on to why the 'mixer' command has stopped working. > > When installing the new sound drivers, I've been replacing the soundcard.h > file with the on included in the sound driver distribution. What I noticed > is that programs which worked before I recompiled them would stop working > after they were built. Firing up gdb on old and new binaries, I see > that the ioctl() system call is being passed different commands. Looking > at header files, I see: > > #define IOCPARM_MASK 0x7f /* parameters must be < 128 byt es */ > #define IOC_VOID 0x00000000 /* no parameters */ > #define IOC_OUT 0x20000000 /* copy out parameters */ > #define IOC_IN 0x40000000 /* copy in parameters */ > #define IOC_INOUT (IOC_IN|IOC_OUT) > /* the 0x20000000 is so we can distinguish new ioctl's from old */ > #define _IO(x,y) ((int)(IOC_VOID|(x<<8)|y)) > #define _IOR(x,y,t) ((int)(IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|( x<<8)|y)) > #define _IOW(x,y,t) ((int)(IOC_IN|((sizeof(t)&IOCPARM_MASK)<<16)|(x <<8)|y)) > /* this should be _IORW, but stdio got there first */ > #define _IOWR(x,y,t) ((int)(IOC_INOUT|((sizeof(t)&IOCPARM_MASK)<<16) |(x<<8)|y)) > > in the soundcard.h file, but looking at /usr/include/sys/ioccom.h: > > > #define IOCPARM_MASK 0x1fff /* parameter length, at most 13 bits */ > #define IOCPARM_LEN(x) (((x) >> 16) & IOCPARM_MASK) > #define IOCBASECMD(x) ((x) & ~(IOCPARM_MASK << 16)) > #define IOCGROUP(x) (((x) >> 8) & 0xff) > > #define IOCPARM_MAX PAGE_SIZE /* max size of ioctl, m ult. of PAGE_SIZE */ > #define IOC_VOID 0x20000000 /* no parameters */ > #define IOC_OUT 0x40000000 /* copy out parameters */ > #define IOC_IN 0x80000000 /* copy in parameters */ > #define IOC_INOUT (IOC_IN|IOC_OUT) > #define IOC_DIRMASK 0xe0000000 /* mask for IN/OUT/VOID */ > > #define _IOC(inout,group,num,len) \ > (inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num)) > #define _IO(g,n) _IOC(IOC_VOID, (g), (n), 0) > #define _IOR(g,n,t) _IOC(IOC_OUT, (g), (n), sizeof(t)) > #define _IOW(g,n,t) _IOC(IOC_IN, (g), (n), sizeof(t)) > /* this should be _IORW, but stdio got there first */ > #define _IOWR(g,n,t) _IOC(IOC_INOUT, (g), (n), sizeof(t)) > > Notice how IOC_OUT, IOC_IN, IOC_VOID are different between the two. > > I think that soundcard.h should just #include if _IOR > isn't defined, rather than doing its own thing like this. I'm going > to try rebuilding stuff with this change and see what happens. > > louie > > > From owner-freebsd-multimedia Sat Jul 26 12:54:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA16827 for multimedia-outgoing; Sat, 26 Jul 1997 12:54:07 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id MAA16819 for ; Sat, 26 Jul 1997 12:54:04 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id PAA00871; Sat, 26 Jul 1997 15:54:01 -0400 (EDT) Message-Id: <199707261954.PAA00871@whizzo.TransSys.COM> X-Mailer: exmh version 2.0delta 6/3/97 To: Amancio Hasty cc: multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707240240.TAA08628@rah.star-gate.com> In-reply-to: Your message of "Wed, 23 Jul 1997 19:40:57 PDT." <199707240240.TAA08628@rah.star-gate.com> Mime-Version: 1.0 Content-Type: multipart/mixed ; boundary="==_Exmh_20290887880" Date: Sat, 26 Jul 1997 15:54:01 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a multipart MIME message. --==_Exmh_20290887880 Content-Type: text/plain; charset=us-ascii Ok, I made my change to soundcard.h, and now /usr/sbin/mixer can be rebuilt with guspnp11 and it works! Attached is the diff. I can see how this broke now; the mistaken value for IOC_OUT is currently interpreted by the kernel as IOC_VOID, which would result in nothing being copied out. louie --==_Exmh_20290887880 Content-Type: text/plain ; name="diff1"; charset=us-ascii Content-Description: diff1 Content-Disposition: attachment; filename="diff1" --- soundcard.h.orig Mon Jul 21 21:39:40 1997 +++ soundcard.h Sat Jul 26 15:46:26 1997 @@ -83,26 +83,7 @@ */ #ifndef _IOWR -/* @(#)ioctlp.h */ - -/* Ioctl's have the command encoded in the lower word, - * and the size of any in or out parameters in the upper - * word. The high 2 bits of the upper word are used - * to encode the in/out status of the parameter; for now - * we restrict parameters to at most 128 bytes. - */ -/* #define IOCTYPE (0xff<<8) */ -#define IOCPARM_MASK 0x7f /* parameters must be < 128 bytes */ -#define IOC_VOID 0x00000000 /* no parameters */ -#define IOC_OUT 0x20000000 /* copy out parameters */ -#define IOC_IN 0x40000000 /* copy in parameters */ -#define IOC_INOUT (IOC_IN|IOC_OUT) -/* the 0x20000000 is so we can distinguish new ioctl's from old */ -#define _IO(x,y) ((int)(IOC_VOID|(x<<8)|y)) -#define _IOR(x,y,t) ((int)(IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)) -#define _IOW(x,y,t) ((int)(IOC_IN|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)) -/* this should be _IORW, but stdio got there first */ -#define _IOWR(x,y,t) ((int)(IOC_INOUT|((sizeof(t)&IOCPARM_MASK)<<16)|(x<<8)|y)) +#include #endif /* !_IOWR */ #define SNDCTL_SEQ_RESET _IO ('Q', 0) --==_Exmh_20290887880-- From owner-freebsd-multimedia Sat Jul 26 12:57:45 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id MAA17007 for multimedia-outgoing; Sat, 26 Jul 1997 12:57:45 -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 MAA17002 for ; Sat, 26 Jul 1997 12:57:42 -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 MAA10752; Sat, 26 Jul 1997 12:57:42 -0700 (PDT) Message-Id: <199707261957.MAA10752@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Louis A. Mamakos" cc: multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-reply-to: Your message of "Sat, 26 Jul 1997 15:54:01 EDT." <199707261954.PAA00871@whizzo.TransSys.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 12:57:42 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Most cool!! Tnks a lot for the fix! Amancio >From The Desk Of "Louis A. Mamakos" : > This is a multipart MIME message. > > --==_Exmh_20290887880 > Content-Type: text/plain; charset=us-ascii > > Ok, I made my change to soundcard.h, and now /usr/sbin/mixer can be > rebuilt with guspnp11 and it works! Attached is the diff. > > I can see how this broke now; the mistaken value for IOC_OUT is > currently interpreted by the kernel as IOC_VOID, which would result > in nothing being copied out. > > louie > > > --==_Exmh_20290887880 > Content-Type: text/plain ; name="diff1"; charset=us-ascii > Content-Description: diff1 > Content-Disposition: attachment; filename="diff1" > > --- soundcard.h.orig Mon Jul 21 21:39:40 1997 > +++ soundcard.h Sat Jul 26 15:46:26 1997 > @@ -83,26 +83,7 @@ > */ > > #ifndef _IOWR > -/* @(#)ioctlp.h */ > - > -/* Ioctl's have the command encoded in the lower word, > - * and the size of any in or out parameters in the upper > - * word. The high 2 bits of the upper word are used > - * to encode the in/out status of the parameter; for now > - * we restrict parameters to at most 128 bytes. > - */ > -/* #define IOCTYPE (0xff<<8) */ > -#define IOCPARM_MASK 0x7f /* parameters must be < 128 byt es */ > -#define IOC_VOID 0x00000000 /* no parameters */ > -#define IOC_OUT 0x20000000 /* copy out parameters */ > -#define IOC_IN 0x40000000 /* copy in parameters */ > -#define IOC_INOUT (IOC_IN|IOC_OUT) > -/* the 0x20000000 is so we can distinguish new ioctl's from old */ > -#define _IO(x,y) ((int)(IOC_VOID|(x<<8)|y)) > -#define _IOR(x,y,t) ((int)(IOC_OUT|((sizeof(t)&IOCPARM_MASK)<<16)|( x<<8)|y)) > -#define _IOW(x,y,t) ((int)(IOC_IN|((sizeof(t)&IOCPARM_MASK)<<16)|(x <<8)|y)) > -/* this should be _IORW, but stdio got there first */ > -#define _IOWR(x,y,t) ((int)(IOC_INOUT|((sizeof(t)&IOCPARM_MASK)<<16) |(x<<8)|y)) > +#include > #endif /* !_IOWR */ > > #define SNDCTL_SEQ_RESET _IO ('Q', 0) > > --==_Exmh_20290887880-- > > From owner-freebsd-multimedia Sat Jul 26 14:13:07 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA20597 for multimedia-outgoing; Sat, 26 Jul 1997 14:13:07 -0700 (PDT) Received: from u2.farm.idt.net (root@u2.farm.idt.net [169.132.8.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA20592 for ; Sat, 26 Jul 1997 14:13:04 -0700 (PDT) Received: from sequoia (ppp-34.ts-1.mlb.idt.net [169.132.71.34]) by u2.farm.idt.net (8.8.5/8.8.5) with SMTP id RAA00361; Sat, 26 Jul 1997 17:12:59 -0400 (EDT) Message-ID: <33DA685A.446B9B3D@idt.net> Date: Sat, 26 Jul 1997 17:12:58 -0400 From: "Gary T. Corcoran" X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: Anthony.Kimball@East.Sun.COM CC: multimedia@FreeBSD.ORG Subject: Re: Software MPEG-2 (Was: Posting prefix) References: <199707242045.PAA03915@compound.east.sun.com> <199707242113.OAA15573@rah.star-gate.com> <199707250502.IAA29406@silver.sms.fi> <199707250706.CAA03136@compound.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tony Kimball wrote: > Is the mpeg2 format documented online? I understand that conventional > wisdom requires hardware assist, but that just represents an > algorithmic challenge.... I heard Intel (first hand) say that a 233MHz MMX Pentium will *almost*, *but not quite* be fast enough for software MPEG-2 decode (they tried it). In other words, while it generally worked, for high complexity/high motion scenes, it hiccuped. So until most of us have 300+ MHz processors, we'll need to use hardware for MPEG-2 decoding. Of course, if you'd like to get a head start and start writing code for future processors, be my guest... ;-) Or maybe you can find a "trick" that Intel didn't think of... ??? Gary Corcoran From owner-freebsd-multimedia Sat Jul 26 14:41:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21636 for multimedia-outgoing; Sat, 26 Jul 1997 14:41: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 OAA21626 for ; Sat, 26 Jul 1997 14:41:03 -0700 (PDT) Received: from rah.star-gate.com (localhost.star-gate.com [127.0.0.1]) by rah.star-gate.com (8.8.5/8.8.5) with ESMTP id OAA11329; Sat, 26 Jul 1997 14:40:25 -0700 (PDT) Message-Id: <199707262140.OAA11329@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: "Gary T. Corcoran" cc: Anthony.Kimball@East.Sun.COM, multimedia@FreeBSD.ORG Subject: Re: Software MPEG-2 (Was: Posting prefix) In-reply-to: Your message of "Sat, 26 Jul 1997 17:12:58 EDT." <33DA685A.446B9B3D@idt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 14:40:25 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk I am afraid that just because Intel tried and failed does not mean that we can't do it. Too many open questions. Is the programmer or team competent? There is a huge difference between someone working 9 and 5 and a nearly obsessed programmer or hightly motivated programmer tackling the problem. Which platform where they using? Did they use directdraw ? (assuming that they used win95 or winnt) What resolution , color depth and bitrate where they using? The list goes on and on... At the very least is worth investing the possibility of decoding mpeg2. Amancio >From The Desk Of "Gary T. Corcoran" : > Tony Kimball wrote: > > > Is the mpeg2 format documented online? I understand that conventional > > wisdom requires hardware assist, but that just represents an > > algorithmic challenge.... > > I heard Intel (first hand) say that a 233MHz MMX Pentium will *almost*, > *but not quite* be fast enough for software MPEG-2 decode (they tried it). > In other words, while it generally worked, for high complexity/high motion > scenes, it hiccuped. So until most of us have 300+ MHz processors, we'll > need to use hardware for MPEG-2 decoding. > > Of course, if you'd like to get a head start and start writing code for > future processors, be my guest... ;-) > > Or maybe you can find a "trick" that Intel didn't think of... ??? > > Gary Corcoran From owner-freebsd-multimedia Sat Jul 26 14:41:06 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id OAA21645 for multimedia-outgoing; Sat, 26 Jul 1997 14:41:06 -0700 (PDT) Received: from silver.sms.fi (silver.sms.fi [194.111.122.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA21627 for ; Sat, 26 Jul 1997 14:41:03 -0700 (PDT) Received: (from pete@localhost) by silver.sms.fi (8.8.6/8.7.3) id AAA00828; Sun, 27 Jul 1997 00:40:57 +0300 (EEST) Date: Sun, 27 Jul 1997 00:40:57 +0300 (EEST) Message-Id: <199707262140.AAA00828@silver.sms.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Petri Helenius To: "Gary T. Corcoran" Cc: Anthony.Kimball@East.Sun.COM, multimedia@FreeBSD.ORG Subject: Re: Software MPEG-2 (Was: Posting prefix) In-Reply-To: <33DA685A.446B9B3D@idt.net> References: <199707242045.PAA03915@compound.east.sun.com> <199707242113.OAA15573@rah.star-gate.com> <199707250502.IAA29406@silver.sms.fi> <199707250706.CAA03136@compound.east.sun.com> <33DA685A.446B9B3D@idt.net> X-Mailer: VM 6.22 under 19.15p7 XEmacs Lucid Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Gary T. Corcoran writes: > Tony Kimball wrote: > > I heard Intel (first hand) say that a 233MHz MMX Pentium will *almost*, > *but not quite* be fast enough for software MPEG-2 decode (they tried it). > In other words, while it generally worked, for high complexity/high motion > scenes, it hiccuped. So until most of us have 300+ MHz processors, we'll > need to use hardware for MPEG-2 decoding. While I don't want to start a discussion about the benefits of general purpose processors I would say that at the current level of technology it's much cheaper to decode MPEG-2 and to some extent MPEG in hardware since the cost of general purpose processor to do that is at least fivefold to the chip doing the job at full rates. > > Of course, if you'd like to get a head start and start writing code for > future processors, be my guest... ;-) > > Or maybe you can find a "trick" that Intel didn't think of... ??? > Pete From owner-freebsd-multimedia Sat Jul 26 15:34:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id PAA23543 for multimedia-outgoing; Sat, 26 Jul 1997 15:34:42 -0700 (PDT) Received: from u2.farm.idt.net (root@u2.farm.idt.net [169.132.8.11]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA23536 for ; Sat, 26 Jul 1997 15:34:36 -0700 (PDT) Received: from sequoia (ppp-34.ts-1.mlb.idt.net [169.132.71.34]) by u2.farm.idt.net (8.8.5/8.8.5) with SMTP id SAA19256 for ; Sat, 26 Jul 1997 18:34:33 -0400 (EDT) Message-ID: <33DA7B77.794BDF32@idt.net> Date: Sat, 26 Jul 1997 18:34:31 -0400 From: "Gary T. Corcoran" X-Mailer: Mozilla 3.01 (X11; I; FreeBSD 2.2.1-RELEASE i386) MIME-Version: 1.0 To: multimedia@FreeBSD.ORG Subject: Re: Software MPEG-2 (Was: Posting prefix) References: <199707262140.OAA11329@rah.star-gate.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Amancio Hasty wrote: > > I am afraid that just because Intel tried and failed does not mean > that we can't do it. Too many open questions. Yes. > > Is the programmer or team competent? There is a huge difference > between someone working 9 and 5 and a nearly obsessed programmer > or hightly motivated programmer tackling the problem. Uh-huh... > Which platform where they using? > > Did they use directdraw ? (assuming that they used win95 or winnt) > > What resolution , color depth and bitrate where they using? > > The list goes on and on... Of course they did not provide those details... > > At the very least is worth investing the possibility of > decoding mpeg2. > Sure. I guess I was just trying to imply that for the immediate future, until some(many?) of us get new (future) faster machines (or motherboards), a driver for a hardware decoder board might be more useful... Gary From owner-freebsd-multimedia Sat Jul 26 20:07:10 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA14082 for multimedia-outgoing; Sat, 26 Jul 1997 20:07:10 -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 UAA14077 for ; Sat, 26 Jul 1997 20:07:08 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id EAA29100; Sun, 27 Jul 1997 04:06:27 +0200 From: Luigi Rizzo Message-Id: <199707270206.EAA29100@labinfo.iet.unipi.it> Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz To: hasty@rah.star-gate.com (Amancio Hasty) Date: Sun, 27 Jul 1997 04:06:26 +0200 (MET DST) Cc: louie@TransSys.COM, multimedia@FreeBSD.ORG In-Reply-To: <199707261957.MAA10752@rah.star-gate.com> from "Amancio Hasty" at Jul 26, 97 12:57:23 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Most cool!! > > Tnks a lot for the fix! I was looking at ioctl parameters just yesterday. I agree that the fix of changing the _IO.. macros is correct, but then don't we loose binary compatibility with linux apps ? Luigi > > Amancio > > >From The Desk Of "Louis A. Mamakos" : > > This is a multipart MIME message. > > > > --==_Exmh_20290887880 > > Content-Type: text/plain; charset=us-ascii > > > > Ok, I made my change to soundcard.h, and now /usr/sbin/mixer can be > > rebuilt with guspnp11 and it works! Attached is the diff. > > > > I can see how this broke now; the mistaken value for IOC_OUT is > > currently interpreted by the kernel as IOC_VOID, which would result > > in nothing being copied out. -----------------------------+-------------------------------------- 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 26 20:10:58 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA14260 for multimedia-outgoing; Sat, 26 Jul 1997 20:10:58 -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 UAA14255 for ; Sat, 26 Jul 1997 20:10:56 -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 UAA00349; Sat, 26 Jul 1997 20:10:14 -0700 (PDT) Message-Id: <199707270310.UAA00349@rah.star-gate.com> X-Mailer: exmh version 2.0gamma 1/27/96 To: Luigi Rizzo cc: louie@TransSys.COM, multimedia@FreeBSD.ORG Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz In-reply-to: Your message of "Sun, 27 Jul 1997 04:06:26 +0200." <199707270206.EAA29100@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 20:10:14 -0700 From: Amancio Hasty Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Tnks for the warning I will look into it 8) Amancio >From The Desk Of Luigi Rizzo : > > Most cool!! > > > > Tnks a lot for the fix! > > I was looking at ioctl parameters just yesterday. I agree that the fix > of changing the _IO.. macros is correct, but then don't we loose > binary compatibility with linux apps ? > > Luigi > > > > Amancio > > > > >From The Desk Of "Louis A. Mamakos" : > > > This is a multipart MIME message. > > > > > > --==_Exmh_20290887880 > > > Content-Type: text/plain; charset=us-ascii > > > > > > Ok, I made my change to soundcard.h, and now /usr/sbin/mixer can be > > > rebuilt with guspnp11 and it works! Attached is the diff. > > > > > > I can see how this broke now; the mistaken value for IOC_OUT is > > > currently interpreted by the kernel as IOC_VOID, which would result > > > in nothing being copied out. > > -----------------------------+-------------------------------------- > 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 26 20:14:13 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id UAA14335 for multimedia-outgoing; Sat, 26 Jul 1997 20:14:13 -0700 (PDT) Received: from whizzo.TransSys.COM (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id UAA14327 for ; Sat, 26 Jul 1997 20:14:02 -0700 (PDT) Received: from localhost.transsys.com (localhost.transsys.com [127.0.0.1]) by whizzo.TransSys.COM (8.8.6/8.7.3) with SMTP id XAA25560; Sat, 26 Jul 1997 23:13:40 -0400 (EDT) Message-Id: <199707270313.XAA25560@whizzo.TransSys.COM> X-Mailer: exmh version 2.0zeta 7/24/97 To: Luigi Rizzo cc: hasty@rah.star-gate.com (Amancio Hasty), multimedia@FreeBSD.ORG From: "Louis A. Mamakos" Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz References: <199707270206.EAA29100@labinfo.iet.unipi.it> In-reply-to: Your message of "Sun, 27 Jul 1997 04:06:26 +0200." <199707270206.EAA29100@labinfo.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 26 Jul 1997 23:13:39 -0400 Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Don't the linux ioctl()'s come in elsewhere and get mapped? I'm pretty sure the upper bits in the ioctl function code have to be "right" so that stuff makes it across the user/kernel barrier. Uh, yeah, I just found it. Ick. Look at /sys/i386/linux/linux_ioctl.c for the horrible truth. I think this can be made to work. louie From owner-freebsd-multimedia Sat Jul 26 21:24:30 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id VAA16374 for multimedia-outgoing; Sat, 26 Jul 1997 21:24:30 -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 VAA16369 for ; Sat, 26 Jul 1997 21:24:26 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id FAA29171; Sun, 27 Jul 1997 05:23:50 +0200 From: Luigi Rizzo Message-Id: <199707270323.FAA29171@labinfo.iet.unipi.it> Subject: Re: ftp://rah.star-gate.com/pub/guspnp12.tar.gz To: louie@TransSys.COM (Louis A. Mamakos) Date: Sun, 27 Jul 1997 05:23:50 +0200 (MET DST) Cc: hasty@rah.star-gate.com, multimedia@FreeBSD.ORG In-Reply-To: <199707270313.XAA25560@whizzo.TransSys.COM> from "Louis A. Mamakos" at Jul 26, 97 11:13:20 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Don't the linux ioctl()'s come in elsewhere and get mapped? I'm pretty > sure the upper bits in the ioctl function code have to be "right" so that > stuff makes it across the user/kernel barrier. > > Uh, yeah, I just found it. Ick. Look at /sys/i386/linux/linux_ioctl.c > for the horrible truth. I think this can be made to work. not bad. Luckily the switch in linux_ioctl can only have 65536 cases at most ... :} Cheers Luigi From owner-freebsd-multimedia Sat Jul 26 23:42:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id XAA19942 for multimedia-outgoing; Sat, 26 Jul 1997 23:42:52 -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 XAA19937 for ; Sat, 26 Jul 1997 23:42:46 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id HAA29299 for multimedia@freebsd.org; Sun, 27 Jul 1997 07:42:33 +0200 From: Luigi Rizzo Message-Id: <199707270542.HAA29299@labinfo.iet.unipi.it> Subject: snd970726.tgz (including docs!) To: multimedia@freebsd.org Date: Sun, 27 Jul 1997 07:42:33 +0200 (MET DST) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Yet another snap of my new sound code is available at http://www.iet.unipi.it/~luigi/snd970726.tgz no new code (almost) with respect to yesterday's version, but some significant changes: * the most important addition is a Latex file (sound/doc/sound.tex) which tries to document the architecture of the new driver. Since I have been writing it in a hurry, and the code is still evolving in some parts, some details are missing, but I think the document should give a good picture of the overall architecture. In any case, if you take the time to look at it and comment I would be very grateful (I can add a postscript file if necessary). * Another significant change is the deletion of some files and renaming of others, so you'll have to update "files.i386" to configure a kernel. * finally, I have tried to cleanup the format of the two (almost) working drivers, sb_dsp.c and ad1848.c, to make the code easier to follow and to fix rules for other contributors. The proposed format is documented in the latex file, as well as in sb_dsp.c If I have not broken anything in the process, this code worked for both read and write with /dev/audio in SB mode, and for write in ad1848 mode (tests done using a PnP board based on the CS4236). 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/ _____________________________|______________________________________