Linux is not ready for Steam

[darkphoenix22]

I found Windows to be quite nice with bluetooth headsets. I will say though that some of the cheaper bluetooth dongles come with some appalling software but the Microsoft native stuff is pretty good.

This was with the Microsoft native drivers. I had to do an elaborate dance of pairing my headset with the computer everytime I wanted to use it. And god help me if it somehow decided to pair with my cell phone.

How easily did you configure ALSA to play with your bluetooth headset?

I never bothered. But the issues above applied to Mac OS X as well.

The sign of a mature system is the ability to deal with both mandatory as well as other non-core but nice features.

Person A - "But I can't get sound to work with my bluetooth headset...."
Person B - "Oh you're one of those strange people that want to do something that's not normal sound playback. Go read this FAQ and add that patch and edit these config files and then reboot. Now when you want to go back, edit this config and execute that shell command"

Isn't it time to get past just providing the simplest of sound support and also allow people to be able to depend on other more modern things as well. Do we need to remain the "Soviet Era" of multimedia for ever?

How many people have bluetooth headsets? Now, how many people play games?

As the subsets of users who will play games is much higher than those who will use Bluetooth headsets, they come first in terms of defaults. With the people with Bluetooth headsets having the option to install PulseAudio on their own.

[darkphoenix22]

Now, I do not believe Pulse is a bad thing as such, but one of two things should happen:

• Either merge Pulse into ALSA or
• Simplify ALSA to the point that Pulse will do all the heavy lifting...

There would be one other option: Make an ALSA plugin as simple to interact with as Pulse (and make it blazing fast and efficient at soft-mixing for those cases needed**)

I agree with this. However, I would to see an analysis of how much work either of your presented options will take.

Right now, I think etiher of your presented opinions weel take much more works then just improving OSSv4. I also question whether either path will have the ability to maintain ABI stabily with the current implementations of ALSA. Most applications are already compatible with OSSv4 via the OSSv3 fallbacks.

[mugginz]

How many people have bluetooth headsets? Now, how many people play games?

As the subsets of users who will play games is much higher than those who will use Bluetooth headsets, they come first in terms of defaults. With the people with Bluetooth headsets having the option to install PulseAudio on their own.

Rubbish. It's 2010. Linux needs to support both.

[mugginz]

I also question whether either path will have the ability to maintain ABI stabily with the current implementations of ALSA. Most applications are already compatible with OSSv4 via the OSSv3 fallbacks.

PA has OSS support also.

[drag]

Sadly, that's not as easy as you're making it out to be.



Okay... Let's go through what edges are supported with the popular API edges, shall we?

SDL : OSS, ALSA, PA
OpenAL : OSS, ALSA, PA
FMOD : OSS, ALSA, ESD
FMOD Ex : OSS, ALSA, PA
IrrKlang : ALSA
Miles : OpenAL (?)

