Google Chrome/Chromium Now Supports PulseAudio

[delan]

Yeah. I don't know why I (or anybody else) would care about OSS output support for PA in Linux (PA over OSS) when I can use Alsa drivers for setting up my hardware and have something much better (PA over Alsa).

Well, for a start, the people that would care about good OSS support in PulseAudio are those that use OSS, either because they like it (like me; ALSA works on my hardware, but I prefer OSS), or because OSS is the only sound system that has working drivers for their hardware (believe it or not, many dedicated PCI sound cards have poor support from ALSA but work flawlessly with OSS).

All in all, your arguments against OSS have been pretty irrational thus far and read a lot like fanboy-speak.

[liam]

That's the point. It makes things easy to use.

It supports all the hardware that is possible for Linux to support at this time. It supports all the configurations that is needed for desktop audio. You don't have to go out and ditch your hardware that works perfectly well in any other OS. You don't have to memorize the specific alsamixer settings for your stuff to work. You don't need arcane knowledge of drivers and configuration utilities with different documentation or anything like that. No editing of text files.

_thats_the_point_.

It does what is needed to be done.

Well, I DID say I wasn't arguing with you

My only point was that those particular issues seem like they could be resolved inside of POSIX.
Other than that, I agree.

[Dorsai!]

Well, for a start, the people that would care about good OSS support in PulseAudio are those that use OSS, either because they like it (like me; ALSA works on my hardware, but I prefer OSS), or because OSS is the only sound system that has working drivers for their hardware (believe it or not, many dedicated PCI sound cards have poor support from ALSA but work flawlessly with OSS).

All in all, your arguments against OSS have been pretty irrational thus far and read a lot like fanboy-speak.

You forgot to mention the people on BSD or Solaris (not that they are so large in numbers). ALSA ist still a Linux only driver. Even if those people do not use OSS4 their native OS Sound drivers use the OSS API.

[delan]

You forgot to mention the people on BSD or Solaris (not that they are so large in numbers). ALSA ist still a Linux only driver. Even if those people do not use OSS4 their native OS Sound drivers use the OSS API.

This is also true; thank you for reminding me of that fact.

In any case, I will stop arguing about the whole OSS vs. ALSA thing; it is off-topic in this thread and will only serve to annoy those who came to this thread to read about Google Chrome and PulseAudio.

On-topic: I would like to see OSS support in Google Chrome/Chromium, as well as Firefox. Having no OSS support pretty much breaks native audio in both browsers for me.

[drag]

Well, I DID say I wasn't arguing with you

My only point was that those particular issues seem like they could be resolved inside of POSIX.
Other than that, I agree.

Sure sure. I was agreeing with you.

[drag]

All in all, your arguments against OSS have been pretty irrational thus far and read a lot like fanboy-speak.

I am the fanboy? FFS man.

You point out that OSS is far from a acceptable solution for a huge number of cases. You can't even use it yourself. It's power management is non-existent, etc etc.

Your defense of your position rests entirely on statements like:
"Because that is what I prefer"
"(IMHO) crappy USB headsets"

and so on and so forth.

The only point that you brought up that has any valid defence of the continued existence of OSS in Linux is that there are certain specific PCI devices that are supported poorly by their Alsa drivers.

The solution to that is NOT to require anybody that touches the Linux audio stack from the highest level application to the bottom level developer to support OSS in the off chance that a one or two users may run into a subpar Alsa driver. The solution to that is to fix the stupid Alsa Linux drivers so they work. Far less effort, far better results. Much more consistent, easier to document, easier to avoid bugs in the future, easier to support long-term.


-------

As far as portability is concerned; The only operating system that remotely matters for desktop or gaming audio that uses OSS is FreeBSD. Solaris is just pure irrelevance right out of the gate and ever since Oracle bought it up it it's dead in the water.

