Date: Fri, 07 Apr 2000 13:37:55 +0900 From: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> 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? Message-ID: <14573.26147.701848.20799S@rina> In-Reply-To: In your message of "Thu, 6 Apr 2000 15:45:27 %2B0200" <20000406154526.C25990@cons.org> References: <20000331220131.A95404@cons.org> <14568.17977.947700.90123Q@rina> <20000406154526.C25990@cons.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 6 Apr 2000 15:45:27 +0200, Martin Cracauer <cracauer@cons.org> 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 <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?14573.26147.701848.20799S>