Google Chrome/Chromium Now Supports PulseAudio

[mirv]

Well, as I said, he may have other issues with it - but all that aside, he's probably not going to use pulse for the same reason that I refuse to put it on my systems: no need. Everything is working fine for myself without it, so there's no reason to use it. And I'm sure people will take that statement the wrong way, but I really only mean that whether it's good or bad doesn't matter to some people - it's just that there's no reason for them to use it because it doesn't offer anything for them.

[RealNC]

This fanboy war is a joke!

Your opinion is a joke too.

OSS is far behind Alsa in implementation because of its previous licensing. This is why such a project should be dropped

What? Previous licensing is the reason projects should be dropped? Where do *you* come from?

the reason why some cards that don't work on Alsa work on OSS is due to the hardware manufacturers preferring the closed licence.

The what? The closed GPL license? Where can I find that?

We only need one hardware interface to the audio and it should be Alsa.

You understand that the ALSA API is the ugliest thing the kernel devs every created, right? It's one of those things that make Microsoft make fun of Linux rather than vice versa. I urge you to go write an audio player in ALSA and one in OSS. Only that way can someone really know first hand the brain damage in ALSA's API.

[danwood76]

Actually reading what I said would help. I was saying that its far behind Alsa so it should be dropped.
Its behind because some moron thought they could make money from it but oh wait it failed! It should be dropped because it is behind in terms of features compared to Alsa.

A few years ago it wasn't GPL. That was around the time I got a card that required OSS4, it was a horrible closed blob and never touched my system. I ended up selling the card and continuing to use my onboard Intel.

I have written an audio output driver for a university project and tried ALSA, OSS, and then Pulse and to be honest Pulse seemed the easiest and most versitile with regards to defining output parameters so I ended up using it. Alsa was a pain as was OSS mainly because a lot of the docs I found were outdated and so I had to use examples from other software projects to even get sound out.

I've never heard of M$ making fun of Alsa maybe you are living in OSS fanboy land too long!

[ceage]

Your opinion is a joke too.


What? Previous licensing is the reason projects should be dropped? Where do *you* come from?


The what? The closed GPL license? Where can I find that?

Huh? It's not closed. It just takes away the very specific freedom to take four other very specific freedoms away because that would not increase the overall amount of freedom that there is in practice, with regard to free software development. So that would negate it's own purpose and make it a comletely redundant license. One get's the security of copylefted code in return, so it's quid pro quo.

You understand that the ALSA API is the ugliest thing the kernel devs every created, right? It's one of those things that make Microsoft make fun of Linux rather than vice versa. I urge you to go write an audio player in ALSA and one in OSS. Only that way can someone really know first hand the brain damage in ALSA's API.

ALSA was neither designed to be particularly beautiful nor to be used by application developers. It's a low level API designed to make hardware accessible from user space in a way that allows someone else to do everything audio related that can possibly be done. Someone. Like a (modular) sound server. Like PulseAudio.

So ALSA is doing exactly what a kernel subsystem is supposed to do. So does Pulseaudio. Application developers wrote for ALSA in the past only because it was the safest bet among the two million different APIs on Linux.

[RealNC]

Huh? It's not closed. It just takes away the very specific freedom to take four other very specific freedoms away because that would not increase the overall amount of freedom that there is in practice, with regard to free software development. So that would negate it's own purpose and make it a comletely redundant license. One get's the security of copylefted code in return, so it's quid pro quo.

I didn't understand even a singe phrase here. Maybe I'm dense, but what do you mean?

ALSA was neither designed to be particularly beautiful nor to be used by application developers.

I'd be thankful if you could provide a few references for this statement. Sounds rather interesting and I'd like to look it up.

Incidentally, the whole thing sounds like the Direct 3D (pre-10) vs OpenGL thing. Where people said D3D sucks because it's not cross-platform, has ugly API, results in vendor lock-in, all that stuff. Now if you replace D3D with ALSA and OpenGL with OSS, all those arguments are still the same. Yet, this time ALSA is better.

Linux users. Go figure :-P

