Linux is not ready for Steam

[Svartalf]

Which is not going to happen without PA.

Please explain why not. If you can't, perhaps you shouldn't be making such remarks.

Yeah. What is so wrong with running a daemon?

Latency. Just because it's "low" doesn't mean it's lower than without the abstraction layer (and therefore indirection) brought about by the daemon. It's there and it's got to be compensated for in a game. If you bring something to the table that's useful, then yeah, it might be "okay".

If ALSA's broken and "needs" this- shouldn't you be fixing it instead of slapping a band-aid on the problem, hm?

[mugginz]

Once again, I'm not in favour of immediately removing ALSA in favour of OSSv4. I'm only in favour of pushing it into the repos of distros so it can be developed further.

The simple provision of an yet another sound solution when not a mandatory requirement still risks more fragmentation. If we want stuff to work without continual reconfiguration it'd be nice if there weren't a thousand different ways to implement sound play-back on a Linux work station. When PulseAudio first hit the distros I wasn't exactly in favour of the breakage that occurred but I did like the feature set it was to bring.

I do believe Pulse needs to be removed immediately because it does break games and it does break programs.

And what do we do with those people who depend on the features provided by PulseAudio? It actually does work well for some people. Again, ALSA was no panacea either. There was still borkage in various ways with it. If Pulse goes we in no way get rolled back to some perfect state.

Recoding everything to be tolerate of a wrapper is not an option. Removing the wrapper and integrating its functionality into the core sound API is the only way to go.

Well if ALSA is made feature complete with respect to PulseAudio and is reliable, compatible with the rest of the ecosystem and completely robust then I'd be astonished if you could find much wrong with doing it on a purely technical level. When, (if ever), ALSA is in that state then you might have a good argument.

If this can be done with ALSA, sure let's stick with ALSA. But I'm not sure if it can.

I still think it's better to try and prefect the trajectory we're on right now. Constant switching back and forth different approaches is wasteful of human resources.

[mugginz]

AND it does inject latencies in the mix that aren't there with the lowe level stuff. Seriously. You're adding a dispatch layer on TOP of everything else to support per-application level mixing of sounds and network redirection. It's going to add latency in there that isn't there with the raw, low-level stuff.

But surely it has to be done somewhere? If not in user space than in the kernel.

If there's code to perform soft mixing, etc then it needs be be nicely implemented in a performant way, but it has to be implemented.

Redirection of audio over a network isn't a biggy for a lot of people but PA's other features can be.

[mugginz]

We're looking at approximately 12+ years (yes...) of trying to get it right and missing the mark on sound here.

Pretty embarrassing for the Linux desktop, that's for sure. Not to mention frustrating for users of that desktop.

Three differing failed attempts (including OSS, when you get to brass tacks here...) to get it right on Sound.

And now people are calling for yet another change in tack.

At least with 3D, you've largely had the same API interfaces for things, back from when Utah-GLX was the thing, all the way to now. With sound, you've had this hodge-podge of things that offer sort of OSS interfaces, sort of ALSA interfaces, etc.

Hopefully they can perfect those interfaces.

[Svartalf]

[*]Remove PulseAudio and revert back to ALSA the way it is now. Doing this we loose various benefits of PulseAudio and create a less good, not better experience for some.

For SOME. Keeping in mind, so far, nobody's given good, useful benefits for PulseAudio that is useful for most or all. They keep saying we need it because ALSA is broken. If ALSA is BROKEN shouldn't you be FIXING IT instead of slapping yet another layer on top of an already complex system? Slapping it on top of a broken piece only leads to complex situations where things break down. If things were solid and you were advocating providing a simpler interface to ALSA, I might not even chime in on this conversation. However, this isn't what we're talking about here- and adding an abstraction layer on top of a broken, complex system will NOT resolve the problems underneath.

[*]First, fix ALSA, test it thoroughly, make sure it's feature complete and compatible with everything, then replace PulseAudio with it.

Shouldn't we be doing this in the FIRST place? If it's not feature complete or not capable of doing it's original stated goals (which were what was sold to everyone to get them to move to it in the first place...) going nearly 10 years back, shouldn't we be re-thinking things here instead of slapping band-aids on it?

[*]Add any missing functionality to OSS4, test it thoroughly, make sure it's feature complete and compatible with everything, then replace PulseAudio with it.

If and only if, OSSv5 brings something useful to the table, including stability for things, would I advocate that.

What, the removal of PA? It brought new functionality that is desirable and required. If we get rolled back to native ALSA then we loose that and are still left with sound system that's not compatible with all software.

