Wine Developers Fight Over PulseAudio Driver

[GreatEmerald]

I would agree with you unnecessary CPU consumption was PA's only problem. My system is modern, I don't use it. Not saying other shouldn't just saying you're off on your statement. With that being said, I do think wine should be able to handle it if nothing else. I don't really like the idea of wine having a default I guess.

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

[ChrisXY]

Meh. Pulseaudio sucks. It's the first thing I remove when I do a fresh install.

How do you know it sucks then?

[halo9en]

Meh. Pulseaudio sucks. It's the first thing I remove when I do a fresh install.

[Alex Sarmiento]

pulseaudio : a fix for a problem that didn't exist. (not completely true, but a wrong fix anyhow : fixing something by adding a layer of complexity is plain wrong)
I hate pulseAudio, for me it caused nothing but trouble (HTPC, desktop and laptop). Using pure ALSA hasn't yet let me down. The craziness it allows me to do is everything anyone can ask for (I even used it to stream audio of a movei to a different PC). Yes it takes a day of digging through docs/tutorials, but it IS possible.
Also when using pulse on a relatively good sound system, I got the feeling that it somehow distorted the sound; I'll have to do an analysis at some point...
And don't get me started on digital passthrough.

rant off...

Serafean

I haven't notice pulse audio since years,except when i have to deal with wine installations.

[DanL]

Hmm. The article discusses competing versions of a wine pulseaudio driver. It doesn't discuss whether wine will have a pulse driver (it does) or whether you like pulseaudio. Try to stay on topic (I know that's difficult).

Anyway, here's a link to the correctly threaded version of wine-devel (although no one's responded to Martin's comment yet): http://www.winehq.org/pipermail/wine...ead.html#95955

[russofris]

What does Miguel de Icaza have to do with this thread?

I've been told that explaining a joke makes it less funny. I sincerely apologize for any inconvenience that this may have caused.

F

[Delgarde]

I haven't really been a fan of Miguel de Icaza's work since Rage Against the Machine broke up.

What does Miguel de Icaza have to do with this thread?

[russofris]

I don't really like the idea of wine having a default I guess.

My understanding was that wine enumerated the available APIs on first-run, and had some order of preference...

Pulse >= version X
Alsa
Pulse < version X
OSS
esd
arts
etc
etc

While I may be totally and absolutely wrong about this, the sentiment is that the term "default" may be a bit of a misnomer. The user is free to use winecfg if they have a preference.

F

[nightmarex]

I seriously think the NAY SAYERS are on Pentium 3's or the like struggling to keep their system from dying and watching screen page flip.

Modern Linux users want Pulse Audio.

I would agree with you unnecessary CPU consumption was PA's only problem. My system is modern, I don't use it. Not saying other shouldn't just saying you're off on your statement. With that being said, I do think wine should be able to handle it if nothing else. I don't really like the idea of wine having a default I guess.

[russofris]

There's one "hw" device for exclusive access, and there's a dmix device that I guess you can call virtual. The hw device can only be opened by one application at a time. The dmix device can be opened simultaneously.

Per-application volume is not supported well. There's no automation for it, you need to set up everything manually and assign mixer controls to specific applications, which is totally useless. It's one of the things PA chose to replace instead of fix. Well, it was to be expected I guess. Linux devs usually want their own projects instead of joining an existing one. Fame and honor and all that :-/

That's (along the lines of) what I thought. If a per-application mixer can be allocated manually, I'm certain that someone could extend the API allocate them dynamically. Unfortunately, if I remember the formatting of the .asoundrc and the options for each dmix device (define inputs, outputs, sample rates, etc), it's going to be a big task.

Someone should look at the PA API, and reimplement the PA API on top of dmix (or extend the ALSA API). If it didn't work out, at least it adds some fuel to the fire that appears to be consuming the issue. Some bridges are better off burnt.

I haven't really been a fan of Miguel de Icaza's work since Rage Against the Machine broke up.

F