From owner-freebsd-current Sun Sep 16 14: 0:27 2001 Delivered-To: freebsd-current@freebsd.org Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by hub.freebsd.org (Postfix) with ESMTP id 5ED6437B40B; Sun, 16 Sep 2001 14:00:18 -0700 (PDT) Received: from vilnya.demon.co.uk ([158.152.19.238]) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 15ij1U-000Oba-0A; Sun, 16 Sep 2001 21:00:17 +0000 Received: from haveblue (haveblue.rings [10.2.4.5]) by vilnya.demon.co.uk (Postfix) with SMTP id D336C32622; Sun, 16 Sep 2001 21:58:58 +0100 (BST) Message-ID: <012801c13ef2$5d759800$0504020a@haveblue> From: "Cameron Grant" To: , Cc: , References: Subject: Re: " Making DMA buffer resizeable depending on audio speed/format " Date: Sun, 16 Sep 2001 21:58:41 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > The sound driver interface provides the application writer the choice to set > > the buffering they require. This patch has obvious implications for the > > ordering of ioctl's that we may not want to introduce. > > Yes, OSS interface allows for that, but currently FreeBSD doesn't fully > provide applications with means to control buffering, because it only > allows application to regulate front buffer size and state, while retains > back buffer (i.e. DMA buffer) out of application's control, thus > significantly lowering its ability to control audio latency. we set the hardware buffer to the smaller of the application requested size and the maximum size supported by the hardware driver. > Not actually. If our pcm driver was correctly reporting its internal state > then SDL would be able to cope with situation intelligently (it has the code to > do so), but as long as now pcm driver doesn't reports to the application state > of its DMA buffers the application has no ways to regulate buffering > intelligently. You may want to look for my previous messages on topic (more > than a year ago on multimedia@ list). I reduced this problem by downsizing > a mss buffer size from the 64KB (sic!) to 4KB now, but this creates another > problem with the high speed audio. :(( have you tested this in the last 6 months? note that mss.c does not fully implement setblocksize. some drivers do not attempt to implement it at all, but the majority implement it correctly. -cg To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message