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

Maxim Sobolev sobomax at altavista.net
Sun Apr 2 08:29:42 PDT 2000


Mattias Engdegеrd wrote:

> >Yes, it refuses to use provided parameters. I've just digged into
> >kernel sources and found that actually buffer for each driver is
> >specified by using #define, and size of it remains constant from
> >reboot to reboot. I've also found confirmation of my assumptions -
> >buffer for my specific driver was set to 64KB. I'm using
> >OSS-compatable (well, partially in fact) FreeBSD's pcm driver.
>
> Ah. Well, that sucks. Can you check if ioctl(SNDCTL_DSP_GETOSPACE) works?
> If it does, we can use the same trick as on Solaris (which also has a
> big non-adjustable buffer): sleep a while, then check if the buffer
> is running low. If so, feed it. Repeat.

Sounds reasonably, but unfortunately situation even more complicated than
I've written previously. 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. At the same time select() call deals with
backend buffer, so it will not block untill the whole backend buffer will be
filled with data.

Therefore audio application cannot get from the FreeBSD sound driver current
position of the playback and even cannot get from operating system
notification when buffer is getting reasonably empty (I do not think that
buffer with 64KB of data could be considered as an empty one).

I've notified FreeBSD developers about my findings and will try to persuage
them to fix audio driver for better conformance with OSS specs.

-Maxim




More information about the SDL mailing list