From owner-freebsd-hardware Sat Dec 12 03:10:21 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA11395 for freebsd-hardware-outgoing; Sat, 12 Dec 1998 03:10:21 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA11386 for ; Sat, 12 Dec 1998 03:10:13 -0800 (PST) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id MAA10686 for freebsd-hardware@FreeBSD.ORG; Sat, 12 Dec 1998 12:10:06 +0100 (CET) (envelope-from olli) Date: Sat, 12 Dec 1998 12:10:06 +0100 (CET) From: Oliver Fromme Message-Id: <199812121110.MAA10686@dorifer.heim3.tu-clausthal.de> To: freebsd-hardware@FreeBSD.ORG Subject: Re: sane sound cards? Newsgroups: list.freebsd-hardware Organization: Administration Heim 3 Reply-To: freebsd-hardware@FreeBSD.ORG MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Richard Foulk wrote in list.freebsd-hardware: > DMA helps make transfers faster and more efficient. But the time > between DMA transfers is completely indeterminate under most Unixes, > (Windows too.) The sound card driver uses two DMA buffers (each of them is 64 Kb, I think). When the soundcard has finished playing one of them, it begins playing the other one and notifies the driver (with an IRQ) that the first buffer has been played and now is available to be filled with new data. At CD quality (16 bit, 44.1 kHz, stereo), 64 Kb are roughly 0.4 seconds of audio playback. If your driver does not handle the IRQ and set up a new DMA transfer within 0.4 seconds, you have either a _serious_ hardware problem (IRQ conflict, broken DMA controller or something like that), or you software cannot keep up with delivering new audio data to the driver fast enough. In the first case (hardware problem), fix it. In the second case (software can't keep up), there are several possibilities. Assuming that you're decoding MPEG audio files ("mp3" or others), this takes a fair amount of CPU share. If your computer has to do other tasks that require significant amount of CPU power, the MPEG decoder might not get enough CPU time to deliver audio data to the soundcard driver in realtime. If those other tasks appear in peaks (e.g. starting large applications), a buffer within the MPEG decoder will help. For example, mpg123 has an option for this (-b) which causes it to fork a child process which handles the buffering (the child process will virtually always get enough CPU time from FreeBSD's scheduler because it doesn't need much CPU time for itself). If those other tasks are running for a long time (e.g. make world, raytracer etc.), you should renice those tasks or put them into an idle scheduling class (see "man idprio"). Or, alternatively, give the MPEG decoder a negative nice value or put it into a realtime scheduling class ("man rtprio"), although FreeBSD's scheduler is clever enough so that this should not be necessary. Bottom line: A buffer memory on the soundcard does NOT provide any significant advantage. Period. > Perhaps I wasn't clear. My system can play them just fine too. But > not if I do a fair amount of other work at the same time. I'm convinced > that a lack of sufficient buffering on the sound card is the only thing > standing in my way. ... or sufficient buffering in software. Try it. > I don't think you understand how DMA works. Since the transfer is > limited to the buffer on the card it can only transfer tiny bits of data > at a time. That's incorrect. The DMA transfer can run in 64 Kb chunks, even if the soundcard does not use that much on-board memory for buffering. The DMA is used to feed the data directly from main memory into the soundcard's DAC. (Well, almost directly, there's usually a small FIFO in between, because the DAC clock and the DMA clock run asynchronously.) Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message