Linux is not ready for Steam

[crazycheese]

there is a nice framework for audio. It is called ALSA. There is also SDL.
What else is needed? Besided buzzwords from butthurt ubuntu users?

1. Correct mixing of audio streams of different frequency.
2. Prevention of sound card blockade(or take-over) by single application.

The rest like sound card volumes per-app management, one-click sound card mode of operation selection, multiple sound cards management, multimedia streaming over network is very good taken care by pulse. 1&2 would be sufficient for ALSA use on general desktop(not that fancy workstations or people working with several cards etc etc).

Up to the moment - pulse works with everything. It includes both direct output plugins for various, various applications and libraries that this appliacations use. It includes fallback option on catching stream incorrectly directed to alsa.

Oss is a traitor, I will never trust someone turning 180° from BSD to commercial and efficiently abadoning opensource. This is utter crap system. This is the reason ALSA exist. Instead of trolling each other about how bad alsa or pulse is, it is much smarter to separate local problem (fckedup ubuntu because for not reading PA man, from crappy closed sound drivers for several chips, for incorrectly using server kernel on desktop sound server etc) from design flaws. Currently PA has no design flaws. Alsa has two flaws I described, efficiently shifting it from sound system to sound card system. It would be NICE if dmix get the fixes.

Ugh, infinityos...

<edit package.use to replace "-oss", "alsa" and "pulse" with "oss", "-alsa" and "-pulse" accordingly>
rm /etc/asound.conf
emerge -Cq pulseaudio alsa
layman -a majeru
emerge -q oss
emerge -DN world

[pingufunkybeat]

Ever since ALSA got a software mixer (dmix) for cards who can't do hardware mixing, I haven't felt a need for a new audio anything.

I don't see the point behind PulseAudio. I don't see a need for it. Something is fine if it stays out of my way and does what I expect it to. I expect my soundcard to play sounds, mix them, and allow basic volume control. ALSA works.

To me, PulseAudio is a solution looking for a problem, and creating far more problems along the way. It is surely an interesting piece of engineering, but not a piece of engineering anyone needs as default on their desktop distro. I don't need it, and I don't want headaches, so it's not coming anywhere near my machine. It's aRts and ESD done correctly, at a time when nobody needs aRts and ESD.

Linux has a decent sound system - ALSA. Linux also has several choices for media decoding - ffmpeg, xinelib and GStreamer. Pick one for your app and go. Even better, use a higher-level interface which will abstract from it, like Phonon or SDL.

[darkphoenix22]

Oss is a traitor, I will never trust someone turning 180° from BSD to commercial and efficiently abadoning opensource. This is utter crap system. This is the reason ALSA exist. Instead of trolling each other about how bad alsa or pulse is, it is much smarter to separate local problem (fckedup ubuntu because for not reading PA man, from crappy closed sound drivers for several chips, for incorrectly using server kernel on desktop sound server etc) from design flaws. Currently PA has no design flaws. Alsa has two flaws I described, efficiently shifting it from sound system to sound card system. It would be NICE if dmix get the fixes.

OSSv4 is completely open source and under the GPL. ALSA is a complicated mess and the reasons for it's creation no longer stand.

BTW my preference is FFmpeg, mostly because the plugins system for GStreamer is more trouble than it's worth. I just use the gstreamer-ffmpeg plugin and call it a day.

[Svartalf]

Allegro is pretty dead.

I'd hesitate to say that... There's at least one IGF winner from last year that uses it.

SDL can be compiled to ANY library. It can also be compiled with ALL libraries support, you have to set single envvar to tell it what it should use.

Indeed. Baseline sound is not TOO bad with SDL. However, it's not an ideal choice. It is limited in what it and SDL_mixer can do- and more to the point tuning it within that space to avoid latency issues with sound output can be...entertaining...

If you are using OSS and have single card, you pretty much dont need PulseAudio.

Perhaps not "need", but desire, perhaps. If you're running a single sound application and don't mind unloading some things when you want to run a game or deal with a tracker or MIDI app- or to play music, then yeah, it works just fine. If you want to have a SIP phone up on your desk or something similar and want to do more than just that task (i.e. play a game, etc...) you're going to have no end to problems with most of the applications within OSS unless you adopt the latest API edge to cope with that problem. OSS as most people use it is a single sound source playing model- and you have to do something like PulseAudio, Phonon, etc. on TOP of it to make it work like the MacOS and Windows crowd have come to expect things to work (Not to mention most Linux users, really...).

But OSS, like Microsoft, is known for backstabbing.

Not these days, but in the past, yeah.

Besides, Pulse takes 20Mb RAM at peak for all options it gives.

Ah... But with a machine with 256Mb or more RAM, that's not a major problem- and with Gigs of RAM it's mostly a non-issue. Yes, it's bloat. They probably ought to re-think what they're doing within it, if you ask me. The idea itself is a sound one, no pun intended, and unless you can come up with a good, graceful way to handle it in the Kernel you're going to have to have some userspace bit to do this with (OSS4 might've done that- but we don't know in the large because ALSA was put in it's place because of politics ages ago. I didn't quite agree with them then, but I wasn't in a position to challenge it back then.).

