From owner-freebsd-multimedia Thu Apr 6 21:38: 8 2000 Delivered-To: freebsd-multimedia@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 93C7537B62A for ; Thu, 6 Apr 2000 21:38:04 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (tanimura@localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.9.3+3.2W/3.7W-rina.r-0.1-11.01.2000) with ESMTP/IPv4 id NAA35206; Fri, 7 Apr 2000 13:37:56 +0900 (JST) Date: Fri, 07 Apr 2000 13:37:55 +0900 Message-ID: <14573.26147.701848.20799S@rina> From: Seigo Tanimura To: cracauer@cons.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, gandalf@vilnya.demon.co.uk, freebsd-multimedia@freebsd.org Subject: Re: newpcm secondary dma buffer - why? In-Reply-To: In your message of "Thu, 6 Apr 2000 15:45:27 +0200" <20000406154526.C25990@cons.org> References: <20000331220131.A95404@cons.org> <14568.17977.947700.90123Q@rina> <20000406154526.C25990@cons.org> User-Agent: Wanderlust/1.0.3 (Notorious) SEMI/1.13.4 (Terai) FLIM/1.12.7 (=?ISO-8859-4?Q?Y=FEzaki?=) MULE XEmacs/21.1 (patch 9) (Canyonlands) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-multimedia@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 6 Apr 2000 15:45:27 +0200, Martin Cracauer said: >> 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. Martin> I must misunderstand something. How does the 2nd buffer lower the Martin> interrupt rate? At interrupt time you transfer things to the card and Martin> you need a constant rate to keep a 4KB buffer filled, no matter Martin> whether the source is a second buffer or something else. Of course, Martin> the number of system calls (writes from the application) is lowered, Martin> but unless I'm mistaken, this is neglectable when compared to the Martin> interrupt hammering on an ISA card. I forgot to mention another point. Even if an interrupt rate is somewhat high, sound plays smoothly provided that a user process feeds new sound data in real time. The 2nd buffer gives us a quick solution to achieve realtime playback in general situation. New sound data to be played is in the kernel memory. This allows us to copy the data to the DMA buffer during interrupt. On the other hand, if the buffer size is too small, we might have to perform copyin to fetch new data. This is not our option because copyin might involve pagein and sleep. Although copyin in the user process seems to work, the process may not always get to grab a cpu before the buffer runs out of sound data. While the optimum solution would be to introduce support of a real time process to our kernel, this would be a far difficult task for me to do... (snip) Martin> - generally detracting us from implementing the same sementics that Martin> OSS/Linux sound drivers implement for the API. Martin> Remember that many sound-intensive applications on FreeBSD are either Martin> Linux binaries or just ported by Linux-persons. Martin> The semantics of the API aren't specified anywhere, so people develop Martin> by try-and-error on Linux and are done with it. That may sound bad, Martin> but wouldn't have to bother us since we are in a position to implement Martin> the exact semantics of Linux (since we get source for the Linux Martin> drivers and soundards are simple enough to copy the relevant Martin> mechanics). Unless we use the secondary buffer, that is. I agree that for ordinary sound cards. But what about the sound devices with no reference, like USB audio? I had a quick look at the uaudio driver of NetBSD, which did not support mmap. I wonder how the Linux guys are going to handle new audio devices. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-multimedia" in the body of the message