Date: Mon, 17 Sep 2001 00:32:05 +0400 From: Maxim Sobolev <sobomax@mail.ru> To: orion@FreeBSD.ORG Cc: multimedia@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: " Making DMA buffer resizeable depending on audio speed/format " Message-ID: <E15iiaB-0003kl-00@mx7.port.ru> In-Reply-To: <200109161859.f8GIxrN52078@mule.aciri.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 16 Sep 2001 11:59:53 -0700, Orion Hodson wrote: > > 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. 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. > 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. 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. :(( > 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. See above. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E15iiaB-0003kl-00>