Google Chrome/Chromium Now Supports PulseAudio

[RealNC]

LOL:

"Some claim the drivers “sound better”. Not relevant."

Nope, not relevant at all.

"Stop developers from writing apps with the OSS API"

Yep, true cross-platform friendliness. Write for ALSA so that your app will work on Linux, BSDs, etc. Oh no, ALSA is Linux-only. First you blame MS for such tactics, but then you go and embrace them? If you write for OSS, your app will work on many Unices, not just Linux. So why use ALSA in the first place?

"ALSA wasn't really that different from OSS anyway"

Then why reinvent the fucking wheel instead of fixing the one you have?

Oh, and didn't anyone notice that the PDF comes up with the shortcomings of OSS that only exist in the ancient in-kernel version and don't exist in the modern implementation? How convenient, don't you think?

[kayosiii]

LOL:

"Some claim the drivers “sound better”. Not relevant."

Nope, not relevant at all.

Unless you can quantify it in some way or prove it with double blind testing it really isn't relevant.

"Stop developers from writing apps with the OSS API"

Yep, true cross-platform friendliness. Write for ALSA so that your app will work on Linux, BSDs, etc. Oh no, ALSA is Linux-only. First you blame MS for such tactics, but then you go and embrace them? If you write for OSS, your app will work on many Unices, not just Linux. So why use ALSA in the first place?

The Author of the paper is advocating using pulse/jack rather than using Alsa directly i.e. using a client server model rather than a sound device is a file model. For jack in particular - having a pull based model work efficiently is very important. The Author notes that writing apps the OSS way encourages apps that don't necessarily play well with the rest of the sound system. You can certainly make a case that cross platform is important but you cannot simply ignore these other factors. For jack you get significant benefits for your application using jack over using alsa,oss directly - I imagine it is the same for using pulseAudio.

Oh, and didn't anyone notice that the PDF comes up with the shortcomings of OSS that only exist in the ancient in-kernel version and don't exist in the modern implementation? How convenient, don't you think?

The paper was written in 2009, When was the modern version of OSS made publicly available?

It should give some insight as to where Linux audio is going and why.
At this point it is most important to have a model that works and has the manpower behind it to fix the things that don't work. Pulse is a reasonable canditate for this. OSS could have been a candidate but because of the bridges that the OSS team burn't in the past I really can't see everybody moving that way any time soon. (If OSSv4 had been freely available before everybody migrated to pulse-audio there is a very small chance that things might have been different)

[curaga]

For jack you get significant benefits for your application using jack over using alsa,oss directly - I imagine it is the same for using pulseAudio.

If you go for pulse-only in your app, you get the benefit that your app won't even run on linux, only on PA-including linux.

[kayosiii]

If you go for pulse-only in your app, you get the benefit that your app won't even run on linux, only on PA-including linux.

This is even more true of OSSv4 and Alsa. For practical purposes PA including linux is all major Linux distributions minus people who manually uninstall it (which should be a decreasing number as PA gets better - I no longer uninstall PA but I used to). It covers a wider range of hardware than either OSS,OSSv4 or Alsa. It's hard to reccomend any single sound api to for non pro-audio software on Linux but PA is increasingly becoming it.

[drag]

Yep, true cross-platform friendliness. Write for ALSA so that your app will work on Linux, BSDs, etc. Oh no, ALSA is Linux-only.

Programs using Alsa libraries are cross-platform. They run just fine on FreeBSD or whatever other system you'd care to inflict on yourself.

http://www.freebsd.org/ports/audio.html

Just do a ctrl-f search for 'Alsa'.

This is even more true of OSSv4 and Alsa. For practical purposes PA including linux is all major Linux distributions minus people who manually uninstall it (which should be a decreasing number as PA gets better - I no longer uninstall PA but I used to). It covers a wider range of hardware than either OSS,OSSv4 or Alsa. It's hard to reccomend any single sound api to for non pro-audio software on Linux but PA is increasingly becoming it.

Pro-audio is so far removed from desktop audio it's just silly. Very different goals. Having a separate audio stack for both is not really a bad thing.

If you want to use your 'pulse-only' applications on Jackd then you can just pulse-jack. That way you don't have to give anything up. It would be the easiest way I know of to pull in audio samples from Flash video online to 'pro' style audio tools in Linux, for example.

[kayosiii]

Pro-audio is so far removed from desktop audio it's just silly. Very different goals. Having a separate audio stack for both is not really a bad thing.

Apple have done a fairly good job of this with coreaudio. I prefer jack from a technical standpoint though.
What I was trying to say was that if you are doing pro audio then jack is a no-brainer. Otherwise you need to choose between the other options of which I think PA will reach the largest number of people going on into the future.

If you want to use your 'pulse-only' applications on Jackd then you can just pulse-jack. That way you don't have to give anything up. It would be the easiest way I know of to pull in audio samples from Flash video online to 'pro' style audio tools in Linux, for example.

As it happens I run a firewire based soundcard so jack is my only option. PA seems to work better with jack better than alsa works with jack.

[NomadDemon]

it would be nice to have jack and PA, no oss ano no direct alsa support
PA for consumers and JACK for pro audio. jack should be more flexible by the way, need to use same sample rates with all programs to get it work, windows and cubase sound managment dont need same sample rates, and also works great [ASIO]

[curaga]

This is even more true of OSSv4 and Alsa. For practical purposes PA including linux is all major Linux distributions minus people who manually uninstall it (which should be a decreasing number as PA gets better - I no longer uninstall PA but I used to). It covers a wider range of hardware than either OSS,OSSv4 or Alsa. It's hard to reccomend any single sound api to for non pro-audio software on Linux but PA is increasingly becoming it.

No, if you write for OSS your app will run everywhere. If you write for ALSA, your app will run on most linux. See how each is a subset? Pulse is a subset of the alsa group.

[curaga]

(edit still broken)

Of course this was a generalization, as one can't use the apis to their full effect due to brokenness of pulse, alsa-safe OSS subset etc.

[drag]

Apple have done a fairly good job of this with coreaudio. I prefer jack from a technical standpoint though.
What I was trying to say was that if you are doing pro audio then jack is a no-brainer.

Absolutely.

Otherwise you need to choose between the other options of which I think PA will reach the largest number of people going on into the future.

Most applications and games will just use audio libraries, all of them will work just fine on most platforms.

Like if your a game programmer you may want to use SDL or OpenAL. Or if your using desktop applications and want event noises you probably want to use Canberra. If your using more complex multimedia applications you will probably end up using Gstreamer.

If you are programming directly in Alsa or OSS whatever your probably doing it wrong.

No, if you write for OSS your app will run everywhere. If you write for ALSA, your app will run on most linux. See how each is a subset? Pulse is a subset of the alsa group.

Of course this was a generalization, as one can't use the apis to their full effect due to brokenness of pulse, alsa-safe OSS subset etc.

So you mean 'run everywhere' you actually mean 'Run like shit in Linux' and 'Runs ok in FreeBSD' and then 'Probably won't work at all in Solaris since the likelihood of actually having fully functional audio drivers for your hardware is small'.

If you are caring about portability then programming in OSS is just about the worse choice you could make.

Even if you program in Alsa it is still very portable to the BSDs and Solaris since the Alsa libs work fine on top of OSS. In addition to this Alsa libs work fine on Windows and OS X, were OSS does not.

So even if your only choices in life is Alsa vs OSS, saying 'Use OSS if you care about portability' is one of the worst pieces of advice you could give to a programmer, since OSS is not really portable at all. Especially not to any OS that your typical user will give a crap about...

But there are still a lot of better choices then Alsa, of course.