Date: Sun, 31 Aug 1997 14:31:14 -0700 From: Amancio Hasty <hasty@rah.star-gate.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: multimedia@FreeBSD.ORG Subject: Re: OPTi931 problems... Message-ID: <199708312131.OAA01585@rah.star-gate.com> In-Reply-To: Your message of "Sun, 31 Aug 1997 13:38:05 %2B0200." <199708311138.NAA03985@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, Thinking a little about your problem when you get an interupt from the chip can you check if the interrupt status bits are set for both the read and write channel. If you can't get it working in full duplex mode just disable its full duplex capability till a work around is found . Also, I would check out the card in Win95 with the manufacturers latest drivers to see if indeed the card works in full-duplex mode. I have no idea how to do that in win95 short of writing a program however I seem to recollect that there are programs floating around in the net which will help you to verify the full duplex mode. On a different note, how is your CS4236 doing? Cheers, Amancio >From The Desk Of Luigi Rizzo : > 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?199708312131.OAA01585>