Date: Thu, 24 Jul 1997 15:38:55 +0200 (MET DST) From: Luigi Rizzo <luigi@labinfo.iet.unipi.it> To: brianc@milkyway.com (Brian Campbell) Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver Message-ID: <199707241338.PAA26145@labinfo.iet.unipi.it> In-Reply-To: <19970724092558.31924@milkyway.com> from "Brian Campbell" at Jul 24, 97 09:25:39 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > |Thanks for the detailed list. > > | > > |I am looking at the DSP_SETFRAGMENT thing, and while I have no problem > > |to implement it with the required features, it sounds quite odd that > > |the application requires many small buffers. If they are small it means > > |the app wants low latency, so why ask for many ? > > > > Small buffers gets it low latency on write()s. Many buffers minimizes the > > chance that the driver will have played everything by the time that it gets > > around to feeding it again. > > In addition, many small buffers allow applications do occasional large > write()s and not have to worry about waiting for several buffers to > empty before the write() can return. Well my point was that that way of requesting buffers is vstrictly related to the particular implementation. I believe the correct request should be 'I want X bytes of total buffering, and be guaranteed that the chunk size is at most Y bytes'. Of course I can assume X = Y*n_buffers. As a matter of fact, I believe that the small buffer size is really important on reads, not on writes, since the chunk size (Y) determines how long an already scheduled dma operation will take, and this is only critical for a read. If you do a short write, either there is no pending data, and you can start a dma op with the correct size, or there is a pending dma transfer, and you have no other choice of queueing the data and waiting. In the read case, a short read with no pending dma transfer can request the exact number of bytes, but a if a dma read has already been started, you are stuck with whatever size was requested before, unless you can poll the status of a dma transfer (which we can now :> ) and invoke tsleep() to wait for data to arrive. BTW the new driver is progressing fast. Yesterday I could hear my PnP CS4236 play audio using SB emulation, and as soon as I get a few spare hours for testing other modes should be ready. 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?199707241338.PAA26145>