Date: Wed, 23 Jul 1997 22:07:32 -0400 From: Randall Hopper <rhh@ct.picker.com> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: freebsd-multimedia@FreeBSD.ORG Subject: Re: dma handling in the sound driver Message-ID: <19970723220732.54270@ct.picker.com> In-Reply-To: <19970720204439.26980@pobox.com>; from Brian Campbell on Sun, Jul 20, 1997 at 08:44:39PM -0400 References: <19970720010235.26253@pobox.com> <199707200711.JAA19743@labinfo.iet.unipi.it> <19970720204439.26980@pobox.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Few days late on jumping in on this thread but here's my 2 cents.
I'm also all-for simplification if we don't sacrifice anything. The
two main issues on my mind WRT the proposed change are:
- Response Time
- Compatibility (Linux and FreeBSD apps)
Response Time:
To the first, if with the proposed mods, a read() of N bytes of data
from /dev/dsp always takes the same or less amount of time as in the
current drivers doing a "SETFRAGMENT N" and read()ing N bytes, and ditto
for write(), I'm sold on this point. So e.g. for reads, the size of the
request would need to be completely decoupled from internal buffering sizes
in terms of "filling one up" before data could be returned so small read
requests of N bytes could always be services very quickly if at least N
bytes were available.
Having recently had to use SETFRAGMENT myself to solve delay problems
recording interleaved audio and video to disk for Fxtv, I know it's very
useful with the current drivers to have this control. With a default
buffer size of 32K for the sbxvi driver, the reads take __WAY__ too long to
keep a multitasking event loop spinning. But with 1K buffers, it works
very well. I've noticed that mtv (Linux MPEG system stream player) sets 1K
buffers as well for the same reason during interleaved audio and video
playback (checking with GETOSPACE to see when a buffer frees up).
Compatibility:
To the second point, Linux compatibility is pretty important, and
avoiding having to report FreeBSD stuff is a plus as well. Of course, the
ioctls that tie into this are SETFRAGMENT, GETISPACE, and GETOSPACE,
allowing the client to set the internal buffer size and request a number of
buffers, as well as fetch back the driver's adjusted buffer size and
determine free buffer counts before doing reads and writes.
Without maintaining a client-settable "buffer size", I guess
GETISPACE and GETOSPACE could be dummied up to satisfy the coded
assumptions of existing Linux and FreeBSD/Linux sound clients. Hmmm.
Guess the sound driver could keep track of the requested FRAGMENT size, and
then return the amount of free buffers and buffer size using this
originally-requested buffer size, virtualizing the whole thing.
Anyway, the compatibility aspect sounds doable. If the response time
is a sure-thing as well, it sound like a good change to me!
Randall
Brian Campbell:
|Similarly for recording. Sometimes you'll want to use a low number
|of small buffers for sampling -- say for some sort of recognition
|function, or frequency analyzer. You want to get hold of the
|samples as soon as possible and if your processing time on those
|samples means the recording "stalls" and you miss a buffer or three
|then you just want to continue with what's happening "now".
...
|The point being that you probably can't chose a "best" number or
|size of DMA buffers. You probably also can't solve all latency
|problems (unless there's a gross one that exists that I'm unaware
|of) for all uses.
Luigi Rizzo:
|> On Sat, Jul 19, 1997 at 04:37:50PM +0200, Luigi Rizzo wrote:
|> > I have planned to rewrite the dma buffer handling routines for
|> > the sound driver as follows.
|>
|> There is a mechanism for setting the size and number of DMA buffers,
|> is there not? Will this be removed, or the settings simply ignored?
|
|i forgot to say that all current ioctls will remain valid (for
|backward compatibility reasons). If they are really useful, they
|will have the same effect. If they become useless (e.g. in the case
|of SNDCTL_DSP_SETFRAGMENT, because the new implementation implicitly
|solves the problem), they might become a nop, or they will just
|maintain a fake state variable.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970723220732.54270>