Linux is not ready for Steam

[darkphoenix22]

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.

Man I really hope that doesn't cause problems for me down the road...

I still remember the epic mess making Nouveau default made.

[Svartalf]

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.

Sounds like you're making the first steps. If it works out and OSS4 works as well as it's proponents make it out to be, that'd be a boon for everyone, really. We don't need half the functionality ALSA provides (seriously) and it'd make writing sound producing apps easier, including abstraction edges like SDL/SDL_mixer, FMOD, IrrKlang, and OpenAL/cAudio.

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.

No, we don't. And it sounds like you're mostly on the same page I am with this. I don't care WHAT we choose so long as it's robust, simple, and accomplishes multiple sources being stitched together onto the single set of speakers, coupled with allowing multiple requesters to pull sound from the input lines.

[Svartalf]

Man I really hope that doesn't cause problems for me down the road...

Get ready for "fun".

I still remember the epic mess making Nouveau default made.

Heh... About the same mess having people insert ALSA by default and PulseAudio by default made. We need to get this largely right now (You're not going to get Valve to wait on Steam/Source- it'll be on THEIR schedule...) and in a manner that will not overly break anything out there commercial games-wise. Caster should work. Cortex Command should work out well as well. Other titles, not so sure. If the Mixer works as advertised, I'll bet that SDL/OpenAL will fall back to OSS gracefully and just mostly work out of box. Timings might need to be tweaked (they were adjusted to ALSA/PulseAudio...) but past that they should work. Same goes for anything using FMOD, IrrKlang, or Miles.

[Svartalf]

The other thing you need to concern yourself with would be to get a BeagleBoard and try to make OSS work right for it. Most of the ARM Linux systems are using ALSA and this move should probably also account for them if you're going to work on making it start to happen.

[curaga]

OSSv4 isn't quite ready yet, mostly because of the mixer GUI and the need to update the drivers.

Wait, you judge a sound system based on its GUI mixer?

[darkphoenix22]

Wait, you judge a sound system based on its GUI mixer?

I'm a distro maintainer. I have to make sure things are pretty and easy for end-users. I think the Xfce Mixer can be patched to support OSSv4 though.

[darkphoenix22]

The other thing you need to concern yourself with would be to get a BeagleBoard and try to make OSS work right for it. Most of the ARM Linux systems are using ALSA and this move should probably also account for them if you're going to work on making it start to happen.

I'll look into as soon as I get some funding. I'm working on a media center ATM though.

[darkphoenix22]

Well OEM media center.

[crazycheese]

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.

No offence, I have a feel I talk to the wall here.
I was unable to get DMIX do job done for the reasons mentioned in my post of what ALSA lacks.
First it does not support true software mixing - it cannot mix streams of different bitrate and frequency, so if one is playing 44kHz and other starts 22kHz only second is played.

Second DMIX does not prevent any application take over the sound card. This means for example Adobe Flash or Avidemux taking over soundcard, stopping any other music playback instantly. Any new application will exit with error unable to access device or device busy until the hijacker is closed. This never happens in PA.

This and many more is done by Pulse. But ALSA doing it properly will eliminate need for extra 20Mb of RAM(so much takes PulseAudio, almost nothing). Never the less Pulse is sanely implemented, it can take over and give features. If you dont want it, you can remove it.

If you dont see the point of Pulse, why dont you visit at least its Wikipedia entry?

ALSA is not replacing Pulse
Pulse is not replacing ALSA

Pulse implements wide array of features, absent in ALSA, such as live audio stream rerouting. This is similar to JACK, however is desktop (and not workstation) optimized. I consider it pretty cool to have individual per-app volume controlls as well as individual recording controls(where you can separate Mic from sound card and Mic from Webcam and adjust the volume live and per app).
Pulse is not related to Ubuntu.

--Let me introduce you to the basics of Linux multimedia--

---CODECs
liblame, libh264, libwhatever is a codec - it encodes or decodes the encrypted binary stream. Application can talk to the codec library directly. If stream is not encoded(RAW) it can be send directly to sound card driver.

Ffmpeg is just a large codec collection(instead of individual libraries). It is all-in-one library, like Mplayer, featuring many MPEGx codec routines.

Xine is similar to Ffmpeg and Mplayer in terms it is one big all-in-one codec, but it only supports decoding(which is lame) and it also allows linking to external additinal libraries(so its not one massive rock like Mplayer)

Gstreamer is an interface for multimedia. It makes talking to codecs for purpose of code/decode a fuzz. It makes programming easier. It consists of gstreamer core and gst-plugins. Plugins are just binders to individual codec libraries mentioned before. When you install gst-plugin-ffmpeg you also install libffmpeg. You can understand it as an exoskeleton around codecs, making life much easier for a programmer. It talkes corresponding codec and outputs to correspondent sound system - two hares with one shot. It is not like MPlayer or Xine, or Ffmpeg - it lets system stay flexible. However its only Linux(BSD?).

Example:
Libmpeg, Mplayer(having copy of libmpeg it inside), Xine(having it inside as decode only version), Ffmpeg(having its functionality inside) are duplicates in the system. Gstreamer plugin libmpeg and libmpeg are not duplicates.

---- Sound Libraries
This libraries make programmers life easier.
Instead of talking to decoder and sound card system directly, they just talk to Sound Library.

SDL - features capable mixer and backend. Developer just write code for SDL to play his sounds/music, and SDL compiled against ALSA, OSS, Pulse, Jack or even windows directsound - talks to them by itself for the output. Should user have any of this four or one installed, SDL will talk to them. For the en/decoding - SDL can access individual codecs automatically(as far as I know), but also has support for Gstreamer. It is crossplaform and part of big toolkit(it also has layers for networking and 3D via OpenGL). The disadvantage is its interface while more universal - is more generic(basic) than talking to this five personally(and releasing five program verions). But its more than enough for gaming.

