Linux is not ready for Steam

[darkphoenix22]

softvol wasn't meant to be used for per-application volume controls, it was made so you could adjust your master sound volume if your hardware didn't have hardware volume control. Using softvol to provide per-application volume controls is a hack and must be implemented by apps themselves or a wrapper.

OSSv4 has transparent and centrally managed per-application volume controls. Built into the API. No additional wrappers or programming required.

[darkphoenix22]

AlSA is easly extendable. Unlike OSSv4 which has how many devs left? 1? Or pulseaudio, which will fail like HAL failed.

PulseAudio was made a wrapper to extend ALSA as the devs didn't want to bother with the frustration of adding new features to ALSA. Many of the same devs who made ALSA also made PulseAudio (although the core maintainers are different). You're not going to get active development on one without the other.

[Kano]

As you seem to know alsa very well maybe you could show me a config for hdmi audio with softvol + dmix. i currently have got dmix running with hdmi (over gt220).

[darkphoenix22]

I've never tried using softvol to provide per-app controls. Mostly because such an external solution is much more trouble than it's worth.

[pingufunkybeat]

Do you have any source for all this stuff you are talking about?

Mixing belongs into the sound system. There is no way that applications should worry about whether something is playing already. That's not a hack, it is exactly where it belongs. The history of Linux sound is a history of weirdo sound daemons which were all hated and ended up abandoned carcasses next to the road. An app should either talk to a well-defined hardware interface (ALSA or OSS, or something else), or using a library which abstracts this away. It should not be talking to a daemon which most people will not install anyway.

PA and JACK are solutions for sound professionals, not for playing music on a regular everyday desktop. You don't need any of their features for anything you do every day, unless you're a sound engineer. Forcing this onto everyone just so 0.01% of people can stream sound over the network as a tech demo is insane.

If there are problems with ALSA, then you fix ALSA. It seems like most "problems" don't even exist. Sure, per-app volume would be nice. should I run a professional sound daemon and run all my software through an emulation layer because of this? Hell no!

Software mixing only exists because some hardware does not do this at the hardware level. If it doesn't exist at the hardware level, then it has to be performed by a driver -- dmix. OSSv4 does exactly the same thing. Why on Earth is on a hack, and the other one not?

What are you smoking?

[kraftman]

It work well enough for my friend. Did you try the trunk build? The stable build has issues, according to my friend who is now using the trunk build of OSSv4 on Gentoo.

He told me that it also resulted in a huge increase in sound quality and clarity on his computer. He was quite pleased with this surprize.

I tried it few months ago, but I never had problems with ALSA, so I don't see too many reasons to switch. Maybe differences are noticable in some applications? While the stable version has some known issues and supports less features then ALSA I don't see how it can be better. However, for some people OSSv4 works better, but I'd rather vote for fixing ALSA then replacing it with OSSv4 which is worse for other people. There must be reasons why ALSA was chosen over OSSv4. Overall, I don't care about non Linux platforms, so I prefer Linux to not support Unix like systems. I also don't notice any difference in the sound quality between Linux+ALSA and Windows. If OSSv4 will prove it's better for long term then no problem. I'd like to have something which works as it should without Pulse Audio, because it consumes CPU time. Right now, Phonon+Xine works fine for me with ALSA.

[darkphoenix22]

Do you have any source for all this stuff you are talking about?

Mixing belongs into the sound system. There is no way that applications should worry about whether something is playing already. That's not a hack, it is exactly where it belongs. The history of Linux sound is a history of weirdo sound daemons which were all hated and ended up abandoned carcasses next to the road. An app should either talk to a well-defined hardware interface (ALSA or OSS, or something else), or using a library which abstracts this away. It should not be talking to a daemon which most people will not install anyway.

Where did I call dmix a hack? I called implementing per-app volume controls using a wrapper or softvol a hack.

PA and JACK are solutions for sound professionals, not for playing music on a regular everyday desktop. You don't need any of their features for anything you do every day, unless you're a sound engineer. Forcing this onto everyone just so 0.01% of people can stream sound over the network as a tech demo is insane.

If there are problems with ALSA, then you fix ALSA. It seems like most "problems" don't even exist. Sure, per-app volume would be nice. should I run a professional sound daemon and run all my software through an emulation layer because of this? Hell no!

I agree, which is why PulseAudio is a "bad thing". Per app volume controls should be in the core sound API itself, not implemented via a wrapper.

Software mixing only exists because some hardware does not do this at the hardware level. If it doesn't exist at the hardware level, then it has to be performed by a driver -- dmix. OSSv4 does exactly the same thing. Why on Earth is on a hack, and the other one not?

I think you need to read my posts a little more carefully because I comepletely agree that software mizing and per app volume controls should be in the core API, not implemented via a wrapper.

In fact, I support OSSv4 for the very reason that the ALSA devs aren't implementing features anymore and are instead relying on PulseAudio to provide new features. Mostly because they can't be bothered to extend ALSA anymore it's too damn complicated to be usefully expanded while keeping API stability.

Linux needs a simple, extenisble audio API that doesn't need wrappers to provide functionality that should be in the API itself. ALSA will never be that API. OSSv4 has the potential to become it, if we solve the political issues.

[darkphoenix22]

I tried it few months ago, but I never had problems with ALSA, so I don't see too many reasons to switch. Maybe differences are noticable in some applications? While the stable version has some known issues and supports less features then ALSA I don't see how it can be better. However, for some people OSSv4 works better, but I'd rather vote for fixing ALSA then replacing it with OSSv4 which is worse for other people. There must be reasons why ALSA was chosen over OSSv4. Overall, I don't care about non Linux platforms, so I prefer Linux to not support Unix like systems. I also don't notice any difference in the sound quality between Linux+ALSA and Windows. If OSSv4 will prove it's better for long term then no problem. I'd like to have something which works as it should without Pulse Audio, because it consumes CPU time. Right now, Phonon+Xine works fine for me with ALSA.

I agree that PulseAudio should be removed and that ALSA should stay as the default sound API for the near future. ALSA, as is, is not a viable long term soultion, for the extensibility reasons I have stated above.

And I'm not sure ALSA can be fixed to become simple and extensible. Which is why I began to look at other options like OSSv4.

[darkphoenix22]

Summary:

- Short-term: Abandon PulseAudio

Why?

If a game uses sound for timing, it's toast with PulseAudio due to the higher latency. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.

- Long-term: Look at OSSv4 as a possible replacement for ALSA

Why?

PulseAudio's 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 API stability. This is why PulseAudio was created in the first place.

[pingufunkybeat]

This would not be possible with ALSA unless we made another wrapper

Why?

The problem is ALSA is too damn complicated to be usefully expanded while keeping API stability. This is why PulseAudio was created in the first place.

Says who?

PulseAudio was created to replace ESD.