Date: Mon, 1 Sep 1997 08:25:45 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: multimedia@FreeBSD.ORG Subject: Re: OPTi931 problems... Message-ID: <199709010625.IAA04641@labinfo.iet.unipi.it> In-Reply-To: <199708312131.OAA01585@rah.star-gate.com> from "Amancio Hasty" at Aug 31, 97 02:30:55 pm
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. I do that. I loop on the status register until I find it to be zero, acking and serving requests as I see them. But I am sure that the chip is broken and the most likely reason is described below. I'll be able to prove that when i implement auto mode (which I would have already done if I had not wasted so much time debugging this chip:( ). > If you can't get it working in full duplex mode just disable its > full duplex capability till a work around is found . at the moment I just check the isa dma count register to check if I missed one interrupt, and serve it in case. This has its own problems: since I can only check at the next interrupt on the other channel, there are hiccups in the output (the one which most often loses samples due to the access pattern in "vat") because the interrupt is served later than it should be. Also, it might well be that both channels have the same problem, and in this case I am in a deadlock. But I have a workaround in mind, again it will be implemented for auto mode (it requires it). > On a different note, how is your CS4236 doing? very well! as a matter of fact, if someone wants to have a short talk using vat just drop me an email and let me know the parameters. > > - 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?199709010625.IAA04641>