Date: Thu, 6 Apr 2000 15:45:27 +0200 From: Martin Cracauer <cracauer@cons.org> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: cracauer@cons.org, gandalf@vilnya.demon.co.uk, freebsd-multimedia@freebsd.org Subject: Re: newpcm secondary dma buffer - why? Message-ID: <20000406154526.C25990@cons.org> In-Reply-To: <14568.17977.947700.90123Q@rina>; from tanimura@r.dl.itc.u-tokyo.ac.jp on Mon, Apr 03, 2000 at 04:20:25PM %2B0900 References: <20000331220131.A95404@cons.org> <14568.17977.947700.90123Q@rina>
next in thread | previous in thread | raw e-mail | index | archive | help
In <14568.17977.947700.90123Q@rina>, Seigo Tanimura wrote: > 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. I must misunderstand something. How does the 2nd buffer lower the interrupt rate? At interrupt time you transfer things to the card and you need a constant rate to keep a 4KB buffer filled, no matter whether the source is a second buffer or something else. Of course, the number of system calls (writes from the application) is lowered, but unless I'm mistaken, this is neglectable when compared to the interrupt hammering on an ISA card. > 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. So the goal is to have as much code in common for all sounddrivers, including DMA-cable and not DMA-capable? Good point, but I doubt that the gain is very big and that it might not be worth the effort when looking at the disadvantages: - effectivly making mmap() support impossible - damaging all precise timing schemes applications might use - making the drivers for plain soundcards less maintainable - generally detracting us from implementing the same sementics that OSS/Linux sound drivers implement for the API. Remember that many sound-intensive applications on FreeBSD are either Linux binaries or just ported by Linux-persons. The semantics of the API aren't specified anywhere, so people develop by try-and-error on Linux and are done with it. That may sound bad, but wouldn't have to bother us since we are in a position to implement the exact semantics of Linux (since we get source for the Linux drivers and soundards are simple enough to copy the relevant mechanics). Unless we use the secondary buffer, that is. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer <cracauer@cons.org> http://www.cons.org/cracauer/ Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536 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?20000406154526.C25990>