Linux is not ready for Steam

[bwat47]

Also, regarding latency: I cannot detect audible sound latency while playing StarCraft. Running in VirtualBox. Which is configured to use the ALSA sound driver. So the sound goes like this:

StarCraft's own mixer->Windows XP sound stack in a VM->ALSA's pulse plugin->pulseaudio sound server->ALSA hardware driver->my soundcard.

It's totally fine. Claiming that a stupid game needs the same low-level latency as a professional audio workstation is pure hubris with no grounds in reality.

QFT.

Windows which is what most gamers use also has a PA like sound mixer. Its a game not professional audio editing.

[mugginz]

So crippling the sound system by removing PulseAudio is the answer?

"The sound system" does not include PulseAudio on many systems.

You are free to use it if you wish. I should be free not to use it and disable it without crippling my system.

The fact that you can't simply turn the thing off in some distros is rather scary.

You're missing the point.

You're assuming that simply rolling back to an ALSA only system fixes all issues to all users.

There is some important functionality provided by Pulse. If ALSA gets patched to provide all of that then there's no reason based on feature set alone no to go back to ALSA only. Will the ALSA guys add this?

Lucky for you those problems obviously don't exist on your own particular system. Not everyone's so well off.

I understand this and agree.

But this is a case of buggy drivers, and bugs should be fixed, not worked around.

No. In addition to any bugs that may be present in the ALSA hardware drivers, there's also higher level functionality not there in ALSA either.

Both PulseAudio and the higher levels of ALSA utilise these lower levels so both are subject to issues there but it's the higher level "niceness features" provided by Pulse that hasn't been there in ALSA only systems that they need to add to get my vote.

ALSA routes the PCM data through a software mixer as well. You still have latency addition whether using Pulse or ALSA.

Not if your card supports hardware mixing, you simply don't use a dmix plugin in that case.

Correct me if I'm wrong.

Not using a dmix like feature, no matter who's providing it (ALSA/Pulse/The Next New Audio Sub-system ), restricts the amount of concurrent audio streams you can play. Putting hard limits where they don't need to be doesn't make any sense to me. Without software mixing you're basically restricted to a small sub-set of audio hardware in order to facilitate a proper user experience.

And there are sound cards that don't do hardware mixing. As well as that, what happens when you max out the amount of channels available to a particular card that does? Add another card?

Use a software mixer, which has been a part of ALSA for a long number of years. No need to use software mixing if your hardware supports it.

It's a bit like insisting on using CPU for 3d rendering, in case some cards have buggy drivers.

Terrible analogy, I know...

But ALSA's dmix doesn't produce as nice results as does Pulse's mixing. Also, as soon as you dmixing, you're back to the latency addition you're saying Pulse sux for having.

That's the thing. Implementation details aside, both Pulse and ALSA are in similar boats here.

Every Linux program might be written to the ALSA API, assuming that ALSA automagically set itself up for the particular hardware in use and while that particular program's the only thing happening at any given time it might be completely happy. That's not always the case.

Once again, I have never had problems with any number of programs using ALSA simultaneously.

If this doesn't work on some systems, it's a driver bug.

Not just driver issues.

Consider the following use case.

• Install Ubuntu.
• Install Skype.
• Pair bluetooth headset with system.
• Start Skype and tell it to use bluetooth.
  
• Now, switch off the bluetooth headset. Now Skype auto routes audio though the main speakers.
  
• Receive a call which at this stage will be ringing through the main speakers. While it's ringing, turn on the bluetooth headset and Skype auto magically starts routing the call through the bluetooth headset. Absolutely no clicking, just automatical.

The same type of thing works with gaming headsets, etc.

How does ALSA deal with remembering preferred routes for audio and automatically re-routing it on demand these days?

Why would it need to be resampled the second time. Why wouldn't it be:

Software written for ALSA -> ALSA Layer for PulseAudio -> resample -> mix with any other audio currently playing -> Hardware.

If the first resampling is done at the correct frequency, then yeah. Still, it's a longer chain.

How's that longer than:

Software written for ALSA -> ALSA Upper Layers -> resample -> mix with any other audio currently playing -> Hardware.

And maybe that hardware doesn't support hardware mixing. What then?

Then use software mixing, as present in ALSA for many years.

You only use it when you actually need it.

But according to you software mixing is unacceptable.

Pulse is performing needed tasks and then routing it to the hardware via ALSA drivers, just like the upper layers or ALSA do.

If it does exactly the same thing that ALSA does, then I really don't see the point.

It does what ALSA does and more.

ALSA was extended in order to kill ESD, which was doing pretty much the same thing as PulseAudio (though not as sofisticated). ALSA killed ESD. Now PulseAudio is here as a drop-in replacement for ESD.

I didn't find ESD as good as Pulse. Pulse is a superset, not just an analogue.

The argumentation is that ALSA does not work correctly on all systems.

ALSA also is lacking features.

Is the solution to fix ALSA, or to introduce yet another layer, which works on top of a broken system, and introduces a whole new batch of problems?

Well if ALSA implements everything that's in Pulse, then that becomes an option without feature removal.

Are you assuming that the higher level bits of ALSA introduce no extra code to the lower level hardware drivers?

Sometimes Linux really goes around in circles. People hated ESD and aRts because they introduced all sorts of problems with all sorts of applications and because there were all sorts of problems with backwards compatibility. In the end, they both died because of this. Now PulseAudio is pushed as a standard, and people are having the exact same problems again.

I think you're conflating implementation specific issues/bugs with feature sets provided to the end user.

[pingufunkybeat]

There is some important functionality provided by Pulse. If ALSA gets patched to provide all of that then there's no reason based on feature set alone no to go back to ALSA only. Will the ALSA guys add this?

So why can't anyone list these features and why they are so important for a desktop system.

So far, the killer arguments were:

- software mixing (works in ALSA)
- per app volume (works in ALSA, but is quite clunky and should be reworked)

I don't accept these arguments, sorry.

The only good argument for PA so far is the ease of rerouting bluetooth streams. OK, that is an argument and, although I haven't tried it, I believe that it's probably messy with pure ALSA.

The other arguments (network routing) are fringe applications nobody needs, and those who do are using JACK anyway.

Not using a dmix like feature, no matter who's providing it (ALSA/Pulse/The Next New Audio Sub-system ), restricts the amount of concurrent audio streams you can play. Putting hard limits where they don't need to be doesn't make any sense to me. Without software mixing you're basically restricted to a small sub-set of audio hardware in order to facilitate a proper user experience.

With ALSA, you have a choice, and you can switch trivially.

With a sound daemon, you are always emulating hardware functionality in software. This is an odd solution.

But ALSA's dmix doesn't produce as nice results as does Pulse's mixing. Also, as soon as you dmixing, you're back to the latency addition you're saying Pulse sux for having.

This is an implementation issue and probably not a big deal to change. And I haven't mentioned latency at all, you're referring to other posters.

Software mixing always adds latency. Hardware mixing doesn't.

That's the thing. Implementation details aside, both Pulse and ALSA are in similar boats here.

Similar, yeah, but one is a daemon, and the other one an API layer.

But according to you software mixing is unacceptable.

Come on, don't make things up. I've never claimed such a thing.

I'm saying that if your sound card can mix 8 streams in hardware, then it's rather pointless.

Well if ALSA implements everything that's in Pulse, then that becomes an option without feature removal.

It doesn't need to implement EVERYTHING in Pulse, as only a small subset of Pulse functionality is even remotely useful for a desktop.

And the subset that keeps getting mentioned 99% of the time is "software mixing".

This is not convincing.

I don't know, sell me PulseAudio. Right now, I don't use it, and I don't see a need to. I'll give you that, if I start using wireless bluetooth headsets and want to route Skype output on the fly back and forth, it would probably be worth an install.

But why should it be made mandatory? If I'm not rerouting bluetooth audio streams on the fly, what else does it do for me?

[mugginz]

So why can't anyone list these features and why they are so important for a desktop system.

