From owner-freebsd-hardware Sat Dec 12 15:57:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA12546 for freebsd-hardware-outgoing; Sat, 12 Dec 1998 15:57:03 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from dingo.cdrom.com (ppp-d9.dialup.hilink.com.au [203.2.144.19]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA12541 for ; Sat, 12 Dec 1998 15:56:59 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id PAA00626; Sat, 12 Dec 1998 15:54:14 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Message-Id: <199812122354.PAA00626@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: richard@pegasus.com (Richard Foulk) cc: freebsd-hardware@FreeBSD.ORG Subject: Re: sane sound cards? In-reply-to: Your message of "Fri, 11 Dec 1998 15:45:20 -1000." <199812120145.PAA10540@pegasus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 12 Dec 1998 15:54:12 -0800 From: Mike Smith Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > } > A larger on-card buffer would make the problem go away. > } > } Not really. You're DMA'ing data from the system to the card, so that will > } never get interrupted with load. > > 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. > > You can't DMA a megabyte buffer full of data to a card that doesn't have > any place to put it. You certainly don't have any idea how DMA works either it seems. 8) There's nothing fundamentally impossible with using DMA in that fashion; you put a FIFO on the card as the DMA destination, and pace the DMA operation to keep the FIFO full. The actual size of the DMA transfer is completely irrelevant. In practice, there are lots of restrictions imposed by the toylike DMA hardware in the PC that interfere. > 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. 64K of audio data is 16Ksamples (16bit stereo), or 372msec, about a third of a second. If the application has provided more data to the driver (a wise idea, when possible), there is no way that "another process" can "keep the CPU busy" (the driver will be invoked via interrupt from the soundcard, preempting any other process) and prevent handling of the DMA termination. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message