Date: Sat, 12 Dec 1998 01:08:38 -0500 From: "Christopher R. Bowman" <crb@ChrisBowman.com> To: richard@pegasus.com (Richard Foulk) Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: sane sound cards? Message-ID: <199812120617.BAA05746@quark.ChrisBowman.com> In-Reply-To: <199812120145.PAA10540@pegasus.com> References: <Kevin Day <toasty@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 03:45 PM 12/11/98 -1000, Richard Foulk wrote: >} > } >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. DMA systems like this often have a low-water mark. When the buffer drains to the low water mark, an interrupt is sent to the processor telling it that it is time to set up another DMA transfer so the buffer doesn't drain completely. So it seems that you are saying that the buffer runs out before the CPU has a chance to set up another DMA operation. This either happens because interrupt activity is high, and when the sound interrupt comes in their is already an interrupt being handled, or you are doing a lot of syscalls that lock out the sound driver code with an SPL level that prevents the sound interrupt from being serviced quickly enough. If you could increase the buffer length on the sound card you would be able to handle these problems better. But you probably can't. Instead why don't you see if you can do one of 2 things to the code. 1) see if the interrupt low-water mark can be increased. This will increase the number of sound interrupts, but give you more time to respond before the buffer runs dry. 2) see if the priority of the sound interrupt can be raised. This may slow down the other tasks in the system but hopefully the sound driver will be able to respond quicker since it may preempt other interrupts or won't be locked out by lower level SPL changes. -------- Christopher R. Bowman crb@ChrisBowman.com http://www.ChrisBowman.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812120617.BAA05746>