So, if your game uses FMOD classic (and there's quite a few that do...) you're out of luck. Ditto if you're using IrrKlang. Either we need to be better about educating the middleware crowd about PA, or we're going to have to find cleaner answers for the low-level access APIs.

Yeah. It's to bad we can't fix obsolete proprietary libraries. But fmod has always seemed to have been a problem for me. It's been a while since I've ran across any sort of need to ever install it.

But either way you'd still have to agree that from a game designer's point of view that having to write a entirely new audio structure on top of Alsa is undesirable when it's extremely likely that Linux is going to remain a tiny percentage of potential users/customers.

Choosing a library that is portable to Windows and OS X is going to be a big advantage.

Yeah, and it also has some...interesting...quirks about playback when you use SDL_mixer against PA and no real 3D sound support. OpenAL with some higher-level library support would probably be better as a choice if you're implementing something. I'd had high hopes for cAudio, but trying to use 2.X hasn't panned out as planned. OpenAL's nice as a mid-level API- but it is too clumsy for use as a sole framework by itself.

Well SDL has the advantage that your probably already depending on it for a lot of features for displaying 2D (and possibly 3d, although I expect most engines would target OpenGL) and for dealing with input controls (keyboard, joystick, mice). So using it for Audio is a nice move.

OpenAL sounds like it's something that you'd only want to use for bigger games were audio is part of the gameplay. In that case I expect that your moing into the realm of 'Game Engines' were the average game author is just purchasing or using a engine made by another team. After all people would much rather be spending hours/money making the actual game then programming in OpenGL or DirectX.

Plus you have Creative trying to push OpenAL support for Windows as a alternative to no-hardware-acceleration-allowing audio system used in Windows 7 and Vista. Audio hardware acceleration is completely dubious, at best, but at least you'll know the support is going to be there for OpenAL from Creative.

(but I suppose given Creative's track record this may be a minus)

Actually, if you target OSS, you can get BSD, Solaris, AND Linux (either through OSSv4 being installed or the varying OSS support options- albeit that some configs won't work right that way...).

No I don't think that targeting OSS would help out much for Linux at all.

OSS support in Linux sucks REALLY BAD, at best. It's a complete usability nightmware. CUSE + PA would probably give the highest level of support you'd ever hope to see except for the very tiny minority of users (like 1 in thousand) that are crazy enough to actually bother installing OSSv4 drivers in Linux.

Hell, for my purposes CUSE + PA would be superior then just using OSSv4 if I cared about OSS compatiblity since that would mean I would not have to abandon the sleep/hibernate capabilities of my laptop.

(and no, killing all my applications so I can turn OSS off before suspending is not acceptable)

Plus... as a game designer.. do you really care that much about FreeBSD or Solaris? I think that the people that hack on those systems only rarely use them on the desktop, preferring OS X or Windows.

I would expect for a people like Valve or other game makers that Windows, OS X, and Linux would be the priorities (in that order). OSS really does not get you any advantages if that is true.

Unless in some distant future OSSv5 takes over Linux, which is extremely unlikely. The Linux folks would essentially require OSS folks to reengineer their APIs to suit Linux driver requirements. Who do you think would budge first?

If you target ALSA, you're right- it's only Linux. Does *BSD and OpenSolaris support PA? Does PA run atop OSS or ALSA drivers then? If not, you just negated the remark- as *BSD and OpenSolaris/Solaris use OSS from my recollections of things.

Yeah. Pulse Audio supports OSS. It's designed to be portable.

http://www.freebsdsoftware.org/audio/pulseaudio.html

Although I doubt that you'll get all the features you get in Linux. (simply because they simply don't exist in other *nix systems.)

http://www.pulseaudio.org/wiki/AboutPulseAudio#SupportedOperatingSystems

Linux, NetBSD, FreeBSD, Solaris, and Win32 are officially supported systems. I've seen people trying to get it working on OS X for some bizzare reason, too.

I still don't think it's terribly useful as a portability solution since Windows Vista/7 and OS X already have perfectly good audio services.

---------------------------

BTW, OS X's Core Audio is generally regarded as a superior solution to what other OSes currently offer.

It uses a daemon, Coreaudiod. Capable of very good performance from what I hear.

http://www.manpagez.com/man/8/coreaudiod/

[darkphoenix22]

Rubbish. It's 2010. Linux needs to support both.

Sure, but I'm going to support *games* first.

[mugginz]

Sure, but I'm going to support *games* first.

But your solution is to first remove support for bluetooth and then at some stage in the future re-instate it with patches to ALSA.

What's wrong with patching Pulse or middleware such as SDL, OpenAL, etc and leaving support for bluetooth there for those who need it?

[drag]

I agree with this. However, I would to see an analysis of how much work either of your presented options will take.

Right now, I think etiher of your presented opinions weel take much more works then just improving OSSv4. I also question whether either path will have the ability to maintain ABI stabily with the current implementations of ALSA. Most applications are already compatible with OSSv4 via the OSSv3 fallbacks.

Alsa is not too bad in this way and PA already supports backwards compatibility about as well as your ever going to see it.

Applications use alsa-lib so you can change that to do whatever you want as long as you maintain the API/ABIs.

Plus Alsa has that nice feature were you use plugins and it's all configurable from user interface.

Like, I am sure everybody is familar with 'Dmix' plugin. It's a little plugin that creates a simplistic (and crappy sounding) software mixer in userspace that sits between the application and the hardware.

Well "pulse" plugin is all you need for backwards compatibility, generally.

Technically it's possible to run alsa-lib on other systems, too... like OSS and Win32 (not that anybody gives a crap)

Of course using the alsa pulse plugin prevents applications from taking full advantage of features that PA introduces.

OSS, in comparison, is a much bigger headache.

It has that really crappy design were applications can read/write directly to character devices. (The POSIX-style "read/write one character at a time" API is a really bad match for what you need for proper audio support)

The best way to achieve compatibility with that is through the CUSE+PA approach.

Ever use FUSE file systems like GVFS-fuse, sshfs, or ntfs3g (fuse version)? Similar in concept, but for character devices.

That way you can get OSS compatibility without all the hacks.

[Mo6eB]

Careful there. Ubuntu LTS isn't the whole sum of Linux. You've just tripped yourself up if you're trying to provide a commercial game or similar. No, you're not going to be able to support every system- but your thinking you're espousing isn't the answer either.

I just meant it as "support the most popular desktop Linux and don't worry too much about niche distros". For instance, I would never attempt to support every possible Arch or Gentoo install. That would be a nightmare. Supporting the one or two most popular desktop distros gives you most of the user base and a stable (as in, not endlessly configurable) system to support.

More to the point I'm getting to here, the BULK of the potential userspace aren't hardcore tech geeks. They just want to have it drop in and work. Heck, I don't have the time to tinker around like you're implying or to wait for someone else to do it for me- it'd better mostly work out of box.

From all the Linux users I know, not one of us expects things to just work out of the box. We sure wish they did, but we don't expect them to. I do see what you're saying with the lack of time, though. Even if we know there's a good chance we'll have to fiddle around, it's still not good user experience to have to investigate or wait around for somebody to fix whatever problem prevents us from playing. I'm just arguing that it's not a significantly worse user experience than what most Linux users have already. Though, I must admit, a lot of stuff does work out of the box. I am still amazed by it .

And with PulseAudio, it DOESN'T. Raw ALSA or OSS often does better with things than PA does- now the claims of poor implementation and execution on the part of the distributions (Ubuntu, by the by, was one of the guilty parties there...) may be legit, but it implies there's some complexity we don't need.

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.

I feel really dirty trying to defend PulseAudio. I specifically run kubuntu, because it left PA out of the default install. After 10.04 however, there was no way to have kubuntu without it and I didn't feel like changing distros. Fortunately it now works for me, doesn't introduce latency that I can hear and doesn't take 20% CPU just idling. I wish somebody would sit down and measure the audio latency with current PA. I don't notice any latency when playing Quake Live or StarCraft, though; and I'm running StarCraft in VirtualBox.

Also, PA doesn't sit on top of everything else. It talks directly to the ALSA hardware device, meaning no buffering, no resampling, no mixing, just access to the hardware through a single API. If you don't run PA and open the ALSA default device, that gives you a plugin stack which does user-space mixing (dmix) and resampling and introduces latency. Opening the hw device yourself isn't an option, because most of them don't support mixing, so you'll be blocked out. If I remember correctly, Windows also does userspace mixing and per-app volume control and Microsoft care about games. If it was impossible to implement sanely, they wouldn't have done it. I do remember Creative being very pissed about it, but it doesn't seem anybody really cared.

[drag]

Here is the osspd stuff. This program works with Linux kernel's CUSE support to create /dev/dsp and other character devices needed for OSS compatibility.

http://userweb.kernel.org/~tj/ossp/

This should allow proper OSS compatibility in Linux and PulseAudio without all the ld_preload hacks and that sort of thing.

You need to have CUSE support in your kernel (I think it made it in with 2.6.31) and you need to have a version of Fuse libraries that support CUSE (which I do not have, unfortunately).