Linux is not ready for Steam

[Kano]

Most HDA Intel devices work for playback, the problem begins when somebody wants to use a mic. This often requires extra options or a bigger patch. Tested module overrides can easyly transfered into kernel/alsa patches.

In the case of mic problems which are not directly solveable using module overrides i usually suggest using a small usb sound adapter - this works with every os. Also nice when you don't have got front audio connectors.

@Svartalf

Did you try to unload driver/apps using alsaconf instead of rebooting? I had curious effects here too, like when i tested audio via hdmi i had to remove power for my monitor - before audio was muted even when the osd showed full volume.

Bluetooth devices heavyly depend on the software stack. Currently alsa can be used to setup those devices directly in the .asoundrc but with an older stack that does not always work reliable. Informer a special alsa module (snd-bt-sco) was used together with btsco (user space) - that basically worked better than the newer direct integration, but most likely using new user space tools should fix those issues. Compared to other headsets you just always have got a delay via bluetooth.

[darkphoenix22]

I have to add that Bluetooth headsets are unreliable on any operating system in my experience. I ditched mine for a USB Headset, which works fine using plain ALSA. I just had to change the output in Xfce Mixer.

Why again do we need a layer of abstraction made default to satisfy these edge cases? If a user needs Bluetooth audio, he is free to install PulseAudio. There is no need for it to be made default, especially if it breaks games.

[mugginz]

I have to add that Bluetooth headsets are unreliable on any operating system in my experience.

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.

I ditched mine for a USB Headset, which works fine using plain ALSA. I just had to change the output in Xfce Mixer.

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

Why again do we need a layer of abstraction made default to satisfy these edge cases? If a user needs Bluetooth audio, he is free to install PulseAudio. There is no need for it to be made default, especially if it breaks games.

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?

[drag]

OK... So bluetooth is a edge case. (which it's not) (And my bluetooth headset is actually reliable in Linux.)

So... even though users are already quite happily using Bluetooth for audio in OS X and in Windows 7 it's just not good enough for Linux to support it without swapping out audio subsystems.

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


Now lets look at USB headphones.

How easy is it to deal with hotplugging audio devices with Alsa or OSSv4?

I know that it basically is nothing but hell to deal with with just Alsa by itself. The idea that I would have to go back to managing multiple asoundrc files and shutting down applications and restarting them each time I want to plug my headphones in is completely unacceptable.


I never used OSSv4 though.

Say I am playing a video game and I want to use something like skype or other voip system to talk to people.

What would I have to do in OSSv4 to make it so that when I plug in my USB headphones that the game continues to play through my speakers, but I can use the mic and headset to talk to my buddies?


Say I am watching a movie on my laptop and my roomate gets all pissy about the noise. What would I have to do, using OSSv4, to change the default audio output from my speakers to the USB headset?

Can I do this on the fly, or do I have to kill my movie first?

[Svartalf]

@Svartalf

Did you try to unload driver/apps using alsaconf instead of rebooting? I had curious effects here too, like when i tested audio via hdmi i had to remove power for my monitor - before audio was muted even when the osd showed full volume.

It wasn't really happy until I rebooted about 1/2-2/3rds the time- so I just restart my machine that shouldn't otherwise need to be rebooted to get sound back (Not that I should HAVE to do what you've suggested, Kano, either...).

This is the reason I'm even discussing any of this as much as anything else. We still don't have it solid like we think we do- for whatever reasons.

[Kano]

Basically you don't need to change the default for every use case. Of course if want all sound redirected you can change the default in .asoundrd. That's basically needed for flash videos in the browser, i did not find an override option for that yet. VLC allows audio device switching on the fly without stopping the media - also nice to switch to hdmi output - so maybe use that in your movie example

[Kano]

@Svartalf

While testing VLC i got this error: "Please update alsa-lib to version 1.0.24 or higher to try to fix this issue." - basically you can update alsa-lib locally, that's what i do in my vlc script. The funny thing about this error is that alsa-lib 1.0.24 has not even a rc yet

[Svartalf]

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

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

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.

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.

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

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.

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.

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...). 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.

[Svartalf]

@Svartalf

While testing VLC i got this error: "Please update alsa-lib to version 1.0.24 or higher to try to fix this issue." - basically you can update alsa-lib locally, that's what i do in my vlc script. The funny thing about this error is that alsa-lib 1.0.24 has not even a rc yet

Nice... Thanks for the tip. I'll check into it.

[Thetargos]

So it all seems to boil down to sound, dunnit?

Sound in Linux is a "problem", depending on how you want to look at the situation. The problem is not a simple one, it is a rather complex mess that has been crated over the years and the many migrations that have occured... What we currently have is the result of that which is a mixed environment and the fact that many of us still run old OSSv3 applications with ALSA, and even though it offers a fallback it cannot offer all its features to OSS applications, paramount to this is that dmix will NOT, and I repeat: dmix will NOT work with OSS streams being parsed to the main ALSA system through the alsa-oss wrapper, period! The end result for the very topic of this particular thread: Older games, unless migrated, will not work properly with ALSA without Pulse, period.

Add to this cunundrum the fact that pretty much all audio hardware in Linux (through ALSA or OSS) works at the hardware level with only ONE stream, and we have what we currently have in the Linux scene, a mess. The mixed environment is the main difficulty that has to be overcome... And many will still want to run the older applications (even closed applications) on their new systems and get frustrated because they don't work... HELL there are still some poeple running libc5 (yes, five) applications, and it's been over 11 years since the libc wreck, not to mention the gcc2.95 issues and the list goes on and on... It seems these kind of problems have been inherent to Linux' evolution.

The idea behind PulseAudio or a sound system is not alien to the "other" operating systems either. The Windows Sound System is exactly a sound server that mixes streams and stands between the applications and the drivers. The only difference, IIRC is that in the case of the DirectX drivers, DirectSound also functioned as a server or something to that end. In the MacOS side of things CoreAudio is the one responsible for the same thing, however in the case of MacOS the line seems to be a bit more blury between the sound system (server) and the actual drivers, much like is the case in the Linux camp with OSS and ALSA and aRts, ESD, Pulse, etc. However, I do know that CoreAudio actually consists of two parts, one being the sound server, and the other the collection of drivers.

The heterogenity of user experience in the case of Audio on Linux and particularly Audio on the Linux Desktop virtually boils down to two things: Different degrees of support for hardware (some cards supporting hardware mixing, others that are capable not being supported, and many not offering it) and mixed userland and application sound system support: Virtually all sound producing applications support OSS as a fallback, and there are still many applications that do not support ALSA. ALSA supports OSS through a wrapper (yes!, the fun never ends!), but this wrapper does not play well with other ALSA plugins (read, dmix). Hence a middle-ware has been developed, one which is actually part of the actual sound system (and to some degree ALSA and OSS provide) in the other OSes, and yet again had to be developed as a plug-to-a-hole in Linux, only better engineered this time, PulseAudio.

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**)

Individual hardware idiosyncracies only add to the cunundrum and can actually explain the varying degrees of support under ALSA.

**Such as single-stream hardware like the ubiquitous HDA , limited stream hardware (VIA82xx and others, which support from 2 to 4 HW streams) and extended stream support for robust hardware such as EMU10k1/2 chipsets (which support up to 32 streams, 24 usable by ALSA).