From owner-freebsd-hardware Mon Dec 14 03:05:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id DAA10324 for freebsd-hardware-outgoing; Mon, 14 Dec 1998 03:05:28 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from smtp1.xs4all.nl (smtp1.xs4all.nl [194.109.6.51]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id DAA10308 for ; Mon, 14 Dec 1998 03:05:23 -0800 (PST) (envelope-from schofiel@xs4all.nl) Received: from xs1.xs4all.nl (root@xs1.xs4all.nl [194.109.6.42]) by smtp1.xs4all.nl (8.8.8/8.8.8) with ESMTP id MAA05753 for ; Mon, 14 Dec 1998 12:05:18 +0100 (CET) Received: from excelsior (enterprise.xs4all.nl [194.109.14.215]) by xs1.xs4all.nl (8.8.8/8.8.6) with SMTP id MAA00796 for ; Mon, 14 Dec 1998 12:05:16 +0100 (MET) Message-ID: <3674FEF2.732C@xs4all.nl> Date: Mon, 14 Dec 1998 12:05:06 +0000 From: Rob Schofield Reply-To: schofiel@xs4all.nl Organization: Knights of the Round Table Ltd. X-Mailer: Mozilla 3.04Gold (WinNT; I) MIME-Version: 1.0 To: Free BSD Hardware list Subject: Re: sane sound cards? References: <199812120145.PAA10540@pegasus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Richard Foulk wrote: > You can't DMA a megabyte buffer full of data to a card that doesn't have > any place to put it. So a five minute song is going to take roughly > 100,000 separate DMA transfers. That's 100,000 chances for another > process to keep the CPU busy long enough for the sound card to run out > of data. 64 bytes is only a few milliseconds of play time. Unacceptable. You are, or course, perfectly correct here in what you say, but your problem is basically that the market the card designers of these cards are aiming at are primarily single-thread, single user (win/mac). It is only a recent "innovation" that they have moved from ISA bus designs (in 1998!! My Grief!!) to PCI; they are unlikely to make the even greater step of sophistication of process-locked on board buffering for a decent OS. The closest idea I can think of even similar to what you want is the "Speed Variation Buffer" RAM buffer in the second and third generation CD-players produced by Philips years ago where the symbol delivery rate from the disk reader could vary with the rotational speed of the disk (which may have tilted, counter rotated, etc.). This effectively became a FIFO that was clocked out at a controlled rate by the supervising processor for the D/A stages, effectively soaking up the speed variation in the mechanics. I doubt you'll see this on a sound cad, because it costs money; the designers realise that it is cheaper to use off-board RAM that has already been paid for by someone else, and use the OS to provide the "buffer" in software. Low budget, for a low-budget market. This does tend to imply that there would be a good professional market for a company prepared to ivest in a design with a large on-board buffer RAM for the sound data stream, rather than just for symbol tables. Hmmm.... now if I dig out my 'scope and dust off my logic analyser maybe I can ..... Rob Schofield -- The Ninety-Ninety Rule of Project Scheduling: The first ninety percent of the job takes ninety percent of the allotted time, the last ten percent takes the other ninety percent. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message