> "The OSS API requires any services (like data format conversion,
> routing, etc.) be implemented in the kernel."
This is perfectly true.
> Operations like data format conversions are no rocket science. They do
> require few extra CPU cycles but so what. The same number of CPU cycles
> will be spent even if the conversions are done in user space. The same
> is true with "routing". Routing/mixing is always based on some kernel
> level IPC mechanisms. In case of OSS these mechanisms are just hidden
> behind the kernel level audio API.
These are not arguments for putting the services in the kernel.
Davis' point was that the OSS API requires that _all_ services _must_
be in the kernel; it's not possible to add user-defined plugins without
going through some sort of loopback device.
> "It also encourages applications to do things that do not work well with
> other applications that are also trying to do some kind of audio task."
> Like what?
E.g., mmap(), which cannot be reasonably emulated; or mixer devices.
(The OSS v4 API is better in this regard, but developers cannot rely on
it as long as most implementations only offer v3.)
> "OSS applications are written such that they believe they completely
> control the hardware."
> This is complete BS.
Please watch your language. And your next sentence proves you false:
> Yes, there are many OSS applications that open /dev/mixer and
> peek/poke the global hardware level volume controls directly.
> However this is not the way how OSS is designed to be used.
Opening /dev/mixer and using it was the _only_ way how OSS was
designed to be used.
The /dev/something interface implies hardware control; even when
implementing 'virtual' devices, OSS has to use the same interface and
to pretend that it's a 'real' hardware device.
> OSS is perfectly adequate for needs of 99% of the audio programs.
> And I doubt ALSA is any better than OSS for the remaining 1% of
> applications (the laws of the nature are the same for both of them).
It's the OSS implementation that's lacking.
The percentage of programs that, for example,
* want to make use of the full capabilities of any modern device (like
USB, HD-Audio, Bluetooth, Xonar), or
* want to use MIDI, or
* want to work correctly with suspend/resume, or
* must work on embedded architectures,
is way more than 1%. As long as these deficiencies exist, OSS will not
even be considered a theoretical replacement for ALSA.
> They are also required to move to RT kernels because
> ALSA and its followers depend on real time response times.
Please don't publish misinformation. Real-time response times are only
needed for real-time tasks like low-latency signal processing or
synthesizers, and this applies to any implementation, i.e., to both OSS