[SDL] Re: dspaudio & FreeBSD - huge delay [testcase]

Maxim Sobolev sobomax at altavista.net
Sun Apr 2 14:00:39 PDT 2000


Mattias Engdegеrd wrote:

> > In fact there is two buffers in the driver - one
> >frontend, which behaves accordingly to theh OSS specs, and one (usually
> >large) backend, which is used to actually transfer data into card. And what
> >makes this situation even worse, is that all ioctl's expected to return
> >current state of audio buffers in fact returns only state of the front
> >buffer, which in the most cases is empty, as the driver tend to transfer data
> >into its back end buffer ASAP.
>
> If there is no way to resize or get status information of the backend buffer,
> then you are stuck. You can use it for playing music, but nothing latency-
> critical. It sounds brain dead to me.

Yeh, you are absolutely right. Hovewer I've submitted small patch to make
SNDCTL_DSP_GETOSPACE ioctl return the maximum free buffer space available in
either of buffers. So, this would allow application to query driver about amount
of data currently in the buffers and to behave accordingly.

More general approach would require to make driver part of the select() call to
actually consider difficulties of this two-buffer organisation.

> >I've notified FreeBSD developers about my findings and will try to persuage
> >them to fix audio driver for better conformance with OSS specs.
>
> Is OSS the native audio API of FreeBSD, or is it just a compatibility layer?
> If so, there could be a way to handle it. Do the BSD developers have the
> ambition to use other APIs in the future (ALSA, OpenAL)? The OSS/SunOS
> concept where an app talks directly to a device isn't a very flexible design.

Yes, OSS is the native audio API on FreeBSD and it is still some sort of "work in
progress" after recent transition from the old Voxware API. As for you second
question I couldn't tell you much about it, maybe if one of these standards will
gain significant application support then someone will try to port it to the BSD.

-Maxim




More information about the SDL mailing list