Google Chrome/Chromium Now Supports PulseAudio

[delan]

There is a active movement to get rid of OSS support in Linux. The reason, of course, is that OSS is terrible.

While I would not like to turn this into Linux audio debate #1e100, I would like to hear your thoughts on why OSS is "terrible", because I think that your opinion, which is sadly shared by many people, seems ill-founded. I have been using both ALSA and OSS (versions 3 and 4) for years now, and they are now both solid audio systems from my experience.

While OSS 3 lacked much functionality (the most pertinent being a lack of software mixing) and botched its licensing, and could unanimously be described as "terrible", OSS 4 has made advances to the point where referring to it as "terrible" is debatable, but this doesn't seem to happen because too many people jump on the "OSS hate bandwagon". OSS 4 is certainly still missing some important features, and this makes it not suitable for everyone, including power management and MIDI support. However, personally, I think that the "OSS is terrible" line is long expired, because the age-old criticisms of OSS have been rectified.

[drag]

While I would not like to turn this into Linux audio debate #1e100, I would like to hear your thoughts on why OSS is "terrible", because I think that your opinion, which is sadly shared by many people, seems ill-founded..

OSS3 was terrible, as you say. When Linux moved away from it; OSS4 at the time was proprietary. The drivers were closed source for many things and the open source ones were relatively crippled. Development on Alsa started in 1998 or so. OSS4 remained proprietary until 2007. So since it's silly to maintain 2 entirely separate drivers for the same type of hardware the OSS versions that Linux uses will always be moribund in suckitude. The biggest problem from a user standpoint is that OSS3 would not support more then one audio noise at a time. OSS4 fixes this, but it's too little too late.

Besides that OSS is stuck with POSIX file-based semantics. The OSS advocates point to this as 'Simple and Well documented' API and tries to make it out as a good thing... but it's not. Simple is good, but audio stuff is not simple. It is fiendishly complicated.

I have been using both ALSA and OSS (versions 3 and 4) for years now, and they are now both solid audio systems from my experience.

Then your requirements are low and/or you have a very high tolerance for micro-managing your audio system.

[delan]

OSS3 was terrible, as you say. When Linux moved away from it; OSS4 at the time was proprietary. The drivers were closed source for many things and the open source ones were relatively crippled. Development on Alsa started in 1998 or so. OSS4 remained proprietary until 2007. So since it's silly to maintain 2 entirely separate drivers for the same type of hardware the OSS versions that Linux uses will always be moribund in suckitude. The biggest problem from a user standpoint is that OSS3 would not support more then one audio noise at a time. OSS4 fixes this, but it's too little too late.

I am unsure if you are confusing the crippled version of "OSS" that is included in the main Linux kernel tree, and the real, actively developed version of OSS. In any case, I am aware of the licensing history and how ALSA came about; but this is irrelevant today as OSS is open source.

Besides that OSS is stuck with POSIX file-based semantics. The OSS advocates point to this as 'Simple and Well documented' API and tries to make it out as a good thing... but it's not. Simple is good, but audio stuff is not simple. It is fiendishly complicated.

This is the only attempt of yours so far at making a statement about a drawback of OSS as it exists today. However, your statement is incomplete. While you say that "audio stuff is not simple", this doesn't automatically imply that an audio implementation must also be "not simple". OSS's use of POSIX file-based semantics (as your negatively-loaded statement describes that "OSS is stuck with") has not presented any drawbacks, and works well, in fact. Could you care to elaborate on why POSIX file-based semantics are inherently bad as you describe, in a way other than "Audio is not simple. File-based I/O is simple. Therefore, they are a bad match."?

Then your requirements are low and/or you have a very high tolerance for micro-managing your audio system.

Please do not make false assumptions about how I use audio. While I am certainly not a professional user of audio, I am also not the typical green and pink user either. In addition to this, I don't see myself micro-managing my audio; it works flawlessly and is easy for me to control.

[drag]

Well I could not use OSS even if I wanted to. Lets put it that way. I use USB and Bluetooth audio devices. Bluetooth support is non-existent and USB audio support is extremely sub-par.


So. This is a gaming website.... When I play games with friends over the internet they like to use Mumble. It's a fantastic little VoIP app for gamers.

USB headsets for gamers is extremely common. That way it's easy to separate your VoIP traffic from your gaming and music stuff. It's convenient. There are some very fancy headsets... stuff with surround sound and weird crap like that. Plus with the USB standard you can have a extension cord up to 5 meters so you can have a absurdly long connection. And if you put your computer under your desk all you need is to stick a USB hub on your desk and you can plug your headphones in to that when ever you feel like it.

So with PA I can do things like:
1. Start up Mumble, wait for people to start getting online.
2. When I hear people talking, I plug in my headset.
3. Go to audio applet -- > sound settings --> output device headphones/input device headphones
4. Start up the game and start playing.


It's nice, simple, fast, and it 'just works'.

With OSS that is not something I could do. With Alsa it would require editing asoundrc and changing the default audio device or individually reconfiguring each audio application to use the new audio output. Either way I would be fumbling around and restarting the apps or testing things as I am trying to get going and just looking kinda stupid.

