From owner-cvs-all Tue Nov 21 19:54:21 2000 Delivered-To: cvs-all@freebsd.org Received: from cain.gsoft.com.au (genesi.lnk.telstra.net [139.130.136.161]) by hub.freebsd.org (Postfix) with ESMTP id 2990A37B4D7; Tue, 21 Nov 2000 19:54:11 -0800 (PST) Received: from cain.gsoft.com.au (doconnor@cain [203.38.152.97]) by cain.gsoft.com.au (8.8.8/8.8.8) with ESMTP id OAA29167; Wed, 22 Nov 2000 14:22:48 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Wed, 22 Nov 2000 14:22:48 +1030 (CST) From: "Daniel O'Connor" To: Dag-Erling Smorgrav Subject: Re: cvs commit: src/sys/dev/sound/pci maestro.c Cc: cg@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Julian Elischer , Maxim Sobolev Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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