Date: Wed, 22 Nov 2000 14:22:48 +1030 (CST) From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Dag-Erling Smorgrav <des@ofug.org> Cc: cg@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Julian Elischer <julian@FreeBSD.org>, Maxim Sobolev <sobomax@FreeBSD.org> Subject: Re: cvs commit: src/sys/dev/sound/pci maestro.c Message-ID: <XFMail.001122142248.doconnor@gsoft.com.au> In-Reply-To: <xzpsnolf9uk.fsf@flood.ping.uio.no>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21-Nov-00 Dag-Erling Smorgrav wrote: > > a way for the app to discover current state of that buffer, so > > usually apps have nothing to do but to keep this buffer filled all > > the time, hoping that it's small enough to mask this delay. > Plus, this applies to *all* sound drivers, not just maestro. Can we > have this backed out? Also, wouldn't the Right Way be to compute the buffer size based on the data rate and the amount of time you can afford.. eg specify the buffer size in milliseconds rather than bytes.. More work to do I know, but it would provide a hard limit on the latency in all cases rather than having to tune the buffering based on what you are playing. (of course it gets more complex with multiple audio streams :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.001122142248.doconnor>