From owner-freebsd-hardware Fri Dec 11 17:45:53 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA27639 for freebsd-hardware-outgoing; Fri, 11 Dec 1998 17:45:53 -0800 (PST) (envelope-from owner-freebsd-hardware@FreeBSD.ORG) Received: from pegasus.com ([209.84.70.244]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA27632 for ; Fri, 11 Dec 1998 17:45:50 -0800 (PST) (envelope-from richard@pegasus.com) Received: by pegasus.com (8.6.8/PEGASUS-2.2) id PAA10540; Fri, 11 Dec 1998 15:45:20 -1000 Date: Fri, 11 Dec 1998 15:45:20 -1000 From: richard@pegasus.com (Richard Foulk) Message-Id: <199812120145.PAA10540@pegasus.com> In-Reply-To: Kevin Day "Re: sane sound cards?" (Dec 11, 12:29pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: freebsd-hardware@FreeBSD.ORG Subject: Re: sane sound cards? Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org } > } >All of the cards I've checked into appear to fail because there is no data } > } >buffer on the card. At least not large enough to handle 44.1kHz stereo. } > } >My guess is that somewhere between 16K and 64K bytes of buffer should be } > } >sufficient. } > } } > } Buffering is done with primary memory. Card only needs about 4K buffer. } > } } > } > What do you mean by primary memory? If it ain't on the card it's not } > what I want. If it's not on the sound card a slow device elsewhere on } > the system will be able to starve the sound card. } } Most, if not all sound cards use DMA to pull sound out of the system ram and } stream it in. You control the size of the buffer in software that you want } to keep loaded off of the disk, and in an interrupt handler (that can't } really get too lagged) you give it the next dma command and start loading } the next block. DMA helps make transfers faster and more efficient. But the time between DMA transfers is completely indeterminate under most Unixes, (Windows too.) Sound production is a realtime process. External (to the OS) buffering is the best way to try to connect a realtime I/O process to non-realtime operating systems. } If you're getting skipping/missing, it's because your system can't keep up } or there are driver problems. } } I have an original Soundblaster 1.0 (giant ISA card) that has a 64 byte } buffer, but can DMA. I'm able to play mp3's on it with ease. } } Look for IRQ conflicts, or try a different audio driver if possible. 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. (I may end up building a system to dedicate to playing mp3s. But that really shouldn't be necessary.) } > 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. 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. Richard To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message