Linux is not ready for Steam

[Svartalf]

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.

There's a LOT of politics going on with this stuff- many things, PulseAudio included, being offered more as a done deal than anything else.

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.

I think they will be too. The problem is PA doesn't FIX things like you think it does- it fixed YOUR problems. I've found some of the edge cases in my stuff and with the testers I've had with the game ports I've done.

Same here.

It remains to be seen if Hannu and Co. have something going there or not- if there's a way to migrate the ALSA drivers over to OSSv5 and he's got his ALSA layer stuff right, perhaps... That's a lot of ifs though- I'd like to see a fix to this whole mess that's cleaner than what we've got going.

Well the per app volume from a central control is benificial and useful.

Heh... ALSA was supposed to have gotten that as part of the feature set- it was one of the things they used to sell everyone in the community to move over to it and ditch OSSv3.

Working bluetooth integration. If someone wants to say it worked before Pulse then their version of worked is defferent to mine.

I've hit-or-miss issues with Bluetooth with PA. It works slightly better for me with PA than with ALSA, but I can't tell you if that's because ALSA was bad at it or if the BT drivers weren't as good back then. Neither can you unless you've been digging into the guts of both items.

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.

It varies. Remember my remarks. As a software professional of over 25 years in the industry, I've seen many, many attempts to wrap a broken interface or framework with a wrapper- they all end up hiding the issues or making things worse in other areas. Each and every time you do it. If it's broken or incomplete, putting something around it won't fix things- it's sweeping the problems under the carpet.

But who's coming forward with a proven alternative?

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

Hannu looks to be trying- don't know if he'll get there though.

Speaking as a driver developer of numerous years for the Linux kernel (Industrial I/O, imaging devices, and network devices...) and xorg (Utah-GLX...) the bulk of the code is about being in one of several classes with similar behaviors on the OS side of things and the hardware which differs at least slightly in how you talk to it. Much of the code could be used as a crib sheet for OSSv5 drivers if push comes to shove and vice versa since the licenses are completely compatible.

I don't know if ripping ALSA out for something along the lines of OSSv5 if it gets done is a good or bad idea. However, I do know we do need to come up with better core answers than we're doing in the community. PA's main piece that got it sold in was the per-process mixing and the resampling while mixing, if memory serves. If ALSA can't do that one, perhaps it needs to be fixed to do it- because it was supposed to be one of the main features of it to begin with. And if it's "broken" without the wrapper, perhaps there's serious flaws underneath we're sweeping under the carpet here with PA being required.

[drag]

Well PA faced the similar problem with drivers that Network-Manager faced.


PA depends on correct drivers to function.

Traditionally with Linux if your audio sounded like shit then you had to mess around with asoundrc files and things like that.

The reason the audio sounded like shit was that the audio drivers sucked and were doing bad things. Messing around with buffer settings and other things in asoundrc was just people putting a lot of effort into working around driver bugs that never were getting fixed.

but this is retarded because we are not using Windows... we are using Linux. We have access to the source code and the drivers should be fixed rather then forcing users and applications to work around them.

This is one of the big issues with PA early on. It was running into all sorts of problems and instead of working around the bugs like everybody has been doing they fixed the drivers.

It takes the driver fixes a while to get back to the users...

[Svartalf]

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

More the framework above them. Drag's right in that we've got a mess and people missed the scope of the problem in their attempt to make ALSA what it is today. All I know is that it DOESN'T WORK the way we're all trying to do it.

Perhaps it's that we're still trying to push ALSA through PA- I've been led to believe most of the issues vanish if you go directly to PA's own API. Unfortunately, most everyone's using it as a wrapper to OSS and ALSA- which is where many of the woes with the whole thing come into play.

Perhaps PA is the right answer as long as you move to it as your API.

I can't say since there's only a few things right at the moment that provide PA edges, OpenAL-soft and SDL being the only two I know of right now. Everything else for sound middleware (the actual high-level application frameworks, really...) uses ALSA or OSS for their low-level API edges. Therein comes your problems with games- they're not all going to use OpenAL (and certainly not SDL unless they're a small casual game developer- or they're forced to for compatibility reasons...)- and this is where a good portion of the fun comes from. All the high-level stuff ending up using the "wrong" edges for a given user's config- and it differs from each user's system as to what precisely that is within the context of PA.

As I've said...slapping a wrapper on top of a broken interface doesn't make for it working better.

[Svartalf]

As an aside: I have to reboot my quad-core machine I develop on periodically to get sound to work right. PA just packs it up and leaves the interfaces in such a state that I can't always get audio back. Regardless of the fact that it might be a driver problem (How? It's a typical HDA codec that others have...) the fact that sound just simply QUITS WORKING, should hammer home that we still don't have it right yet- even if PA's the answer.

[mugginz]