What new functionality that is over what is already there or is supposed to be there? To the best of my recollection, the only real feature that is new and differing is network redirection- which is only useful to select users. Please, delineate just what's special here with PulseAudio that something else like JACK or nothing at all (Remember ALSA was sold to be providing much of what PulseAudio claims
to bring to the table here...)

Remember, in the ALSA only days there was still software having conniptions when playing back audio. This "feature" is not a PulseAudio exclusive by any means.

Heh... Perhaps not, but it should be a sign that perhaps there's something wrong with ALSA. Putting PA in the mix won't resolve those conniptions for every case and will actually make things worse in some instances. Remember, adding a wrapper around a broken framework will NOT fix the problems with the framework, only hide them at best.

[mugginz]

It's almost been done with ALSA, so I'm not wholly sure WHY we needed PulseAudio to begin with- unless the DMix stuff's hopelessly broken for whatever reason (which implies a re-work of that, and not doing yet another layer on top of things...).

I agree it's better to fix rather then continually re-start solutions to the point we never get a finished solution. Now that we're where we are with Pulse I hope they finish that solution off and not jump ship yet again.

[Svartalf]

Pretty embarrassing for the Linux desktop, that's for sure. Not to mention frustrating for users of that desktop.

Not to mention frustrating to the developers writing software for it.

And it's not yet resolved- PA doesn't really do it either, sadly enough. It mostly works, but then ALSA kind of fit that role as well for some time now. It's an improvement over ESD, but that's not saying a lot. It's better than ARTS, again not saying much when you get to brass tacks.

When you keep having to re-work things like this, there should be a hint in that...

And now people are calling for yet another change in tack.

If you can't get it working right, you need to either fix what you've got or replace it with something that will. Slapping abstraction layers on top of broken, complex systems will only hide issues at best- and that's what PA advocates are asking for first and foremost when they insist upon this being the fix for the "sound problem".

If nothing else, we NEED to fix ALSA or replace it before talking about things like PulseAudio, JACK, etc.- because wrappers will not fix the problems in the framework, only hide them. ESD and Arts should've taught us that much if nothing else.

[mugginz]

For SOME. Keeping in mind, so far, nobody's given good, useful benefits for PulseAudio that is useful for most or all. They keep saying we need it because ALSA is broken. If ALSA is BROKEN shouldn't you be FIXING IT instead of slapping yet another layer on top of an already complex system? Slapping it on top of a broken piece only leads to complex situations where things break down. If things were solid and you were advocating providing a simpler interface to ALSA, I might not even chime in on this conversation. However, this isn't what we're talking about here- and adding an abstraction layer on top of a broken, complex system will NOT resolve the problems underneath.

But if ALSA isn't in a state that we want to go back to either then it's a wash. We need to perfect one of the approaches. If the ALSA guys want to provide a more compelling alternative to Pulse then there's a benefit there. I'm not seeing their attempts to supersede Pulse but maybe I'm not looking in the right places.

[*]First, fix ALSA, test it thoroughly, make sure it's feature complete and compatible with everything, then replace PulseAudio with it.

Shouldn't we be doing this in the FIRST place? If it's not feature complete or not capable of doing it's original stated goals (which were what was sold to everyone to get them to move to it in the first place...) going nearly 10 years back, shouldn't we be re-thinking things here instead of slapping band-aids on it?

What ever solution is provided, it has to be compatible with the rest of the current ecosystem. If someone releases a complete, reliable and easy to use solution then I'm sure we'll all be up for moving to it but that's not what some a re arguing for. They're say just scrap Pulse and with that seem to be suggesting that if only we would just use native ALSA then all our problems would go away. I think they're mistaken.

[*]Add any missing functionality to OSS4, test it thoroughly, make sure it's feature complete and compatible with everything, then replace PulseAudio with it.

If and only if, OSSv5 brings something useful to the table, including stability for things, would I advocate that.

Same here.

What, the removal of PA? It brought new functionality that is desirable and required. If we get rolled back to native ALSA then we loose that and are still left with sound system that's not compatible with all software.

What new functionality that is over what is already there or is supposed to be there? To the best of my recollection, the only real feature that is new and differing is network redirection- which is only useful to select users. Please, delineate just what's special here with PulseAudio that something else like JACK or nothing at all (Remember ALSA was sold to be providing much of what PulseAudio claims
to bring to the table here...)

Well the per app volume from a central control is benificial and useful.
Working bluetooth integration. If someone wants to say it worked before Pulse then their version of worked is defferent to mine.
Also, on the whole I find the current state of Pulse to be better and more reliable generally than what we had with straight ALSA.

