Date: Fri, 11 Dec 1998 18:20:21 -1000 From: richard@pegasus.com (Richard Foulk) To: freebsd-hardware@FreeBSD.ORG Subject: Re: sane sound cards? Message-ID: <199812120420.SAA10884@pegasus.com> In-Reply-To: Kevin Day <toasty@home.dragondata.com> "Re: sane sound cards?" (Dec 11, 8:24pm)
next in thread | previous in thread | raw e-mail | index | archive | help
} > 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. } } At least in my design, you trigger an interrupt/timer/something to go off } just before the dma finishes, and in that handler you start up another } transfer. Buffering algorithms are everywhere. Choose one, I'm not picky. } I do arcade game programming. In past projects, i've done similar things on } funky processors as slow as 33Mhz, with no problem keeping things fed. I'd } usually set a timer to expire just before my dma was finished, that } triggered an interrupt, and my interrupt handler started the next dma. No } matter what was happening, i never missed a dma. Arcade games are real-time systems. Apples and oranges. I"ve built I/O cards and written drivers and this is a classic case where a little more buffer will make things work more reliably. Sort of like the older serial ports that had only one or two characters of buffer. At higher speeds under Unix they would occasionally lose characters. So the chip makers eventually added more buffer. What's taking the sound card guys so long? Is it because most of them are used for much less than 44.1KHz stereo? Richard 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?199812120420.SAA10884>