Date: Tue, 12 Mar 2013 15:31:13 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-multimedia@freebsd.org Subject: FreeBSD OSS + Alsa - what's the right behaviour for non-blocking IO? Message-ID: <CAJ-Vmomf3GW0M_8b-W59dSh1rSn5ypHZN_eKQEpJVKJaeA_9ww@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Hi, 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? Thanks, Adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmomf3GW0M_8b-W59dSh1rSn5ypHZN_eKQEpJVKJaeA_9ww>