There's a LOT of politics going on with this stuff- many things, PulseAudio included, being offered more as a done deal than anything else.

Yes, a lot of politics. I however focus more on the outcomes for users (myself included )

I don't care which sacred cows get caught up in this subject. As long as the actual outcome is that someone can put a DVD in their machine, install Linux, install apps and everything just works then I'm happy. Fiddling in config files shouldn't be required/

I think they will be too. The problem is PA doesn't FIX things like you think it does- it fixed YOUR problems. I've found some of the edge cases in my stuff and with the testers I've had with the game ports I've done.

What I'm saying is that there's currently no option that works in every situation. Only options of varying breakage. Some say they're happy with Pulse, some say they're not. Across the machines I install I'm happiest with Pulse. I read of many who are also happy with it as well. This couldn't of been said 12 months ago though. Now that there's some light at the end of the tunnel I hope we don't have that light shut out with a collapse and another delaying shift in direction.

It remains to be seen if Hannu and Co. have something going there or not- if there's a way to migrate the ALSA drivers over to OSSv5 and he's got his ALSA layer stuff right, perhaps... That's a lot of ifs though- I'd like to see a fix to this whole mess that's cleaner than what we've got going.

But if Pulse can leverage the ALSA drivers and cleanly re-implement the higher level stuff then there's also value there.

If they can release an OSSv5 that works with everything, and does everything better than Pulse, with as full hardware support as that provided by the ALSA driver set and this makes all the sound woes go away then they have nothing to worry about. Everyone will pick up their code. If they can demonstrate clear superiority then they're on a winner. If they want to "release early, release often" their code then I'm not interested until it's finished, working, and a viable alternative in a full way.

Well the per app volume from a central control is benificial and useful.

Heh... ALSA was supposed to have gotten that as part of the feature set- it was one of the things they used to sell everyone in the community to move over to it and ditch OSSv3.

Not the first or last project to promise and not deliver. Will we see the same for other sound solutions?

Working bluetooth integration. If someone wants to say it worked before Pulse then their version of worked is defferent to mine.

I've hit-or-miss issues with Bluetooth with PA. It works slightly better for me with PA than with ALSA, but I can't tell you if that's because ALSA was bad at it or if the BT drivers weren't as good back then. Neither can you unless you've been digging into the guts of both items.

Well I actually had to dig into the innards of ALSA and the bluetooth stack a little to try and trace where the breakage was. I haven't had to dig into PA's code. Either way, if there's to be a change away from what we have now it'll have to be usable with bluetooth as well.

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.

It varies. Remember my remarks. As a software professional of over 25 years in the industry, I've seen many, many attempts to wrap a broken interface or framework with a wrapper- they all end up hiding the issues or making things worse in other areas. Each and every time you do it. If it's broken or incomplete, putting something around it won't fix things- it's sweeping the problems under the carpet.

I've been a software developer in my earlier times and have a decent appreciation of the issue in play. This is why I'm aware that the "throw it away and start from scratch" method has it's problems as well. Someone has to implement code to provide the required functionality. If it's quicker to fix what we have instead of yet again starting from scratch then I'm all for that. On the other hand of someone can show me a finished product that's good to go then I can appreciate that equally as well. Unless there's a viable alternate there's value in sticking with the known quantity.

But who's coming forward with a proven alternative?

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

Hannu looks to be trying- don't know if he'll get there though.

Speaking as a driver developer of numerous years for the Linux kernel (Industrial I/O, imaging devices, and network devices...) and xorg (Utah-GLX...) the bulk of the code is about being in one of several classes with similar behaviors on the OS side of things and the hardware which differs at least slightly in how you talk to it. Much of the code could be used as a crib sheet for OSSv5 drivers if push comes to shove and vice versa since the licenses are completely compatible.

And this facilitates the development of new drivers but doesn't provide them by itself.

I don't know if ripping ALSA out for something along the lines of OSSv5 if it gets done is a good or bad idea. However, I do know we do need to come up with better core answers than we're doing in the community. PA's main piece that got it sold in was the per-process mixing and the resampling while mixing, if memory serves. If ALSA can't do that one, perhaps it needs to be fixed to do it- because it was supposed to be one of the main features of it to begin with. And if it's "broken" without the wrapper, perhaps there's serious flaws underneath we're sweeping under the carpet here with PA being required.

But I'm saying if the ALSA guys fix their brokeness then I'm happy.

Until they demonstrate finished code I'm not interested in shifting to another flavour of brokeness. I prefer the flavour I've got at the moment.

[Thetargos]