[F.Ultra]

Your argument is $WORKING_APP doesn't do sound properly on $NEW_SOUND_SYSTEM, so it's the problem of the $WORKING_APP and they all should convert to the $NEW_SOUND_SYSTEM. Yeah gotcha. How about the $NEW_SOUND_SYSTEM work with existing apps instead of forcing everyone to accomodate it.

AFAIK the PA team has gone down that very road, but sometimes it's not possible to accomodate 100% of the old applications/usage scenarios without some breakage. The main problem was that the old sound system in Linux was a broken mess (there is some chart over the insane situation by the Adobe flash team somewhere on the Internet if you are interested in just how insane that previous world was) and with PA we at last get a good nice and clean sound system for Linux. If you are a programmer then you probably understand why it might be an enormous task of fitting that old insane world into the new system without some breakage.

And it might also be that those applications that still doesn't work hasn't been brought to the PA team's attention, or they might already be solved by wrapping them with padsp. And PA solved problems for the desktop, it might not solve anything for you that happen to have to right combination of sound card and distribution but for any one else it solves a lot of set up problems (among other things).

[ceage]

I didn't understand even a singe phrase here. Maybe I'm dense, but what do you mean?

I was talking about licensees giving up certain rights and receiving certain other rights in return.

I'd be thankful if you could provide a few references for this statement. Sounds rather interesting and I'd like to look it up.

Incidentally, the whole thing sounds like the Direct 3D (pre-10) vs OpenGL thing. Where people said D3D sucks because it's not cross-platform, has ugly API, results in vendor lock-in, all that stuff. Now if you replace D3D with ALSA and OpenGL with OSS, all those arguments are still the same. Yet, this time ALSA is better.

Linux users. Go figure :-P

This has been discussed to death on linux-audio-dev around the time when ALSA came up. For example Paul Davis (who is a JACK+ALSA-Developer) recommends to just use JACK instead and forget about ALSA.

See http://www.equalarea.com/paul/alsa-audio.html#forget

It's no accident JACK exits. The sole Problem here is that JACK is targeting pro audio. So PulseAudio simply is for mainstream users what JACK is for pro audio.

[kayosiii]

Well if jack/pulseaudio bypass some faulty alsa implementation, I may agree they "improve performance" like drag was saying to me. But then I have to say that's not PA or jack that improve performance, but it is ALSA that has some bugs or misconfigurations.

It's not so much bypassing a faulty implementation as it is that Alsa provides the functionality and Jack/Pulse decide how to use it. Without jack/pulse it's up to each individual application to decide how to use the functionality provided by alsa. There is also some value in having applications coordinated with each other.

[RealNC]

I was talking about licensees giving up certain rights and receiving certain other rights in return.

This has been discussed to death on linux-audio-dev around the time when ALSA came up. For example Paul Davis (who is a JACK+ALSA-Developer) recommends to just use JACK instead and forget about ALSA.

See http://www.equalarea.com/paul/alsa-audio.html#forget

It's no accident JACK exits. The sole Problem here is that JACK is targeting pro audio. So PulseAudio simply is for mainstream users what JACK is for pro audio.

I do use Jack for my audio applications (Zyn, Ardour, etc.) However, extra layers of indirection like PA look kinda funny and suggest an underlying problem. You see, saying that ALSA is not intended to be used directly is one of those things that came about after the fact. ALSA wasn't designed to not be used directly. It was designed as a replacement for the standard Unix audio interface (OSS) and to be incompatible with it. That would give it the freedom to do what it wants without worrying about Unix compatibility. But "not used directly" was never a goal. It grew over time and got complicated to use. And that was the point where people realized that it's better to not use it directly. IMO, that says a lot about ALSA: it certainly isn't a small, elegant, easy to use piece of software. In other words, it's software that does work, but it's not good software. I am of the opinion that instead of coming up with ALSA, the devs back in the day should have continued to develop the in-kernel OSS.

[kayosiii]

http://linuxplumbersconf.org/2009/slides/Paul-Davis-lpc2009.pdf