The operating systems that actually matter in terms of portability are going to be FreeBSD, Linux, OS X, and Windows. Only one of them actually uses OSS for anything. (Sure OSS supports Linux to a certain extent, but it's not available and never will be used by the vast majority of users.) If you are caring about a portable solution attacking the problem at the low-level kernel interface is not going to yield good results.

Even using PA for portability is bad news. Not because PA is not portable, but because Windows and OS X already have their own sound servers that meet or exceed the capabilities of PA. Having PA on them is redundant.

For what is required for a modern desktop audio you _must_ have a sound server of some type. You absolutely need something that provides central management of mixers, central configuration of devices, power management, timing, correct buffering of audio, routing of audio. You need something that provides a consistent interface user-friendly interface for not only users, but application developers. Interfaces and controls that are not going to change based on what hardware you happen to be running at the time or what output you want to use.

Windows has had it few different attempts to get audio right. It was completely re-done from the ground up for Windows Vista and Windows 7 which massively improved the usability and capabilities of that OS. The OS X sound servers have been around for ages and have provided a consistent audio stack that not only is user-friendly and supports a wide range of devices, but meets the needs of professional audio.

Linux needs those similar capabilities as does FreeBSD (or any other OS). You are not going to achieve it by having multiple redundant audio stacks in Linux... all of which are broken in different ways and none of them have a fraction of the capabilities of any other modern OS and then force users to choose and force developers to support all possible combinations.

[drag]

On-topic: I would like to see OSS support in Google Chrome/Chromium, as well as Firefox. Having no OSS support pretty much breaks native audio in both browsers for me.

It seems like they are not interested.
http://code.google.com/p/chromium/is...etail?id=19470

Same thing for Jack
http://code.google.com/p/chromium/is...etail?id=42458

For FreeBSD it looks like they just use the Alsa libs
http://code.google.com/p/chromium/is...etail?id=36008

[h**2]

What is all that stuff you always have to do on Linux with your audio? As a FreeBSD user I never had to worry about audio, it just worked, a simple native implementation that offers OSS interface to all applications.

Now every UNIX audio implementation other than ALSA implemented the OSS interface, but of course back then that must have been the right thing to do since ALSA was much superior... oh wait, now we are fixing ALSA because its broken. And we are doing that by yet another layer of abstraction! So e.g. KDE applications now work this way
APP -> Phonon -> Pulse -> ALSA -> Kernel

X-points of failure and breakage, no wonder its a pain to set up.

This is modern computing I guess. But of course everything is going to be better now. Then again it must have been really bad on Linux back than, since it sure sucks now. And because of Linux "progress" everything is starting to break everywhere else now aswell. Talking on-topic I have to pipe Chromium audio through some virtual ALSA foo just to make it work on FreeBSD or ArchLinux with OSS. I am really looking forward to the times where other folks have to write pa-wrappers around alsa-wrappers for an interaface that used to be shared by all (OSS).


P.S: Sorry for the rant. I am not anti-Linux (in fact Linux is better than FreeBSD for a lot of things). I just don't understand how an OS with such a large developer base cannot produce something simple, that just works. While all other smaller *nixes somehow managed.

[blackshard]

No. It's not a abstraction layer. It's a sound server.

And yes it can actually improve performance. Everything PA does is needed to be done. There is no free lunch here. You need to perform sound mixing somewhere, you need to have accurate timings. You need something to manage your sound devices, etc etc. You can do it through a combination of application logic and driver logic, or you can separate that stuff off and handle it centrally by a program that is designed specifically to solve these problems.

(meaning it can improve performance because it does a better job)

It IS an abstraction layer since offers high level functions (software mixing, realtime resampling, filtering, etc...) using lower level functions (offered by ALSA).

Another by definition adds complexity to the system, it can't simply "improve performance". There were (and still there are) many laments from people about cpu power usage from pulseaudio, mostly coming from the resampler in a standard and plain out-of-the-box configuration.

It can't improve performance, instead it can offer added services but can't do that without using more power.

Well maybe that is something you can fix if you think that SIMD can help with those filters.

Sure they can, the fact is that they require a lot of work since SIMD aren't exactly easy to manager. And also the resampler chosen by default is heavy enough to let people complain.

Anyways it only performs remixing if it has to.

Got a example?

I set my default output stream to 44100 Hz, 16 bit stereo.
Set my PA resampler to src-linear
I played a 44100 Hz 16 bit stereo stream and watched cpu usage from pulseaudio.
Then I set my PA resampler to copy
Played the same stream as above and cpu usage was lower.

It's not a proof, but indeed is a hint.

[daedaluz]

I'm Opera user so obviously I hadn't noticed something missing since I've never installed Chromium, but this got me curious. I thought that obviously a modern browser supports Pulse. Now I started wondering, does FF and Opera support Pulse after all?