From owner-freebsd-multimedia Wed Sep 3 22:40:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id WAA07084 for multimedia-outgoing; Wed, 3 Sep 1997 22:40:29 -0700 (PDT) Received: from labinfo.iet.unipi.it (labinfo.iet.unipi.it [131.114.9.5]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id WAA07077 for ; Wed, 3 Sep 1997 22:40:20 -0700 (PDT) Received: from localhost (luigi@localhost) by labinfo.iet.unipi.it (8.6.5/8.6.5) id GAA09292; Thu, 4 Sep 1997 06:28:31 +0200 From: Luigi Rizzo Message-Id: <199709040428.GAA09292@labinfo.iet.unipi.it> Subject: Re: snd970903.tgz and pnp970903.tgz To: reilly@zeta.org.au (Andrew Reilly) Date: Thu, 4 Sep 1997 06:28:31 +0200 (MET DST) Cc: multimedia@FreeBSD.ORG In-Reply-To: <199709032316.JAA02065@gurney.reilly.home> from "Andrew Reilly" at Sep 4, 97 09:16:35 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-freebsd-multimedia@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > I haven't bought a sound card yet because I want to be sure that I can > do full-duplex, full bandwidth (48kHz preferably, 44.1kHz is OK) signal > processing. All I've heard about the SB16 (and by extension the SB32, > AWE32, and AWE64) says that the closest it comes to full-duplex is 16 > bits out/8 bits in. Is that the case? forget the SB16, or ESS-based cards. The idea of a split architecture with 16bit in one direction and 8bit in the other one is crazy. I strongly recommend CS4236-based cards, which works very well in full duplex. The data sheets on the Crystal site are very good. The CS4237 should work as well, although I cannot find this card in the stores and cannot test it myself. Finally, the CS4232 is reported as broken in the OSS/Voxware documentation. The one I have (on an Intel Zappa motherboard) seems in fact unable to use the second DMA channel, but I am not sure if it is the motherboard or the 4232. Also the CS4232 has a non-conforming PnP behaviour (my PnP code does not have a problem with that, though). The OPTI931, if it really worked, would be another cheap and good alternative. But 1) the chip is severely buggy in full duplex, and 2) the data sheets are very coincise and miss important details. They may fix it in the future, but both silicon rev. 0.1 and rev.1.0 seems to have the same bugs. > Are there any inexpensive sound cards with good AD/DA quality that can > do full duplex 16-bit? Speaking of AD/DA quality I cannot say much in terms of S/N ratios etc, since I have not done any test. What I can say is that again Crystal provides detailed notes on board layout etc to make the analog part less noisy etc. > In any case, do you have an idea of the minimum latency you could get > with a program that just did un-buffered reads and writes to the audio > device? Are we talking about <= 20ms? My driver basically tracks the status of a DMA transfer so if you do non-blocking reads you get the bytes as soon as the DMA has transferred them. The granularity is 4 bytes so your latency is 500us (mono,8KHz) or less. Of course when your process is descheduled... Also note that at the moment my driver does not use DMA AUTO mode, so at high loads or high sampling rates it might occasionally miss samples. This should not be a big problem with the CS42xx which has a decent-sized FIFO. And I plan to add AUTO mode in the future. > (I'm a DSP guy, and I would very much like to be able to prototype > algorithms on my workstation, before I have to cut them into DSP code.) this was one of the planned uses of my code, this is why you can do multiple opens of the audio device on full duplex cards: your_filter_program < /dev/audio > /dev/audio works fine :) Cheers Luigi > > -- > Andrew > > "The steady state of disks is full." > -- Ken Thompson > >