[darkphoenix22]

Perhaps not "need", but desire, perhaps. If you're running a single sound application and don't mind unloading some things when you want to run a game or deal with a tracker or MIDI app- or to play music, then yeah, it works just fine. If you want to have a SIP phone up on your desk or something similar and want to do more than just that task (i.e. play a game, etc...) you're going to have no end to problems with most of the applications within OSS unless you adopt the latest API edge to cope with that problem. OSS as most people use it is a single sound source playing model- and you have to do something like PulseAudio, Phonon, etc. on TOP of it to make it work like the MacOS and Windows crowd have come to expect things to work (Not to mention most Linux users, really...).

OSSv4 has built in mixing and per-application volume controls.

[Svartalf]

OSSv4 is completely open source and under the GPL. ALSA is a complicated mess and the reasons for it's creation no longer stand.

The biggest impediment to moving back to OSSv4 is inertia and the lingering aftertaste of the infighting that occurred when at least one Linux distribution vendor forced the issue and moved ALSA in, more as a fait accompli than anything else, into the kernel and "deprecated" OSS. We needed answers back then- they weren't forthcoming immediately from the OSS camp at that time. Perhaps they could have worked out the issues with OSS, perhaps not. Now we're stuck with ALSA- and I'm not wholly sure how to disentangle ourselves from the mess that was made there. I know for a fact that doing something like was done with ALSA back the other way wouldn't be a good answer either (Many don't know the pure AGONY trying to sort out the chaos that the move there caused for about 6-12 months...it wasn't fun making it work right for everything...hey, that'd be about like what PulseAudio's been doing to people... )

BTW my preference is FFmpeg, mostly because the plugins system for GStreamer is more trouble than it's worth. I just use the gstreamer-ffmpeg plugin and call it a day.

Understandable.

[Svartalf]

OSSv4 has built in mixing and per-application volume controls.

Like I said... I thought they'd sorted it out more at the lower levels, but I wasn't sure because I've not had the time to try to hose up my machine and then un-hose it by ripping Pulse/ALSA out and putting OSSv4 in. And as I said before in the previous posts, making a by-fiat answer like that, you're going to have the same fun going forward for about 6-12 months as people sort out what you've done- and in some cases try to un-break their games (studios, that is...) by what you've done there if we did it.

I'm not saying we shouldn't look into that- but we need to make a very, very well thought-out decision on this before acting. Yes, we need answers now. NO, we don't need to just make the problems worse in other areas more than ONCE. We won't get another shot at moving things around like this for many years to come.

[darkphoenix22]

The biggest impediment to moving back to OSSv4 is inertia and the lingering aftertaste of the infighting that occurred when at least one Linux distribution vendor forced the issue and moved ALSA in, more as a fait accompli than anything else, into the kernel and "deprecated" OSS. We needed answers back then- they weren't forthcoming immediately from the OSS camp at that time. Perhaps they could have worked out the issues with OSS, perhaps not. Now we're stuck with ALSA- and I'm not wholly sure how to disentangle ourselves from the mess that was made there. I know for a fact that doing something like was done with ALSA back the other way wouldn't be a good answer either (Many don't know the pure AGONY trying to sort out the chaos that the move there caused for about 6-12 months...it wasn't fun making it work right for everything...hey, that'd be about like what PulseAudio's been doing to people... )

I'm looking at making it ALSA/OSS4 an install time choice or having two separate ISOs for infinityOS 2.0. OSSv4 isn't quite ready yet, mostly because of the mixer GUI and the need to update the drivers. But I think it would take a lot less work to fix up OSSv4 than it would take to fix ALSA/PulseAudio.

A good first step would be for distros to push OSSv4 to their repositories and begin testing. Arch and Debian already have it, but I don't believe Gentoo does. OSSv4 needs to be throughally tested before we can adopt it. We don't want another PulseAudio situation.

[Kano]

Currently the U maverick kernel has OSS completely disabled if nobody noticed that... Most games seem to use openal for sound, that can be compiled with pulse audio support too, but i see no real reason to use it.

[Svartalf]

Well, again: PulseAudio is not a high-latency framework. It's low-latency; PA tries to provide lower latency than just using ALSA.

Uhm... If you stop to think LONG and hard about that, RealNC, you'd see the error in that remark. HOW can one provide LOWER latency, wrapping around an API edge with another one around it, hm? You can certainly try to, but you will pretty much always fail to accomplish because you're going to insert at least the dispatch times for the abstraction calls in the mix.

If games don't work with it, it's not due to latency. The bug lies elsewhere.

Don't bet on it. There ARE issues on some machines with latency that if you kill PA and just go ALSA, they go away.