So far, the killer arguments were:

- software mixing (works in ALSA)
- per app volume (works in ALSA, but is quite clunky and should be reworked)

I don't accept these arguments, sorry.

There's also sound re-routing and higher quality sound mixing.

The only good argument for PA so far is the ease of rerouting bluetooth streams. OK, that is an argument and, although I haven't tried it, I believe that it's probably messy with pure ALSA.

That's the kind of functionality expected by a lot of people. If Linux is to be viable for a larger user base it needs to provide stuff like this, whether facilitated by ALSA, Pulse, JACK, or whatever.

The other arguments (network routing) are fringe applications nobody needs, and those who do are using JACK anyway.

I currently aren't using network routing of audio. There are however people who are. I'm not going to support the removal of functionality just because it's a feature I personally don't need.

With ALSA, you have a choice, and you can switch trivially.

With a sound daemon, you are always emulating hardware functionality in software. This is an odd solution.

How trivial is the switching?

Also, depending on the hardware you have there'll be resampling say to playback audio that's been sampled at rates the hardware doesn't natively support.

This is an implementation issue and probably not a big deal to change. And I haven't mentioned latency at all, you're referring to other posters.

Software mixing always adds latency. Hardware mixing doesn't.

When/if they implement better mixing then that'll be good but not until.

If you're not referring to latency as a reason to not use Pulse, then what reason do you not like Pulses mixing?

That's the thing. Implementation details aside, both Pulse and ALSA are in similar boats here.

Similar, yeah, but one is a daemon, and the other one an API layer.

And what's on the other end of that API layer? Magic that requires no code to push that audio data to the audio hardware level driver code?

But according to you software mixing is unacceptable.

Come on, don't make things up. I've never claimed such a thing.

Well then why do you have a problem with Pulses mixing?

I'm saying that if your sound card can mix 8 streams in hardware, then it's rather pointless.

And what percentage of users have audio hardware that provides that?

Of those that do, what happens when you push a 13456 samples per second stream to one of those channels that only provides playback at 16/24/44.1/48K samples per second?

It doesn't need to implement EVERYTHING in Pulse, as only a small subset of Pulse functionality is even remotely useful for a desktop.

In your opinion for your use case. And that's where the problem seems to be.

And the subset that keeps getting mentioned 99% of the time is "software mixing".

This is not convincing.

I don't know, sell me PulseAudio.

I'm not selling to you, just explaining why it's useful.

If you're prepared to fiddle, read man pages, edit config files, have various sound playback modalities depending on the config files you're using at the time depending on what particular style of audio playback you need and don't require things to "just work" then Pulse isn't likely to be critical to you in any way.

If you're the type of person that has work to do and can't spend time making their system work so they can get on with real work then Pulse might just be a god send.

Right now, I don't use it, and I don't see a need to. I'll give you that, if I start using wireless bluetooth headsets and want to route Skype output on the fly back and forth, it would probably be worth an install.

But why should it be made mandatory? If I'm not rerouting bluetooth audio streams on the fly, what else does it do for me?

For you you've found plain ALSA fits your needs acceptably.

To call for distros to drop Pulse on that basis is a bit thin.

[pingufunkybeat]

I currently aren't using network routing of audio. There are however people who are. I'm not going to support the removal of functionality just because it's a feature I personally don't need.

I've never met anybody who needed network routing of audio.

This was the main selling point of aRts for how many years? 6? In the end, nobody has ever used it.

People who need such functionality are completely welcome to use software which provides it, like PulseAudio. But to deprecate ALSA and make PulseAudio mandatory because of this? I don't think so.

How trivial is the switching?

Commenting dmix out in the default .asoundrc. So not too trivial, but nothing requiring a radically new sound system.

If you're not referring to latency as a reason to not use Pulse, then what reason do you not like Pulses mixing?

That it's not needed.

Of those that do, what happens when you push a 13456 samples per second stream to one of those channels that only provides playback at 16/24/44.1/48K samples per second?

Then you resample.

