Linux is not ready for Steam

[darkphoenix22]

Edit: Most programs and libraries are a setting away from using OSSv4 directly, *without* the ALSA compatibility layer.

Damn edit limit.

[ZedDB]

Isn't it more like:
App->OpenAL->OSSv4 ?
Or if you use ALSA:
App->OpenAL->ALSA
And with PulseAudio:
App->OpenAL->PulseAudio->ALSA

[pingufunkybeat]

Or OSS4 -> OpenAL, no?

Sure, if such a move is actually justified.

On the plus side, it could bring the unified sound architecture back to the free Unix systems.

On the downside, it doesn't seem to be ready, or significantly better than ALSA, and the people behind it already tried to hijack it and hold the Unix crowd ransom.

So, while I'd be open to switch to OSSv4 in principle based on technical merits alone if it turns out to be the better technical solution, I would think about it 10 times first, given the political history surrounding it. If it's not a necessary switch, screw it.

[energyman]

Rather a choice.

OSSv4 needs to be pushed into the mainstream Linux distributions so it can be tested and fixed.

OSSv4 devs should stop working on it and help with ALSA. Same for the ossv4 fanbois who troll around everywhere.

[darkphoenix22]

So, while I'd be open to switch to OSSv4 in principle based on technical merits alone if it turns out to be the better technical solution, I would think about it 10 times first, given the political history surrounding it. If it's not a necessary switch, screw it.

I'm only advocating a full switch when it is ready, unlike the PulseAudio devs who wish for their beta quality software to be pushed on anyone.

The problem with ALSA isn't that it doesn't work. It is whether it will work in the future and whether it will meet the needs and wants of devs and users. Users want per-application volume controls and devs want a simple audio API that will make their life easy, rather than having to deal with 15 different wrappers. Abstraction is not a solution to ALSA's problems. As you can see with PulseAudio, abstraction only exacerbates ALSA's flaws, namely it's complexity, while addding even more problems like high-latency. ALSA is an adequate solution presently but I don't think that will hold, even in the near future.

It comes down to this. ALSA can not be easily expanded. OSSv4 likely can.

[darkphoenix22]

On the downside, it doesn't seem to be ready, or significantly better than ALSA, and the people behind it already tried to hijack it and hold the Unix crowd ransom.

If that happened, the solution would be a fork. OSSv4 is now licensed under the GPL so a fork would always be possible. We just need to keep 4Front on their toes about putting all of their work under the GPL (in addition to any other licenses) if they wish for OSSv4 to be adopted.

[energyman]

you can control the volume in wesnoth independent from the volume in vlc. The app people just have to put it in. OSS is not needed for that.

I wished pulseaudio would die a quick death. The average user does not gain anything by this trainwreck.

[energyman]

It comes down to this. ALSA can not be easily expanded. OSSv4 likely can.

are you paid for this lying?

[darkphoenix22]

you can control the volume in wesnoth independent from the volume in vlc. The app people just have to put it in. OSS is not needed for that.

I wished pulseaudio would die a quick death. The average user does not gain anything by this trainwreck.

Well, in the short term, PulseAudio does need to be abandoned as it has never achieved its original goals and likely never will.

But its functionality needs to be replaced somehow. This would not be possible with ALSA unless we made another wrapper, which would have many of the same unavoidable problems as PulseAudio.

The problem isn't that ALSA doesn't work. The problem is ALSA is too damn complicated to be usefully expanded while keeping ABI stability.

[darkphoenix22]

are you paid for this lying?

I just want a long term solution to the Linux audio problems and API/ABI complexity, which we aren't going to get by sticking with ALSA.