Date: Tue, 29 Jul 1997 13:58:01 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: hasty@rah.star-gate.com (Amancio Hasty) Cc: gozer@ludd.luth.se, freebsd-multimedia@FreeBSD.ORG Subject: Re: guspnp12b Message-ID: <199707291158.NAA01805@labinfo.iet.unipi.it> In-Reply-To: <199707290721.AAA02594@rah.star-gate.com> from "Amancio Hasty" at Jul 29, 97 00:20:51 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Tnks, > > I will try to fix the last dma bug . It has to deal with=20 > changing the size of the last dma request. Typically, with=20 > auto dma the sound card cycles thru the dma buffer at fixed > step sizes and when the last output block of a sound stream > is sent out it is usually not the same step size;hence,=20 > the driver gets into trouble well at least with the sb16 cards. > > Will try to fix it however if it looks too hard that is just the=20 > way that is going to be given that Luigi is revamping the dma > algorithm , I rather fix for good on his version. I think this problem is related to the use of auto-DMA. Here is another one: take a board with a large on-board buffer, filled up using dma; do a first write whose size is shorter than the ISA dma buffer size. The first write will not fill up completely the ISA dma buffer, but will start the dma transfer in auto mode. The board reads bytes quite fast, since it has a buffer (something similar happens to me with the CS4236 and its 32-bytes FIFO). When the desired number of bytes has been transferred, you get an interrupt, but the dma transfer is not suspended (that's the point auto mode). The board tries to read more data, and fetches the previous content of the buffer, although there is no need for the data right now. This would not happen if normal dma was used. This is not to say that the problem cannot be solved, just that it is tricky to get it right, and one has to know a little bit about the board to know which DMA mode is better to use. Luigi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707291158.NAA01805>