Date: Mon, 03 Apr 2000 16:20:25 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> To: cracauer@cons.org Cc: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Subject: Re: newpcm secondary dma buffer - why? Message-ID: <14568.17977.947700.90123Q@rina> In-Reply-To: In your message of "Fri, 31 Mar 2000 22:01:32 %2B0200" <20000331220131.A95404@cons.org> References: <20000331220131.A95404@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 31 Mar 2000 22:01:32 +0200, Martin Cracauer <cracauer@cons.org> said: Martin> could you explain why the newpcm driver uses a secondary buffer to Martin> collect data before it transmits it to the soundcard? (snip) Martin> Please don't say "it does buffering", I assume that :-) But so far Martin> I've been under the impression that such things are unneeded in Martin> today's soundcards and that it is extremly hard to get the mmap API to Martin> work with such a construction in between. First, even in these days certain sound cards have very small size of DMA buffer. My CS4614 sound card has only 4KB, interrupting on playing/recording every 2KB. For CD quality sound(44.1kHz 16bit stereo), the interrupt rate goes up to 86.1 times/sec and likely to unferflow under heavy load. Second, we would eventually have to get rid of DMA dependency in pcm driver. This is essential for pcm devices without DMA, including USB, PCCARD and pc98(nss) sound. For these devices, the driver needs to transfer sound data by block-by-block manner. -- Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@FreeBSD.org> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14568.17977.947700.90123Q>