Remember, in the ALSA only days there was still software having conniptions when playing back audio. This "feature" is not a PulseAudio exclusive by any means.

Heh... Perhaps not, but it should be a sign that perhaps there's something wrong with ALSA. Putting PA in the mix won't resolve those conniptions for every case and will actually make things worse in some instances. Remember, adding a wrapper around a broken framework will NOT fix the problems with the framework, only hide them at best.

But who's coming forward with a proven alternative?

If we jump ship to the OSS4 solution then what about drivers and such?

[drag]

Please explain why not. If you can't, perhaps you shouldn't be making such remarks.

Because:

Hardware devices do NOT have standard and sane mixing interfaces.

The way that they switch between outputs, the types of mixers, the ramp-up/ramp-down of the mixers, loudness levels, and all sorts of different things. All these things very between all sorts of different devices.

For example... enabling digital audio out on my laptop, Audiophile 24/96. and my Audigy audio card are all dramatically different. I am actually completely unable to correctly configure the Audiophile device through the alsamixer interface... it does not really make any sense at all.

And you have the same problems with input, also. Having 400 different ways to configure your Microphone, each of which is specific to a driver and hardware, is NOT 'sane'.

If you want it to be 'sane' your going to have to create a standard mixer interface that gets exposed to users and applications.

Your going to need a system that is going to be able to configure the hardware on it's own and match up the standard/sane interfaces that users/applications interact with with the hardware/driver mixer interfaces.

Also, beyond that, your going to need a way to support different audio devices _ON_THE_FLY_ as hardware configurations are far from static nowadays.

Yes you could write a system that was not PA that can do this... but you'd just be writing another daemon.

If you want that in a kernel then you'd just be shoving the same amount of complexity into the kernel. When designing a system not having stuff like this going in the kernel is a good idea...

When PA crashes all that happens is that applications lose sound for a bit until it starts up. Bad applications might get goofed up a bit. If the same thing happens in your kernel then your system will crash hard and you'll have to deal with additional problems like likely data corruption.

Avoiding using a sound server for configuring your hardware and creating standard/sane mixing interfaces is not going to streamline or simplify anything. It's a complex and difficult problem and won't go away or get solved in a easy manner.

Latency. Just because it's "low" doesn't mean it's lower than without the abstraction layer (and therefore indirection) brought about by the daemon. It's there and it's got to be compensated for in a game. If you bring something to the table that's useful, then yeah, it might be "okay".

What is the latency between the time you press your mouse button and the response on the screen?

Do you not realize that all of this has to move through a video server?

Is that latency too high for your audio?

Do you not realize your video is going through a video server, just like Pulse Audio is a sound server?

What is magical about shoving a bunch of software mixing code in your kernel that makes it oh-so-magically less latency then sticking software mixing code in a daemon?

If ALSA's broken and "needs" this- shouldn't you be fixing it instead of slapping a band-aid on the problem, hm?

None of this ever going to get fixed in Alsa. None of this gets fixed by switching to OSSv4. Or any other driver sub-system that has been created by anybody will solve the issues that PA is forced to deal with.

The F-up that Alsa did originally was trying to do TOO much. It was trying to be a driver system, low-level userspace interface, and a high-level application interface.

This was a stupid design that does not work. Audio is much too complicated to be fixed in such a monolythic manner. It was a mistake because at the time the people designing Alsa did not understand the total scope of the problem (not because they were stupid).

PA allows Alsa to become what it should of been in the first place:

A driver infrastructure and very low-level API for userland.

Getting a proper sound server working fixes the design. Shoving more complexity in Alsa is not likely to work and will probably make the problem worse.

[mugginz]

Pretty embarrassing for the Linux desktop, that's for sure. Not to mention frustrating for users of that desktop.

Not to mention frustrating to the developers writing software for it.

And it's not yet resolved- PA doesn't really do it either, sadly enough. It mostly works, but then ALSA kind of fit that role as well for some time now. It's an improvement over ESD, but that's not saying a lot. It's better than ARTS, again not saying much when you get to brass tacks.

When you keep having to re-work things like this, there should be a hint in that...

And now people are calling for yet another change in tack.

If you can't get it working right, you need to either fix what you've got or replace it with something that will. Slapping abstraction layers on top of broken, complex systems will only hide issues at best- and that's what PA advocates are asking for first and foremost when they insist upon this being the fix for the "sound problem".

If nothing else, we NEED to fix ALSA or replace it before talking about things like PulseAudio, JACK, etc.- because wrappers will not fix the problems in the framework, only hide them. ESD and Arts should've taught us that much if nothing else.

Are you talking about the way ALSA drivers are implemented or the framework above them?