Quote Originally Posted by allquixotic View Post
1. Unless he wants to only support integer sample formats, this will never be allowed in the kernel, because Linus doesn't allow floating point in the kernel. I guess he'd have to resample any inbound floating point audio from programs in userspace before passing it to the kernel. But since the proposal is for directly accessing a character device, that sounds impossible. Good luck with that.
That is fine. This is in no way Linux-specific.

Quote Originally Posted by allquixotic View Post
2. The OSS API? Seriously? It's not even an API; it's just a character based interface. That's not very portable, you know. Even ALSA is more portable than that (you could in principle implement libasound2 backend on Windows and compile it and it should work). Also, OSS is a terrible API from the 90s that has no concept of modern ideas like power savings. The problem is that a "character device" is a concept unique to *NIX operating systems, so any OS that doesn't implement that concept is kinda screwed. A "C" API is pretty much a universal concept; all but 1 or 2 exotic OSes support that. So you can't talk about portability while saying "forget all OSes that don't derive their core design from UNIX".
You can also write a library to simulate character devices on Windows. As far as I know, ALSA is Linux-specific while OSS is available on a wide variety of platforms. Portability-wise OSS is better. Are you volunteering to address that?

Quote Originally Posted by allquixotic View Post
3. We don't need another solution. Period. We have too many already. It's way past the point where introducing new solutions is even remotely plausible. All this can possibly do is bring further fragmentation and brokenness to the Linux desktop, and add more headaches for application developers trying to support every system. Hopefully it does not gain any traction whatsoever.
The same could have been said when ALSA and PulseAudio were made.

Quote Originally Posted by allquixotic View Post
4. Using the justification of being "annoyed" at PulseAudio is not a reason for starting a completely new project. Instead, improve on the things about PulseAudio that annoy you. Although I can't imagine what; I haven't even thought about sound infrastructure on my system for more than a year. I start up apps and they play sound. I don't see what there is to be annoyed about. Everything "just works" with no glitches/dropouts/etc, exactly like it was promised when PA started back in '06 / '07.
It is a perfect reason.

Quote Originally Posted by allquixotic View Post
5. It'll take you a decade to develop all the hardware support needed to be even competitive with OSS4, let alone ALSA. Audio drivers can't ever be pure and simple; they necessarily have to come with tons of ASIC-specific hacks and workarounds, because hardware manufacturers like to add little tweaks to break your driver, like changing pinouts, etc. It's part of the territory. It takes a ridiculous amount of manpower to develop and maintain all those workarounds. One person isn't going to cut it. All the traction is already with ALSA. All the success is already with ALSA.
ALSA is an API. if sound drivers require it, then they are poorly designed.

Quote Originally Posted by allquixotic View Post
This thing is just stupid. It's like going on a 500 mile trip in the car, traveling 498 miles to your destination, then say "oh $@(# I meant to take a train, not a car, this sucks", then drive all the way back home and get on a train to go there again. What a terrible waste of manpower.
The only stupid thing here are the people that try to tell others how to spend their time.

Quote Originally Posted by allquixotic View Post
Contribute to ALSA or PulseAudio (or both) instead, ya dolt!
The same could have been said for OSS when those were in development. Where were you then?