In your opinion for your use case. And that's where the problem seems to be.

The issue is what should be made mandatory in every Linux distro. And this should be things that most people need.

There are people out there with all sort of use cases. In general, you don't make software mandatory if it only addresses a minority of users. In such a case, you make software optional.

And, other than rerouting of bluetooth headsets (which I accept as a relevant use case), I haven't seen anything that requires PulseAudio today.

If you're prepared to fiddle, read man pages, edit config files, have various sound playback modalities depending on the config files you're using at the time depending on what particular style of audio playback you need and don't require things to "just work" then Pulse isn't likely to be critical to you in any way.

But I didn't do any fiddling, and it just worked.

On my work Kubuntu computer, PulseAudio keeps complaining about this and that and turning itself on and off. And you can't get rid of the thing.

For you you've found plain ALSA fits your needs acceptably.

To call for distros to drop Pulse on that basis is a bit thin.

They shouldn't drop it.

Just like they shouldn't drop Athena widgets or GTK or Qt. Or Java. They should make it OPTIONAL so I can use it if I need it. Just like ESD was optional.

Some people seem to want to force PulseAudio as an artificial standard and break support for everything else in the process. What on Earth is the justification for such a thing? My apps work fine with ALSA. Leave them alone. You can patch them to support PulseAudio just like they supported aRts and ESD before, that's fine.

[pingufunkybeat]

If somebody suggested a colour-mixing daemon which intercepts the traffic between the X server and the driver because some drivers are buggy, I would also wonder what the hell was going on

[kazetsukai]

Just like they shouldn't drop Athena widgets or GTK or Qt. Or Java. They should make it OPTIONAL so I can use it if I need it. Just like ESD was optional.

The problem with giving these options is that everyone keeps trying to re-invent the wheel on Linux sound without addressing any of the real problems we currently have while introducing some artificial need for others. I really wish the ALSA team would put together a public facing roadmap, because as is it just seems like random features are introduced every release.

Some people seem to want to force PulseAudio as an artificial standard and break support for everything else in the process. What on Earth is the justification for such a thing? My apps work fine with ALSA. Leave them alone. You can patch them to support PulseAudio just like they supported aRts and ESD before, that's fine.

It is getting ridiculous, on the Ubuntu forums I see two very common themes going on:

"Does it work? No? Disable PulseAudio."
"Does it work? No? Enable PulseAudio."

For most sound problems you will get those two answers, -on the same forum-.

Developers seem to think that we've decided on a sound standard just because one of the more popular desktop distros installs it by default, making -most- (certainly not all) things work. Sadly this is not the case.

[mugginz]

I've never met anybody who needed network routing of audio.

This was the main selling point of aRts for how many years? 6? In the end, nobody has ever used it.

People who need such functionality are completely welcome to use software which provides it, like PulseAudio. But to deprecate ALSA and make PulseAudio mandatory because of this? I don't think so.

When no one needs it then maybe it can be removed. While some do it should stay if it can.

How trivial is the switching?

Commenting dmix out in the default .asoundrc. So not too trivial, but nothing requiring a radically new sound system.

Bingo! And This is not an option to lots and lots of people.

Editing config files in this area indicates fail.

If you're not referring to latency as a reason to not use Pulse, then what reason do you not like Pulses mixing?

That it's not needed.

What, until you do? And then what? Do you then expect an end user to mod a config file when they all of a sudden need software mixing?

Of those that do, what happens when you push a 13456 samples per second stream to one of those channels that only provides playback at 16/24/44.1/48K samples per second?

Then you resample.

But then you need other code than just the low level "push this data set to the hardware" code. Whether this code's in ALSA or Pulse it sometimes has to be done. This in itself doesn't indicate for either Pulse or ALSA only.

In your opinion for your use case. And that's where the problem seems to be.

The issue is what should be made mandatory in every Linux distro. And this should be things that most people need.

There are people out there with all sort of use cases. In general, you don't make software mandatory if it only addresses a minority of users. In such a case, you make software optional.

