using (or not) blocking mode with OSS4

Joerg-Cyril.Hoehle at Joerg-Cyril.Hoehle at
Mon Sep 26 07:57:51 CDT 2011


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.

	Jörg Höhle

More information about the wine-devel mailing list