Hannu’s Blog

While OSS/Free was originally an open source implementation derived from OSSv3 there is one major difference. OSS/Free (and ALSA’s OSS emulation) implemented open() on an audio device so that the open call will wait (by default) until the device becomes free. This was stupid since an application (such as a game) will wait infinitely if some other application is keeping the device open. As a counter measure _ALL_ OSS applications used the O_NDELAY/O_NONBLOCK flag in open() to disable this feature. This was unfortunate since O_NDELAY/O_NONBLOCK also enabled non-blocking reads and writes. OSSv3 didn’t support this POSIX feature so the application developers didn’t notice the problem. They should have disabled non-blocking mode after opening the audio device or to handle the properly partial reads/writes caused by non-blocking mode.

This application level workaround for a bad driver feature causes serious problems with OSSv4 (and also older OSSv3.x versions). When non-blocking I/O is enabled it’s possible that a read/write call doesn’t return/consume all the data requested by the application. Instead a non-blocking write will transfer only the amount of data that fits in the buffer. If the buffer is completely filled then an error (EWOULDBLOCK) will be returned. The application should have code to check for partial writes (the same is true for partial reads).

Now we are in a situation where the OSS plugins don’t work at all with OSSv4. They use a woraround for a design mistake in older OSS/Free and ALSA versions (this problem has been fixed years ago). However they turn on a feature they cannot handle. During playback only a fraction of the data they write to the audio device will get actually played. Majority of the data will get dropped on floor which makes the output signal seriously garbled.

The current situation is major pain in my ass. All OSS applications use non-blocking I/O as a workaround to design flaws in somebody else’s drivers. Then they don’t support the feature properly as defined by POSIX. The result is that only the applications developed by 4Front Technologies work properly with OSSv4. At the same time application developers are against OSS and don’t want to listen any advices because OSSv4 is broken. It must be proken because their fine applications work flawlessly under OSS/Free and ALSA’s OSS emulation that don’t support the proper POSIX behavior.