Date: Sat, 12 Dec 1998 12:10:06 +0100 (CET) From: Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> To: freebsd-hardware@FreeBSD.ORG Subject: Re: sane sound cards? Message-ID: <199812121110.MAA10686@dorifer.heim3.tu-clausthal.de>
next in thread | raw e-mail | index | archive | help
Richard Foulk wrote in list.freebsd-hardware:
> DMA helps make transfers faster and more efficient. But the time
> between DMA transfers is completely indeterminate under most Unixes,
> (Windows too.)
The sound card driver uses two DMA buffers (each of them is
64 Kb, I think). When the soundcard has finished playing one
of them, it begins playing the other one and notifies the
driver (with an IRQ) that the first buffer has been played and
now is available to be filled with new data.
At CD quality (16 bit, 44.1 kHz, stereo), 64 Kb are roughly
0.4 seconds of audio playback. If your driver does not handle
the IRQ and set up a new DMA transfer within 0.4 seconds, you
have either a _serious_ hardware problem (IRQ conflict, broken
DMA controller or something like that), or you software cannot
keep up with delivering new audio data to the driver fast
enough.
In the first case (hardware problem), fix it.
In the second case (software can't keep up), there are several
possibilities. Assuming that you're decoding MPEG audio files
("mp3" or others), this takes a fair amount of CPU share. If
your computer has to do other tasks that require significant
amount of CPU power, the MPEG decoder might not get enough CPU
time to deliver audio data to the soundcard driver in realtime.
If those other tasks appear in peaks (e.g. starting large
applications), a buffer within the MPEG decoder will help.
For example, mpg123 has an option for this (-b) which causes it
to fork a child process which handles the buffering (the child
process will virtually always get enough CPU time from
FreeBSD's scheduler because it doesn't need much CPU time for
itself).
If those other tasks are running for a long time (e.g. make
world, raytracer etc.), you should renice those tasks or put
them into an idle scheduling class (see "man idprio").
Or, alternatively, give the MPEG decoder a negative nice value
or put it into a realtime scheduling class ("man rtprio"),
although FreeBSD's scheduler is clever enough so that this
should not be necessary.
Bottom line: A buffer memory on the soundcard does NOT provide
any significant advantage. Period.
> 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.
... or sufficient buffering in software. Try it.
> 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.
That's incorrect. The DMA transfer can run in 64 Kb chunks,
even if the soundcard does not use that much on-board memory
for buffering. The DMA is used to feed the data directly from
main memory into the soundcard's DAC. (Well, almost directly,
there's usually a small FIFO in between, because the DAC clock
and the DMA clock run asynchronously.)
Regards
Oliver
--
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de)
"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
(Terry Pratchett)
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?199812121110.MAA10686>