Re: " Making DMA buffer resizeable depending on audio speed/format "
> > 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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: " Making DMA buffer resizeable depending on audio speed/format "
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 [EMAIL PROTECTED] if there are specific examples where this is > not the case. See above. -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: " Making DMA buffer resizeable depending on audio speed/format "
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 [EMAIL PROTECTED] if there are specific examples where this is not the case. Kind Regards - Orion In message <[EMAIL PROTECTED]>,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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
