Date: Thu, 4 Sep 1997 06:28:31 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: reilly@zeta.org.au (Andrew Reilly) Cc: multimedia@FreeBSD.ORG Subject: Re: snd970903.tgz and pnp970903.tgz Message-ID: <199709040428.GAA09292@labinfo.iet.unipi.it> In-Reply-To: <199709032316.JAA02065@gurney.reilly.home> from "Andrew Reilly" at Sep 4, 97 09:16:35 am
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199709040428.GAA09292>