Google Chrome/Chromium Now Supports PulseAudio

[delan]

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 is:
"Yeah if you completely ignore everything that needs to be done then it's easy to do."

It certainly did for me.

[liam]

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_



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?

int ioctl(int fildes, int request, ... /* arg */):

from http://linux-documentation.com/en/man/man3p/ioctl.html with the appropriate args seems like it would deal with the headphones quite well.
Perhaps I am missing something since I know that "correct" audio implementations (including those who seemingly disagree with Nyquist/Shannon) are extremely complicated, but these particular things you mentioned seemed quite doable with posix. Even latency seems like it could be dealt with using poll.

Regardless, I agree with what you since PA has made things nothing but easier for me.

[drag]

@delan

You didn't do any mixer settings. You did not configure any of your applications. You didn't do anything, at all.

Zero, nadda.

I didn't realize that OSS4 had mind-reading capabilities.

[drag]

Regardless, I agree with what you since PA has made things nothing but easier for me.

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.

[delan]

@delan

You didn't do any mixer settings. You did not configure any of your applications. You didn't do anything, at all.

Zero, nadda.

I didn't realize that OSS4 had mind-reading capabilities.

The default mixer settings are configured sanely such that multichannel and spdif out are working out of the box. Applications that try to play audio will automatically use OSS, if ALSA and PulseAudio are removed.

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.

PulseAudio's OSS module is absolute tripe; it does not work for anything other than playing audio. Not even the mixer controls work.

[drag]

The default mixer settings are configured sanely such that multichannel and spdif out are working out of the box. Applications that try to play audio will automatically use OSS, if ALSA and PulseAudio are removed.

And when spdif shares the same audio output device as something else?

In many audio devices 'multichannel out' and 'spdif out' are mutually exclusive things. You can't have both at the same time. Especially common when you want to use a microphone.

PulseAudio's OSS module is absolute tripe; it does not work for anything other than playing audio. Not even the mixer controls work.

That's not a bad thing.

[delan]

That's not a bad thing.

Do tell me, under what circumstances is that "not a bad thing"? Because you don't like OSS?

[drag]

Do tell me, under what circumstances is that "not a bad thing"? Because you don't like OSS?

Yeah sure. The sooner LInux software abandons legacy and crufty APIs the easier it is for end users and the less likely you are to run into breakage, security problems, and shitty performance.

Plus I don't want OSS applications doing stupid stuff with my mixer settings. The less damage they can cause the better off I am. There are a number of times OSS applications and Alsa-only applications do just brain-dead shit to my system because of the hoops that those APIs make application developers jump through to try to make things 'easy' for end users. Especially when it comes to probing/configuring device outputs and trying to get microphones to work properly.

Individual applications have no business doing anything like that on the desktop, for the most part. It really just should be managed by a central application.

[delan]

Yeah sure. The sooner LInux software abandons legacy and crufty APIs the easier it is for end users and the less likely you are to run into breakage, security problems, and shitty performance.

OSS isn't a "legacy and crufty API". I don't know where you got that from.

Plus I don't want OSS applications doing stupid stuff with my mixer settings. The less damage they can cause the better off I am. There are a number of times OSS applications and Alsa-only applications do just brain-dead shit to my system because of the hoops that those APIs make application developers jump through to try to make things 'easy' for end users. Especially when it comes to probing/configuring device outputs and trying to get microphones to work properly.

Individual applications have no business doing anything like that on the desktop, for the most part.

You clearly misunderstood my reply. What I meant was that, the PulseAudio module for using OSS, module-oss, is so bad that it can't do any mixing controls. This is mainly due to Lennart Poettering is an arrogant fanboy that is too lazy to get OSS support working. I mean,

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

just shows it all really. Any sane person knows that deprecation is all about discontinuing one implementation of a feature in favour of another implementation of the same feature, not discontinuing one implementation of a feature in favour of a completely different feature which doesn't work in the original situation.

[drag]

You clearly misunderstood my reply. What I meant was that, the PulseAudio module for using OSS, module-oss, is so bad that it can't do any mixing controls. This is mainly due to Lennart Poettering is an arrogant fanboy that is too lazy to get OSS support working. I mean,

Oh. My apologies then.

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

Now OSS output for PA in FreeBSD or something is something else. But I don't see why Lennart Poettering is to blame for shitty FreeBSD support when, obviously, that isn't his focus. It's up for the people that care about BSD support to fix that if it is so broken.

OSS-in support is far more important since applications are more important then drivers. It is too bad that some old binaries that require things like mmap support don't work better in modern Linux. (I don't want them to have mixer controls, of course.)