Date: Sun, 20 Jul 1997 20:44:39 -0400 From: Brian Campbell <brianc@pobox.com> To: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver Message-ID: <19970720204439.26980@pobox.com> In-Reply-To: <199707200711.JAA19743@labinfo.iet.unipi.it>; from Luigi Rizzo on Sun, Jul 20, 1997 at 09:11:51AM %2B0200 References: <19970720010235.26253@pobox.com> <199707200711.JAA19743@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jul 20, 1997 at 09:11:51AM +0200, Luigi Rizzo wrote: > > On Sat, Jul 19, 1997 at 04:37:50PM +0200, Luigi Rizzo wrote: > > Is the current mechanism insufficient? I thought changes were only > > requried for full-duplex operation. > > the main problem I have is that I find the dma code quite complex to > follow and understand (as all code which has been evolving for a long > time and adapting to new boards etc.). The scheme I have described is, > in my opinion, simpler and more effective with respect to latency. > > Plus I'll document it ! Simplification is a good goal. Documentation even even better. But I wasn't aware there were visible [audible? ;-] latency problems. > > There is a mechanism for setting the size and number of DMA buffers, > > is there not? Will this be removed, or the settings simply ignored? > > i forgot to say that all current ioctls will remain valid (for > backward compatibility reasons). If they are really useful, they > will have the same effect. If they become useless (e.g. in the case > of SNDCTL_DSP_SETFRAGMENT, because the new implementation implicitly > solves the problem), they might become a nop, or they will just > maintain a fake state variable. Not to suggest you shouldn't go off in your own direction, but I don't think SETFRAGMENT is useless. Sometimes you'll want to feed the dsp in little bits, sometimes you'll have lots to feed all at once then several CPU intensive seconds before you provide more -- suggesting the use of a large buffer. Similarly for recording. Sometimes you'll want to use a low number of small buffers for sampling -- say for some sort of recognition function, or frequency analyzer. You want to get hold of the samples as soon as possible and if your processing time on those samples means the recording "stalls" and you miss a buffer or three then you just want to continue with what's happening "now". In other circumstances you may want a few large buffers to make sure nothing gets lost and there are no "clicks". The point being that you probably can't chose a "best" number or size of DMA buffers. You probably also can't solve all latency problems (unless there's a gross one that exists that I'm unaware of) for all uses. P.S. What's going on with linux and free audio drivers these days? Are they still running 3.5 or have things d?evolved?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970720204439.26980>