using (or not) blocking mode with OSS4
m.b.lankhorst at gmail.com
Mon Sep 26 14:11:22 CDT 2011
On 09/26/2011 02:57 PM, Joerg-Cyril.Hoehle at t-systems.com wrote:
> I've had a glance at the OSS4 mmdevapi logs attached to bug #28056.
> Among others, it appears that every renderer iteration takes way too
> much time. One possible explanation is that OSS write() takes a lot
> of time to return, presumably in an attempt to write more than what's
> possible without blocking.
> If you look at AudioRenderClient_ReleaseBuffer and oss_write_data,
> you'll see that it writes as much as it has, without querying
> GETOSPACE. So it can block.
> open() is called without O_NONBLOCK, so write() will block when given
> too much data.
> I don't know yet whether O_NONBLOCK should be used. It's not what the
> OSS people recommend. One can argue that NONBLOCK is superfluous when
> write is limited via GETOSPACE.
> What do you think about using (or not) blocking mode with OSS?
> W.r.t. ALSA, I'm considering keeping non-blocking mode but switch from
> a periodic timer to poll(ALSA_fd, period_timeout). Given a lot of
> data, poll would return after the timeout, but when underrun is close,
> this should allow to wake up closer to when data is actually needed.
ALSA needs nonblocking because you can never guarantee the pulse
plugin works correctly, or one of the other plugins. However for oss
it makes sense to query GETOSPACE, so just do that. Nonblocking shouldn't
be needed then.
More information about the wine-devel