[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=10495





--- Comment #231 from Alexey Loukianov <mooroon2 at mail.ru>  2010-02-15 23:58:39 ---
> Invalid argument.
> 
> winealsa:
> [App]->[Wine]->[SB]
> 
> wineoss:
> [App]->[Wine]->[SB]
> 

You are either trolling or wrong.
Sound paths you specify are for "pure ALSA" system, not for the
"PulseAudio-enabled" system.

> > Without any doubts in case we turn off the PulseAudio completely the
> > path will be even shorter, but it will hardly break the sound-related
> > applications on a system that was tuned to use PulseAudio as it's primary sound
> > backend.
> 
> pulse is not a backend. Your own diagrams invalidate your point.
> 

Pulse is a backend. Prove that is it not. And - to be correct - provide your
definition of a term "backend", please, as I suppose we're talking about a
different things when use a word "backend".

> > User will be either forced to reconfigure his/her system to utilize
> > the ALSA/dmix
> ... which takes next-to-no effort.

... in case it is pure-ALSA system without PulseAudio. Have you ever used an
PulseAudio-enabled system where ALSA hw-devices are often locked by PulseAudio
making dmix break (that is one of the reasons I don't use PulseAudio on my
"linux sound processing workstation")? 

> > instead of PulseAudio or to get by with a non-fully-functional
> > sound subsystem.
> ... except it's not fully-functional, and OpenAL would actually help that.

OpenAL is a good thing to implement driver for, but unfortunately it is nothing
more than another software sound library nowdays when it comes to linux world.
Native hardware-accelerated OpenAL drivers are there for Windows and MacOS X,
but there are nothing of this kind for Linux. Actually, I hadn't heard about
any contributions to the Linux port of OpenAL from the Creative, and it looks
like very unlikely for us to get native linux OpenAL-enabled sound drivers
directly from major sound cards vendor :-(.


> > will limit winealsa driver to a some subset of the API that libalsa offers. 
> The question is, will doing this cause winealsa to break? So far, no one has
> demonstrated this either way.

What do you mean by a "break"? Will the (possible) loss of performance be a
"break"? Nevertheless - I repeat it again - a general-purpose "one-fits-all"
driver will always be more generic than specialized ones, and it will not
include target-specific optimizations in it (unless some additional execution
branches will be introduced in it, i.e. a sort of subdrivers - and that is not
far from implementing a separate target-specific driver).

> > ... winealsa driver will loose some possible ways it might behave if
> >  it were targeted to a normal (non-pulse-emulated) ALSA devices.
> Yes, but what hasn't been proven is that Wine actually *needs* to do those
> things.

Surely not. The opposite hadn't been proven as well.

> > usage of PulseAudio-emulated ALSA devices can not be optimized to the same
> > extent as it is possible for the non-compatible-with-Pulse winealsa.
> That is equally true of winepulse.

Equally true... for what? winepulse has nothing to do with ALSA, it should use
native PulseAudio API and it should be optimized for this. winealsa should use
libalsa native API and should be optimized for that. That are the obvious
facts.

> > So, please stop lying to people that winepulse is not required.
> Please don't try to start another flamewar.

There's no need to start a new one - the older is still burning.

> > only _real_ reason I can see why not to include the winepulse in the generic
> > wine source are the maintenance problems. All the other reasons that were
> > stated in the comments upwards seems to be more a political one.
> 
> Code quality may be political, but it made Wine what it is today. Without code
> quality, Wine would be a dying project like Cedega or ReactOS.
> 

The quality of a code is a subjective thing. I've been working some time as a
programmer supporting legacy code and reviewing proposed patches to make it
better. There always were some things that we were not agreeing at with
colleagues while the proposed code was working in general. Then again - as I
had already said - IMHO there's no need in accepting winepulse in mainline wine
source tree. It is sufficient just to make it easier to build it separately
from the wine. 

> seriously as a long-term solution. The reason why it hasn't been done is that
> it's a *lot* of work to do so, and so far no one is willing to do it.

Got it. I hadn't had a lot of free time to look at the wine sound drivers
sources and I was thinking that it wouldn't require a lot of changes to wine.
If it really requires a lot of changes then it makes clear why it hadn't been
done so far :-(.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.