Date: Sun, 31 Aug 1997 13:38:05 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: multimedia@freebsd.org Subject: OPTi931 problems... Message-ID: <199708311138.NAA03985@labinfo.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
As I said some times, the OPTI931 appears to be a bit buggy. Thus far I have found the following problems: - full duplex operation in companded modes (ULAW/ALAW) does not work on the capture channel (playback works fine). The chip appears to produce stereo, 16-bit samples but with a broken count. I haven't tried to ask a different format (say, U8) on the playback channel and ULAW on the capture and see if it works. My driver has a software fix, i.e. when requested ULAW puts the chip in U8 mode and do the conversion in software. However this makes you reduce your dynamic range from 12-13 bits to 8 bits only. I havent done the conversion between S16 and ULAW in the driver because it is much easier to do it in the application. - in full duplex operation, not using auto mode, the chip appears to occasionally lose interrupts on one channel when the other channel generates an interrupt. After much trials and investigations, I am almost convinced that the problem lies in the 931 not decrementing its internal counters in some circumstances, despite the DMA request is issued. As a result, the counter in the 8237 (ISA DMA controller) goes to 0 earlier than the one in the 931, and your transfer blocks forever if you do not use auto mode. These events are very frequent if reads and writes are synchronized, e.g in vic I get one such event every 5..10 full DMA transfers, meaning that the 931 loses 5-10 samples per second. Note that, if what I suspect is true, this is a very bad bug since it also affects transfers using auto mode. In auto mode you don't realize the problem immediately, but the loss creates a drift between the actual and the expected status of buffers (your DMA read-write location keeps moving ahead of what you believe). Reading the actual count of the DMA channel via isa_dmastatus() appears to be the only thing which can (partly) fix the problem. I say partly because nobody knows what happens in the 931 with the phantom transfer, if it is reissued immediately, or after one sample time, or who knows when. For sure, this behaviour completely breaks the assumption that read and write sample speeds are the same (many audioconferencing tools use this principle...). 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/ _____________________________|______________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708311138.NAA03985>