Very well explained and worded... I'd add, however, that this is only true for those cards that do not have hardware mixing support in either ALSA or OSS. For the ALSA part I know of some (Creative EMU10K1/2 [Original Live and Audigy] and some 4D Sound chips, some others I do not readily remember make or model). Most recent sound chips (integrated or otherwise, as even some high end cards support only one strea, at least in ALSA [Yes, I'm looking at you M-Audio!]) seem to be single stream-only (or have support for only one stream in either ALSA or OSS, I really do not know for sure)... I'll go now to finish reading the rest o the commnts, just wanted to comment on this.

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.

[mugginz]

More the framework above them. Drag's right in that we've got a mess and people missed the scope of the problem in their attempt to make ALSA what it is today. All I know is that it DOESN'T WORK the way we're all trying to do it.

Perhaps it's that we're still trying to push ALSA through PA- I've been led to believe most of the issues vanish if you go directly to PA's own API. Unfortunately, most everyone's using it as a wrapper to OSS and ALSA- which is where many of the woes with the whole thing come into play.

Perhaps PA is the right answer as long as you move to it as your API.

I can't say since there's only a few things right at the moment that provide PA edges, OpenAL-soft and SDL being the only two I know of right now. Everything else for sound middleware (the actual high-level application frameworks, really...) uses ALSA or OSS for their low-level API edges. Therein comes your problems with games- they're not all going to use OpenAL (and certainly not SDL unless they're a small casual game developer- or they're forced to for compatibility reasons...)- and this is where a good portion of the fun comes from. All the high-level stuff ending up using the "wrong" edges for a given user's config- and it differs from each user's system as to what precisely that is within the context of PA.

As I've said...slapping a wrapper on top of a broken interface doesn't make for it working better.

Yes. You have to have viable underpinnings for any wrapper to have some hope. These can be fixed however.

[mugginz]

As an aside: I have to reboot my quad-core machine I develop on periodically to get sound to work right. PA just packs it up and leaves the interfaces in such a state that I can't always get audio back. Regardless of the fact that it might be a driver problem (How? It's a typical HDA codec that others have...) the fact that sound just simply QUITS WORKING, should hammer home that we still don't have it right yet- even if PA's the answer.

I've had to restart the Pusle daemon a couple of times to get sound back. It's also a quad core with HDA. Maybe there's something there? While Pulse may not be perfect in my opinion it's less nonpefect than the current alternatives.

[drag]

More the framework above them. Drag's right in that we've got a mess and people missed the scope of the problem in their attempt to make ALSA what it is today. All I know is that it DOESN'T WORK the way we're all trying to do it.

Perhaps it's that we're still trying to push ALSA through PA- I've been led to believe most of the issues vanish if you go directly to PA's own API. Unfortunately, most everyone's using it as a wrapper to OSS and ALSA- which is where many of the woes with the whole thing come into play.

Perhaps PA is the right answer as long as you move to it as your API.

Yeah. OSS over PA is shit. But OSS over anything is shit.

Alsa is 'ok'-ish. It depends on the App and how much of Alsa they use. You don't get the full benefits from PA, though. (like if the application supports PA it'll remember the mixer settings, but won't if it's using Alsa. Also for some apps, like browsers plugins, they create a new alsa interface every time they are meet a new video or game or whatever)


The solution is for Application-level type programmer is to ignore PA/Alsa/OSS altogether.

You just use whatever audio library that works for your type of application.

You program in SDL or OpenAL or whatever. That way you benefit from the expertise and shared experience that the library developers have built up. All these audio libraries support PA nowadays.

Also you gain a lot of portability. SDL audio will work well enough across OS X, Windows, Linux, FreeBSD, Solaris, Haiku... etc etc.

If you target OSS you only can run your application on FreeBSD or Solaris. If you target Alsa you can only run your application on Linux. If you target Pulseaudio you can only run your application on Freebsd/solaris/Linux (even though PA is portable to Windows and OS X both of those systems already have their own PA-style audio servers)

That sort of thing.

[drag]

As an aside: I have to reboot my quad-core machine I develop on periodically to get sound to work right. PA just packs it up and leaves the interfaces in such a state that I can't always get audio back. Regardless of the fact that it might be a driver problem (How? It's a typical HDA codec that others have...) the fact that sound just simply QUITS WORKING, should hammer home that we still don't have it right yet- even if PA's the answer.

The HDA 'standardization' is anything but. Pretty much every device is different in some manner. Alsa should detect these and load up the Intel-HDA stuff with the correct configuration, but it does not always get it right.

That could be a problem, but I bet it's a issue with PA.

Newer versions of PA have added the ability to configure the outputs on your video card, (and when it works) it effectively eliminates the need to ever use any other mixer interface.

You know.. configure external Mic vs internel Mic, digital out, 4-speaker surround sound, 7.1 surround sound, etc.

So it's probably configuring something like that wrong or something bizzare like that.

Keep in mind, also, that some cards were never able to be practically configured through something like alsamixer. Before PA I would have to use a special card-specific mixer application to configure my Audiophile 24/96; for example.