Wine Developers Fight Over PulseAudio Driver

[gilboa]

How long ago did you try pulse under arch? I'm currently using pulse under arch and it works perfectly, I didn't even have to do any extra tweaking... pacman -S pulseaudio pulseaudio-alsa pavucontrol, and everything just works (well I had to do a little bit of tweaking in XFCE, but that was due to xfce-mixer and xfce-volumed's nonexistant pulse support and not a problem with arch. When I used it in gnome/kde it required zero extra tweaking), the arch packages already included the necessary asound.conf too.

To be honest, I didn't have much time to test Arch, so any issues I had with PA/XFCE might have been *entirely* my fault.

- Gilboa

[psycho_driver]

Not a fan of PA. Have never used it on my gentoo boxes, and I routinely have to work around it on my wife's desktop.

[Dehir]

Im really looking solution for this problem and i hope it ends up better pulseaudio support for wine. Why someone asks. Well im currently running setup where i output sometimes my music from apps and game sounds from wine via tunnel-sink and its pretty annoying when it gets latency. My network speed isnt the problem its the alsa-pulseaudio problem here. Almost every other app work flawless like html5 sound from youtube and native linux games vlc etc... (flash plugin isnt working and its very choppy but ya).

So less latency is always better as it makes things working. And i think that in this point it would be best to seal pulseaudio support as i think its now mature enough to handle all the audio needs for near lets say 5-10 years in future and lets hope that other audio driver will overcome in time that can handle everything in one layer.

I also started to use pulse audio like year ago as it got enough mature. But case you dont need the pulse audio you will be fine just using alsa. Thou many packages are being merged depend on pulseaudio so it cant hurt much to give it a try.

The pulse audio networking isnt too hard to figure out but it totally lacks good documentations maybe. I used various wikipages to get my setup(openwrt,gentoo,archlinux). I guess the hardest part is to realize how it should be configured to handle the audio. Maybe some pictures with flow-chart should easy it up a but i guess :\

[Stedevil]

Once again, pulse-damon.conf. It has loads and loads of settings to micromanage how much CPU it uses. It's set to be high priority by default (so that audio isn't interrupted), and you can change that very easily.

It seems that the main problems that people have with PA are that a) it was released earlier than it was ready (integrated properly) and so people still remember it in that broken state, even if it's fixed long ago, and b) that nobody cares to read the manual for it...

I agree on a) (and god knows It was a bumpy ride when PA was forced down on people too early), but not about b). WHY should an average desktopuser have to read documentation about how to manually set up their sound card driver and mid level sound system with a texteditor??? That is something geeks and sound pros only should ever need to even think about. Average Joe expect sound to always just work, and that is how it should be on a modern system.

[gamerk2]

I agree on a) (and god knows It was a bumpy ride when PA was forced down on people too early), but not about b). WHY should an average desktopuser have to read documentation about how to manually set up their sound card driver and mid level sound system with a texteditor??? That is something geeks and sound pros only should ever need to even think about. Average Joe expect sound to always just work, and that is how it should be on a modern system.

^^ This. Its not the mid-90's anywhere, where you have to manually manage IRQ's and the like.

[cynical]

I do agree. But you're forgetting that ALSA-lib was created to handle all the userspace stuff. ALSA has two parts, one in kernel space, one in user space. PA is trying to replace the user space part of ALSA. It would make more sense to enhance user space ALSA instead of replacing it.

Except that because it isn't just an enhanced ALSA, it can be used on multiple platforms. The added flexibility is a benefit even if it doesn't help Linux users directly and AFAIK there is no downside.

There's two approaches to fixing something. a) try to fix the existing code and b) rewrite the existing code. PA did neither. It just threw another API in there. So when something turns up in PulseAudio that doesn't work well in the future, let's create yet another one. We'll call it NewAwesomeAudio which replaces PulseAudio. And later, when problems with that turn up, we'll go for yet another new API.

No. If there's a problem, fix it.

PulseAudio is a sound server. The whole point of creating it is to abstract away the various sound APIs, hardware, and multimedia backends from each other. This means that in the future when any new number of those are created, they will be invisible to the end user who will continue to use PulseAudio to manage everything.

Can anyone explain to me why Pulseaudio is bad? From what I can see it is an excellent solution to the problem of the Linux audio stack not having feature parity with its commercial bretheren.

[curaga]

PulseAudio is a sound server. The whole point of creating it is to abstract away the various sound APIs, hardware, and multimedia backends from each other. This means that in the future when any new number of those are created, they will be invisible to the end user who will continue to use PulseAudio to manage everything.

Can anyone explain to me why Pulseaudio is bad? From what I can see it is an excellent solution to the problem of the Linux audio stack not having feature parity with its commercial bretheren.

You yourself wrote up one reason. It's a server, Yet Another Daemon you have to run, wasting resources unneededly.

As for the plethora of other reasons, do read up the 30-page threads pulse causes, CBA to repeat them (and myself).

[niniendowarrior]

To me, Pulse Audio is a well-intentioned piece of software that just doesn't work. I have had close to 0 problems running Alsa and the very instant Ubuntu introduced Pulse Audio, it's been nothing but hell. Not ready for prime time is true. But is it just my bad memories of Pulse Audio? Hardly. To this day, it still gives me hell and I have better things to do than fiddle around with this bullsh*t.

[Lemonzest]

I've had zero problems with PA, but then maybe that's because Mageia and Mandriva before it have good defaults and its all tied in together

[gilboa]

To me, Pulse Audio is a well-intentioned piece of software that just doesn't work. I have had close to 0 problems running Alsa and the very instant Ubuntu introduced Pulse Audio, it's been nothing but hell. Not ready for prime time is true. But is it just my bad memories of Pulse Audio? Hardly. To this day, it still gives me hell and I have better things to do than fiddle around with this bullsh*t.

1. I've been using PA exclusively since Fedora 9-10 (?) on >10 desktop machines, with zero issues.
This of-course doesn't necessarily negates your experience, but its just as valid.

2. It's time to give it a rest. PA won, Alsa-clean lost. You may enjoy tweaking alsarc and dmix on a per-application basis, but a vast majority of the Linux user-base don't (hence the exponential increase in PA aware distributions and software).
Granted, you may find like-minded people and find PA-free distributions, but in the current rate of affairs, the selection is rather thin and will only get thinner.

As I doubt that you truly believe that repeating the same rant over and over again will cause Ubuntu or Fedora to drop PA (and I'm not talking about you specifically), you're left with one of two options:
1. Learn how to get PA working for you, or 2. start marking preparation to switch to BSD.

- Gilboa