> > 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
