FreeBSD OSS + Alsa - what's the right behaviour for non-blocking IO?

Adrian Chadd adrian at
Tue Mar 12 22:31:14 UTC 2013


I've been hacking on some Alsa code on Linux which uses poll() and
non-blocking IO to schedule audio.

When I run that code on FreeBSD, it chews 100% of CPU.

Now, the mechanics are pretty clear:

* the /dev/dsp.X FD always returns POLLOUT;
* when I then call alsalib to fetch the number of samples available to
write into the playback buffer, I get 0
* this happens for quite a while until it finally returns non-zero.

Digging into it (ie, snd.verbose=4 and looking at the sound setup
routines) I discovered that the watermark was being set to the
playback buffer size (32768 frames in my case, so 131072 bytes) and no
subsequent adjustment was done.

The oss plugin for alsa-lib calls SNDCTL_DSP_LOW_WATER

So I'll go and tinker with the ALSA setup side in order to see what
the story is (it's almost certain I'm setting things up incorrectly
for non-blocking IO here and I need to to wave the right magic wand to
get the low watermark reset right.

However, there's definitely a behavioural difference here - FreeBSD
shouldn't be returning POLLOUT on the dsp device, only to find that
there's no space in the playback FIFO.

Any ideas?



More information about the freebsd-multimedia mailing list