[delan]

Well I could not use OSS even if I wanted to. Lets put it that way. I use USB and Bluetooth audio devices. Bluetooth support is non-existent and USB audio support is extremely sub-par.

Lack of proper USB and Bluetooth audio support is certainly a drawback of OSS, and I am not denying this. I feel disappointed that Hannu doesn't have the resources necessary to develop OSS full-time; if he did, we would probably have had these features in OSS for years already.

So. This is a gaming website....

I didn't know that.

When I play games with friends over the internet they like to use Mumble. It's a fantastic little VoIP app for gamers.

USB headsets for gamers is extremely common. That way it's easy to separate your VoIP traffic from your gaming and music stuff. It's convenient. There are some very fancy headsets... stuff with surround sound and weird crap like that. Plus with the USB standard you can have a extension cord up to 5 meters so you can have a absurdly long connection. And if you put your computer under your desk all you need is to stick a USB hub on your desk and you can plug your headphones in to that when ever you feel like it.

So with PA I can do things like:
1. Start up Mumble, wait for people to start getting online.
2. When I hear people talking, I plug in my headset.
3. Go to audio applet -- > sound settings --> output device headphones/input device headphones
4. Start up the game and start playing.


It's nice, simple, fast, and it 'just works'.

With OSS that is not something I could do. With Alsa it would require editing asoundrc and changing the default audio device or individually reconfiguring each audio application to use the new audio output. Either way I would be fumbling around and restarting the apps or testing things as I am trying to get going and just looking kinda stupid.

OSS can do this easily by itself.

I'd have to admit that I have a gripe with PulseAudio; I've had more time with it breaking than with it working. Its main developer Lennart Poettering is very arrogant, and his section on OSS in his Guide to Sound APIs is completely inaccurate and FUD at almost every sentence:

The Open Sound System is a low-level PCM API supported by a variety of Unixes including Linux. It started out as the standard Linux audio system and is supported on current Linux kernels in the API version 3 as OSS3. OSS3 is considered obsolete and has been fully replaced by ALSA. A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions. The OSS API is very low-level, based around direct kernel interfacing using ioctl()s. It it is hence awkward to use and can practically not be virtualized for usage on non-kernel audio systems like sound servers (such as PulseAudio) or user-space sound drivers (such as Bluetooth or FireWire audio). OSS3's timing model cannot properly be mapped to software sound servers at all, and is also problematic on non-PCI hardware such as USB audio. Also, OSS does not do sample type conversion, remapping or resampling if necessary. This means that clients that properly want to support OSS need to include a complete set of converters/remappers/resamplers for the case when the hardware does not natively support the requested sampling parameters. With modern sound cards it is very common to support only S32LE samples at 48KHz and nothing else. If an OSS client assumes it can always play back S16LE samples at 44.1KHz it will thus fail. OSS3 is portable to other Unix-like systems, various differences however apply. OSS also doesn't support surround sound and other functionality of modern sounds systems properly. OSS should be considered obsolete and not be used in new applications. ALSA and PulseAudio have limited LD_PRELOAD-based compatibility with OSS.

More specifically, this sentence, which he uses as a cop-out to justify his criticism of OSS 3 to relate to OSS as a whole:

A successor to OSS3 called OSS4 is available but plays virtually no role on Linux and is not supported in standard kernels or by any of the relevant distributions.

The above sentence starts off with an argumentum ad populum, then implies that audio has to be inside the main kernel tree, then concludes with another argumentum ad populum.

Worse still, is this message:

W: module.c: module-oss is deprecated: Please use module-alsa-card instead of module-oss!

Huh? I thought deprecation was when you deprecate one implementation of a feature (in this case, PulseAudio communicating with OSS) in favour of another implementation of the same feature. You don't deprecate a feature in favour of a completely different feature, which, in this case, obviously won't work because I'm not using ALSA.

[Dorsai!]

I am not sure if you realize that PA can not directly be compared to ALSA and OSS.

PA is only a soundserver/abstraction layer that either outputs to ALSA or OSS (or even both at the same time).
Your argument is therefore reduced to the feature lacking driver for USB Audio. USB Audio indeed sucks on OSS.

But there are other (mostly PCI) cards that use OSS to its full potential. With them you have per application volume control, very low latency kernel space mixing (nothing like ~8192 samples as with dmix) and high quality sample rate conversion.

But then Intel HDA (AFAIK the only card that uses PM) has no Power Management in OSS so Notebooks should stick with ALSA. Other than that the HDA driver of OSS is fine and full featured (and supports even things like manually and seperately muting Headphones or internal speakers)

So for (IMHO) crappy gaming usb headsets: ALSA with PA
For Notebooks with Intel HDA: ALSA (PA optionally)
For (supported) HQ PCI Audio: OSS4 (PA optionally but not really any benefit)

On the other hand I dont feel like OSS4 development is going anywhere at the moment. Maybe a reinclusion in the kernel could have prevented that, maybe not.

I for one use ALSA without pulse as only ALSA supports my RME hdsp at the moment whose low latency mixing cappabilities are sufficient for me.

