From owner-freebsd-current Sun Sep 16 12: 0: 4 2001 Delivered-To: freebsd-current@freebsd.org Received: from mule.aciri.org (mule.aciri.org [192.150.187.28]) by hub.freebsd.org (Postfix) with ESMTP id EFC3C37B401; Sun, 16 Sep 2001 11:59:53 -0700 (PDT) Received: from mule.aciri.org (localhost [127.0.0.1]) by mule.aciri.org (8.11.3/8.11.1) with ESMTP id f8GIxrN52078; Sun, 16 Sep 2001 11:59:53 -0700 (PDT) (envelope-from hodson@mule.aciri.org) Message-Id: <200109161859.f8GIxrN52078@mule.aciri.org> X-Mailer: exmh version 2.1.1 10/15/1999 To: sobomax@FreeBSD.org Cc: multimedia@FreeBSD.org, current@FreeBSD.org Reply-To: orion@FreeBSD.org In-reply-to: Your message of Sat, 15 Sep 2001 11:41:16 +0400 Subject: Re: " Making DMA buffer resizeable depending on audio speed/format " Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 16 Sep 2001 11:59:53 -0700 From: Orion Hodson 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 Maxim 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. I suspect (not insist :-) the two specific fixes you report are caused by: - mss maximum buffer size is too small (4096 bytes ~ 23 ms of CD quality audio). Your patch helps because you increase the default buffering to 16384 bytes. - digger relies on a sound library that does not always set the blocksize (there are paths in the SDL audio code where this is the case, eg esd). Your patch helps because it sets the default buffer size smaller. Increasing the default buffering is certainly an option we should consider. However, any application that wants low latency should talk to the sound device directly and use the existing ioctls to get this. AFAIK, these work very well, mail sound@freebsd.org if there are specific examples where this is not the case. Kind Regards - Orion In message ,Maxim Sobolev writes: > This is a multi-part message in MIME format. > > --192.168.1.100.0.526.1000539647.245.19907 > Content-Type: text/plain > > Hi there, > > I want to get your comments on the attached patch, which makes sound > driver resizing its DMA buffer according to the currently selected > audio speed/format. This is necessary because most audio hardware > supports wide range of speeds/formats, which makes it hard to define > one buffer size that will satisfy all supported formats and providing > minimal latency for the formats with low datarates, while good skip > protection for formats with high datarates. For example 4096 bytes used > now in most drivers doesn't protect data playing on 44kHz from skipping > when there is some kernel activity going on (for example output on > console or switching between consoles), while at the same time this > size means 0.5s latency for games that use 8kHz/8 bit audio formats, > which is a quite noticeable delay. > > Attached patch fixes some maximal buffer size, which is necessary > for proper registering with the DMA subsystem, while scales this > buffer down when format with lower datarate is selected. I'm running > this patch for a month on my -current system with OPL3-SA hardware > and so far it works like a charm - mpg123 no longer skips when I'm > scrolling in the editor running on console, while audio delay in > digger (22kHz, 8 bit, mono) is absolutely unnoticeable. > > This patch only improves mss driver, but it should be relatively > easy to modify other drivers as well (I do not have a hardware to > test changes on). > > Thank you in advance! > > -Maxim > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message