And, other than rerouting of bluetooth headsets (which I accept as a relevant use case), I haven't seen anything that requires PulseAudio today.

What about gamers using in game chat via headsets and then switching to the mike on their webcam when it suites them?

As to what types of use to code to. If you're just starting out you restrict yourself to the most urgently required functionality. As time moves on it's good to provide a fuller functionality for users. If Linux had just been released yesterday you could forgive 1995 levels of functionality. It's now 2010 and it's not unreasonable to expect a little more.

If you're prepared to fiddle, read man pages, edit config files, have various sound playback modalities depending on the config files you're using at the time depending on what particular style of audio playback you need and don't require things to "just work" then Pulse isn't likely to be critical to you in any way.

But I didn't do any fiddling, and it just worked.

Yet above you're proposal to deal with "in session user requirement changes" is to mod a config file.

On my work Kubuntu computer, PulseAudio keeps complaining about this and that and turning itself on and off. And you can't get rid of the thing.

And obviously this is an example of where it's not perfect. Not everyone's having that level of issue thankfully.

I personally was running Kubuntu 9.10 on my main system with Pulse and had no problems. My MythTV box is Kubuntu 10.04 based. My main rig is now Ubuntu 10.04 with Pulse.

In the past I've had to install Pulse to alleviate issues that come up in an ALSA only install.

If more people than not have issues with it, and this isn't going to change then thay should dump it. I'm not hearing that level of outrage though.

I will say that Pulse does suffer from the syndrome that fglrx will one day suffer once it becomes viable. That is, it once sucked, is now good, but it will take time for some to like it because it's reputation precedes it. Largely these days Pulse seems to work happily a lot of the time.

They shouldn't drop it.

Just like they shouldn't drop Athena widgets or GTK or Qt. Or Java. They should make it OPTIONAL so I can use it if I need it. Just like ESD was optional.

Widget sets are a different situation though. You can have QT, Gtk, Motif, wxWidgets etc all up and going at once but can't really have a Pulse and non Pulse system at the same time. (VMs not withstanding)

I guess you can always move to a distro that doesn't integrate Pulse.

Some people seem to want to force PulseAudio as an artificial standard and break support for everything else in the process. What on Earth is the justification for such a thing? My apps work fine with ALSA. Leave them alone. You can patch them to support PulseAudio just like they supported aRts and ESD before, that's fine.

Pulse may need to continue to work on the ALSA layer but I still think it provides a better system overall than a plain ALSA one.

[pingufunkybeat]

Maybe my problem is with a sound daemon.

Every sound daemon in the history of Linux has always sucked. Things got fixed and improved, and they still sucked. And it seems like PulseAudio sucks too, given the number of problems people are reporting.

ALSA is not perfect. Perhaps it is stagnant as a technology, and ready to be replaced in order to deal with the new needs for a brave new desktop, bring more plug and play, etc. Perhaps parts of ALSA should be replaced by better code from a different project, and maybe PulseAudio has some of the answers. Maybe a library superior to ALSAlib should replace it, I don't know, I'm not against progress. Technologies such as hal and devfs have been abandoned and replaced by better things once they went stagnant, and maybe it's ALSA's turn for a major overhaul.

But introducing ESD 2.0 as a solution to software mixing is really not very convincing. We've seen this SO many times, and it sucked every time.

Fix the sound properly. Keep the hardware stuff in the kernel, and expose a sane API to the applications. In other words, reinvent ALSA if necessary. The apps should shove a stream into a device and not care about anything else.

Why do you need a daemon? Then if the daemon is not running, you get no sound? What sort of a Frankenstein solution is that?

[mugginz]

If somebody suggested a colour-mixing daemon which intercepts the traffic between the X server and the driver because some drivers are buggy, I would also wonder what the hell was going on

But that's not an analogue of the Pulse vs ALSA situatiuon.

Though if some commonly required functionality was needed though and it was implemented in a shared library until the driver implemented it natively then that'd make sense.

Until the driver implemented your colour mixing code and assuming it has to be done, why not make it available elsewhere until the driver implements it?