Oh and another downside of OSS I forgot: It does not correctly support ACPI and hibernation. The modules must be unloaded (the oss script for that is fine) and after reactivation be reloaded. That can be automated by script but is a bit annoying.

[drag]

I am unsure if you are confusing the crippled version of "OSS" that is included in the main Linux kernel tree, and the real, actively developed version of OSS. In any case, I am aware of the licensing history and how ALSA came about; but this is irrelevant today as OSS is open source.

I couldn't imagine how it's NOT relevant. If it wasn't for the history then OSS wouldn't be crippled in Linux. The fact that you have to go through a shitload of extra steps and re-compile and/or reconfigure everything in order to use OSS means that it's a huge PITA for anybody wanting to use it.

It is a usability nightmare.

So yeah: If you want to completely ignore all the negative aspects of setting up and using your audio then OSS is not terrible. It is still not going be nearly as good as Alsa or PA, but it is not terrible.

But I am not going to ignore the first step of using OSS is going to be:

Step 1. Break everything in your system related to audio

_that_sucks_

This is the only attempt of yours so far at making a statement about a drawback of OSS. However, your statement is incomplete. While you say that "audio stuff is not simple", this doesn't automatically imply that an audio implementation must also be "not simple". OSS's use of POSIX file-based semantics (as your negatively-loaded statement describes that "OSS is stuck with") has not presented any drawbacks, and works well, in fact. Could you care to elaborate on why POSIX file-based semantics are inherently bad as you describe, in a way other than "Audio is not simple. File-based I/O is simple. Therefore, they are a bad match."?

I could. But it's stupid to post a wall of text into why reading and writing to a file is not adequate for modern audio applications. I mean, seriously, how many people here actually understand the concepts of POSIX file semantics? I would have to go on and explain everything about reads, writes, buffering, and all that crap. It is silly.

POSIX file semantics are:
open( ), close( ), read( ), write( ), ioctl( ), select( ), poll( ), mmap( )

So. When I plug in my USB headset which one of those function calls is going to be used to notify my application that a new audio device has been inserted?
How about buffer control? Which one of those calls is going to be used by a application when it needs to change how the buffers work?
Or how about low latency operation? How is that suppose to work?

The answer is "none of them" and "can't do it" and "It doesn't work".

I mean even for simple applications the file system semantics are not adequate. That is why we have fifos and sockets. Why do people think that reading and writing to a device file is going to be perfectly fine for modern audio systems, but not good enough for your Xterm or your web browser to do even very basic rendering on your display?

Please do not make false assumptions about how I use audio. While I am certainly not a professional user of audio, I am also not the typical green and pink user either. In addition to this, I don't see myself micro-managing my audio; it works flawlessly and is easy for me to control.

I am not making assumptions. When you say things like '""I don't see myself micro-managing my audio; it works flawlessly and is easy for me to control.""" then it's pretty easy to understand that your requirements for audio is not that high. Because if it was you'd find that OSS and Alsa is not going to allow that for anything beyond bog standard stuff.

And it's nothing to do with 'professional audio'. Just stupid-simple stuff like 'Configure the microphone correctly' is a huge pain in the ass and differs from driver to driver and device to device.

I mean seriously. For years and years and years when people bitched and moaned about only being able to play one audio stream at a time the standard answer was:
"It is because your sound card sucks!!!! LOL. Buy one that does hardware mixing and not one of those piece of onboard!"

(Except, of course, hardware mixing stomps all over your audio quality. but don't tell the 'sound blaster' fanboys.)

[delan]

I couldn't imagine how it's NOT relevant. If it wasn't for the history then OSS wouldn't be crippled in Linux. The fact that you have to go through a shitload of extra steps and re-compile and/or reconfigure everything in order to use OSS means that it's a huge PITA for anybody wanting to use it.

It is a usability nightmare.

So yeah: If you want to completely ignore all the negative aspects of setting up and using your audio then OSS is not terrible. It is still not going be nearly as good as Alsa or PA, but it is not terrible.

But I am not going to ignore the first step of using OSS is going to be:

Step 1. Break everything in your system related to audio

_that_sucks_

That's funny. Because in my experience, installing OSS is not hard at all. On Debian, Ubuntu, et al., it's a simple case of removing the PulseAudio and ALSA packages, and installing the oss4-base package, and sound works. Even on Gentoo, which is often lauded as a 'difficult' distro to use, it consists of all of two steps:

1. emerge oss-devel; /etc/init.d/oss start; rc-update add oss
2. add 'oss' to the USE flags of any relevant packages and re-emerge them

[Dorsai!]

OSS is problematic to install only if your alsa soundsystem is hardwired into the kernel. If it is compiled as a module (as in most distros) you are fine. OSS init script does the rest.

It even recompiles the modules by itself if you change to a new kernel. Much less hassle than using nvidia drivers or any other third party kernel module.

[drag]

I call BS.

So all I have to do is:
apt-get install oss4-base

And now my SPDIF-out is all of a sudden going to magically work with all my applications?

It is hilarious how it's easy to paraphrase what you guys are saying as:
"Yeah if you completely ignore everything that needs to be done then it's easy to do."

Just uninstall everything and reinstall it, no problem!