OpenAL - same as SDL-audio part, but more 3D audio features. Many apps can output to OpenAL or SDL, whatever you have in your system.

Allegro - heard its same as SDL, but less featurefull, heard its practically depricated. Also Allegro worked on Pulse.

---- Sound Servers
Pulse can:
- mix streams from different sources(applications and cards)
- per-application and per-sound card volume with mouse
- network stream broadcasting
- connect OSS and ALSA to one single thing. Application talk to Pulse and pulse sends to ALSA or OSS. Developer only needs to output to pulse.

What Pulse is not:
- it is not a codec
- it is not a hardware manager
- it cannot connect codecs or connect applications and codecs.
Its just a network-capable awesome mixer.


Phonon is DEPRICATED. Use Pulse and Gstreamer instead. Phonon is not part of KDE, but part of Qt. Originally Phonon was meant to automatically detect wherever Qt application is run on Linux(ALSA,OSS), BSD(OSS) or Windows(DSound). However, on all platforms it is unnecessary now because of pulse. Pulse is crossplatform and gives more than Phonon, hence Qt abadoned it.

JACK is same to Pulse, but shifts on application-to-application links, lower latencies and professional usage. You can connect JACK to Pulse, JACK connects applications together and result goes to Pulse which connects it to multiple sound cards.

---- Sound card systems
Further, ALSA - a hardware management and (to some degree) mixing system vs OSS are end-point audio hardware systems.
These manage the hardware. They can take that binary stream(only unencrypted) and make a card play it.
If you have encrypted stream(ogg,mp3,wav,flac whatever) you need to decode it before it can be send to hardware.

Additionally OSS,compared to ALSA, features more mature mixer, easier API but is known for making crap in the past. A commercial company stands behind it - thats it. Commercial means making money by any case possible. Thats why I consider ALSA better to OSS, I can hardly imagine how OSS can make money not by selling licenses. One day they stop releasing GPL version and Linux is screwed again. Its trilicensed btw, not only GPL.


-------- Possible playback variations:

Raw--->ALSA or OSS--->Sound cards
::App need to work with ALSA or OSS

Encrypted--->liblame---->ALSA or OSS---->Sound cards
::App need to work with liblame and ALSA or OSS
Very bad mixing in ALSA.Takeover possible if app written in bad style.

Encrypted--->Gstreamer(takes out liblame automatically)--->ALSA or OSS(whatever Gstreamer is set to)----->Sound cards
::App need to work with Gstreamer only.
Very bad mixing in ALSA.Takeover not seen, since Gstreamer behaves correctly.

Encrypted--->Gstreamer(takes out liblame automatically, set to pulse plugin)--->Pulse---->ALSA or OSS(whatever pulse is set to)----->Sound cards
::App need to work with Gstreamer only.
Good mixing, no takover possible, regardless if gstreamer is not only app playing.

Encrypted--->SDL(calls Gstreamer automatically, as it sees Gstreamer is present)--->Gstreamer(takes out liblame automatically, set to pulse plugin)--->Pulse---->ALSA or OSS(whatever pulse is set to)----->Sound cards
::App need to work with SDL only. It is crossplatform.
Good mixing, no takeover possible, as above.

Encrypted--->SDL(calls Gstreamer automatically, as it sees Gstreamer is present)--->Gstreamer(takes out liblame automatically, set to alsa or oss)--->ALSA or OSS(whatever pulse is set to)----->Sound cards
::App need to work with SDL only. It is crossplatform.
Very bad mixing in ALSA.Takeover not seen, since Gstreamer behaves correctly.


I dont see any problem with linux.

If you program for linux only or require more features - use Gstreamer for sound operations.

If gstreamer is too generic for you, you will have to 1) talk to codecs 2) talk to sound system of your choice -- all your way, ie manually.

If you dont want gstreamer, xine offers similar functionality(although codec part is totally differently implemented). But gstreamer and xine can coexist(although there will be duplicated stuff)

If you programm crossplatform - use SDL or OpenAL.
Yes, this is not copypaste, comments welcome.

[pingufunkybeat]

First it does not support true software mixing - it cannot mix streams of different bitrate and frequency, so if one is playing 44kHz and other starts 22kHz only second is played.

This sounds like a serious bug that needs to be fixed.

Second DMIX does not prevent any application take over the sound card. This means for example Adobe Flash or Avidemux taking over soundcard, stopping any other music playback instantly. Any new application will exit with error unable to access device or device busy until the hijacker is closed.

I cannot reproduce this. Adobe Flash does not block the sound card. In fact, nothing does.

Pulse implements wide array of features, absent in ALSA, such as live audio stream rerouting. This is similar to JACK, however is desktop (and not workstation) optimized.

So people who need it can use JACK. Or PA. Or anything they want.

I don't see a need to make this a desktop standard and to have everything depend on it. And making it a default that is almost impossible to turn off and breaking X applications in the process, like Ubuntu did, is simply a terrible idea.

The fact is, while per-app volume control is kind of neat, most people don't need anything else than volume control and reliable software mixing.

Then again, mixing belongs on the sound card anyway.

--Let me introduce you to the basics of Linux multimedia--

I don't know if you're addressing this to me specifically, but I'm quite aware of all this, thank you.

Phonon is not part of KDE, but part of Qt.

You are aware that Phonon is KDE technology which was donated to Qt, right?