Occasional sound drops in Wine via PulseAudio

Wine should have a PulseAudio output plugin. This is a feature request.

What does Pulseaudio support that the sound system for the existing plugins can't do? We have way too many half-working sound plugins already, there should be a good reason before we add and maintain yet another one.

1) Distribution are currently moving over to PulseAudio as default. Fedora 8 already uses it as default sound system, Ubuntu and OpenSuSE plan to do so. When PulseAudio is being used, you can not use ALSA or OSS directly. There are compatibility layers for OSS and ALSA being provided by PulseAudio, but they both increase the latency. The ALSA layer does not work in connection with Wine.

2) When everything works well, nearly all applications using sound will use PulseAudio as sound output. Many already have PulseAudio output plugins, namely Gstreamer, Xine and Mumble. Because of them all using PA, Wine would not have to maintain great amounts of backends.

3) Proper software mixing. Because of 2, software mixing should work fine using almost all software then.

4) Better support for Thin Clients as Pulse Audio has great Networking Support. Many LTSP implentations already using PA.

5) Moving sounds on-the-fly between devices.

This statements are without warranty, but should be true.

Also have a look at http://fedoraproject.org/wiki/Interviews/LennartPoettering

There has already been some discussion here: http://<email address hidden>/msg39145.html

It even seems that someone is already working on it. I will subscribe him.

http://<email address hidden>/msg35153.html

At the moment we aren't much interested in PulseAudio. We have had different sound drivers in Wine and they end up being half baked. It took years to get our current oss and alsa drivers sort of working and even those aren't that great yet. We can't use another audio backend.

Especially games use DirectSound which means direct soundcard access. Right now the current audio situation (partly due to bad sound drivers) is already very bad and we have bad audio quality and latency. An additional layer in between will make it worse.

Pulseaudio should deliver a good replacement for dmix and let Wine and other apps keep Alsa. Apps like Quake4 and Unreal Tournament won't get rewritten to use pulseaudio.

"planning to" is not really an argument.

Please understand that Wine absolutely needs lowlevel low latency soundsupport, otherwise we will get countless reports of
"stuttering audio" and similar.
And audio middlewares are not really known for "low latency".

A framework like arts,esd or pulseaudio will not help,
and most users do not care about network transparency.

If someone wants to write a pulseaudio driver, he should feel free to do so, but he should be aware that just writing a simple 20 line linear PCM out driver is not sufficient.

PA will offer a good latency as soon as some kernel patches flow in. If you need more information, please ask.

I understand your arguments and I think that currently, you are right.

But then, there should be at least some communication with the PA devs in order to make it possible to use Wine using the ALSA backend.

The more distros switch to PA (and they currently are doing so), the more users will complain about "no sound in Wine".

PA will never be an option for gaming in Wine. You're right, we have to get in contact with the PA developers, to make sure PA allows us to bypass it entirely.

"Good latency" is not enough, we need "no latency". Even if PA gets latency down to 50 or even 25 ms it is way too long. Did you ever watch a professional counterstrike player? My (unscientific) estimate is that the (eye,ear) -> hand reaction time is around 100 ms. Adding another 25 ms game -> sound hardware delay is absolutely unacceptable.
CS players say that they feel the difference between a 20 ms ping and a 50 ms network ping when playing online, and I am sure they are right about this.

If a sound server is active by default that needs extra user action to be bypassed then it will make Linux unusable for professional gamers. Gamers do not care about mixing two applications' sounds, since they have only one app anyway.

ARTS surrendered its exclusive control of the sound device when it was not used, and we need at least something like that from PA for proper DirectSound support. A better solution would be if PA passed alsa calls through to the driver without going through its mixer when only one app is using alsa, and transparently enables and disables the mixer if other apps pop up.

> Gamers do not care about mixing two applications' sounds, since they have only one app anyway.

This is not true. Most professional gamers use TeamSpeak / Ventrilo / Mumble to communicate with their team.

The other things are probably true, but I wonder how far the latency will be cut down when the Kernel is compiled with the right patches.

Regarding latency:

=== QUOTE ===

Gustavo then played the latency card: yes, PA increases the latency
over direct hw access. But so does dmix, because it enforces fixed
fragment settings for all apps. What you really want to do (which
however right now is only partially implemented in PA) is allowing
per-stream fragment settings, by scheduling audio based on timer
interrupts instead of sound io interrupts (based on fixed fragment
settings). Those timer interrupts can be dynamically changed so we can
change the wakeup points dynamically during playback without too much
effort. However this needs some kind of kernel support (hrtimers,
HPET), which only has become available very recently and on x86 only
(not even amd64 yet), so until we get this fully implemented a few
months will pass. If we have that however, we basically get the same
PCM pipeline that Vista and MacOS have: a huge mixing buffer managed
by a real-time userspace sound server which allows rewriting at any
time and notifying clients dynamically, scheduled via timer
interrupts. In essence, in the long run we really *need* something
like PA, if we want to provide low latencies (i.e. short fragments ==
frequent interrupts) and low power consumption (i.e. few interrupts ==
huge fragments) at the same time and switch between them
dynamically. Yes, right now, PA increases your achievable latencies a
bit (but just a bit), but in the end we *need* a process that does the
audio scheduling based on timers -- something that PA will then do. Of
course, PA doesn't fully implement yet, which is partially PA's fault
and partially the kernel's fault that sucks when it comes to timers,
right now. We're getting there.

=== /QUOTE === Source: http://<email address hidden>/msg11086.html

Written by Lennart Poettering, PA developer at Red Hat.

Regarding

> Apps like Quake4 and Unreal Tournament won't get rewritten to
> use pulseaudio.

Doesn't Quake4 use SDL? Then, if SDL would offer PA support, Quake4 should work fine, also.

Teamspeak is a good point, yeah. However, often fps gamers sit in the same room, so no need for such a chat app. (Online gaming doesn't allow proper competitive gaming anyway due to high network latencies).

Regarding the latency of dmix and software mixing: Yes, dmix isn't any better, but for people that need highly efficient mixing there is sound hardware that supports hardware mixing(the usual AC97 chips don't support that). Wine currently does not support hardware mixing due to Alsa limitations, but I doubt a sound middleware like PA will fix that. (Lennart Poettering says it is "bullshit" and gives the Intel HDA soundchip as an example. Gamers do not use the HDA and AC97 chips for a reason. Gamers slap Microsoft for disallowing HW mixing in Vista for a reason).

Even with hardware that doesn't do HW mixing, games expect to be able to mix themselves and write the results directly to the card, bypassing any other mixing software.

However, it sounds like PA already does what we want:

===
Gustavo brought up the issue that PA "hogs" the sound device. Sure we
do. The idea is having everything go through PA, so that we can treat
everything the same. However, since there are some APIs that are
notoriously hard to virtualize (e.g. OSS with mmap) and some areas
where you don't want the extra context-switching PA adds (pro audio,
for now), there's now a tool called "pasuspender" which when passed a
command line it will execute that, but before doing so suspend PA's
sound card access and afterwards resume it again. So, prefix your
"quake2" invocation with "pasuspender" and everything should be
fine. Also, we now close all audio devices after 1s of idle time by
default. We do this mostly to save power. However this also has the
side effect of releasing the audio device quickly for other apps. The
drawback of course is that many sound cards generate pops and clicks
everytime you open/close the device (some intel hda for example), but
that can probably be worked around in the drivers (according to
Takashi) and I guess you cannot have everything at the same time, so
power saving is more important for now. In practice you probably
shouldn't notice PA's presence at all -- unless you try to play a ALSA
stream to hw:0 and a PA stream at the same time. And last but not
least, we have been shipping a PA plugin for libasound for a while
now. It's enabled by default in F8 and redirects all ALSA audio to
PA -- unless some borked app hard codes "hw:0" as device name.
===

So we can just stick to Alsa, and the game gets direct access without delays.

> So we can just stick to Alsa, and the game gets direct access without delays.

Only when Wine is being called using pasuspender, which suspends the sound of all other applications using PA.

But you are right, the free-time gamer is probably content using the PA Alsa plugin if it would work. So we can finally sum up that it should be made to work using Wine and that everything should be as it should be then.

The professional gamer would have to use pasuspender.

"Also, we now close all audio devices after 1s of idle time by
default". I don't read this as if pasuspender needs to be called. pasuspender sounds like a way to force PA off, even if some app is using PA. A feature like this was missing from arts: If you can't get direct access for some reason you had to search through all the apps to find the app that kept the sound device hostage.

Okay, sorry, I misunderstood.

Not meaning to be a nuisance, but if this topic is encouraging discussion, how about moving it to the wine-devel mailing list? Bugzilla is not a forum, and not all developers follow bugzilla that closely.

Thank you for subscribing me, Martin.

I won't be making any promises regarding the driver. I still have the code lying around, but it's far from finished.

There's not much I can say about whether it is a good or bad decision to include PA support. But I personally think that software mixing is very important; I'm a laptop user and casual gamer. Last time I tried, PA's ALSA emulation wasn't working in Wine either. (But that was a while ago, and I should try again with 0.9.7.) (Also, OSS emulation worked fine, just with some crackling in the sound.)

Assuming that PA is going to polish it's ALSA emulation, it *might* be a good decision to only support the ALSA API in Wine. But ALSA emulation is also another layer inbetween, and I can't tell how that influences latency, which also seems to be important to many.

*** This bug has been confirmed by popular vote. ***

In Ubuntu Hardy Heron (8.04) Alpha 2, pulseaudio is enable for default.

References:
https://wiki.ubuntu.com/HardyHeron/Alpha2#head-efb28122d420eb09a74d286f3439126dd14bbafd

The new default pulseaudio in Hardy does not work with many non-Gnome programs. I am worried that everyone (Ubuntu, Alsa, Pulse, Wine) is not on the same page. Will try cross-posting bug information.

Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/198453
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/109439

Pulse:
http://www.pulseaudio.org/ticket/198

Alsa:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2601

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

Tom's Wine Patch:
http://www.winehq.org/pipermail/wine-patches/2008-February/050561.html

Skype:
http://forum.skype.com/index.php?showtopic=112021

But wait! There are more! Alsa tells me they have one for Ekiga, and Gnome has one, too.
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=3825
http://bugzilla.gnome.org/show_bug.cgi?id=413552

I dunno if this has been posted before but a PulseAudio developer writes this in his blog:

:::::::::::::

I am not really asking anyone to port their apps to the native PulseAudio API
right now. While I do think the API is quite powerful and not redundant, I also
acknowledge that it is very difficult to use properly (and very easy to misuse),
(mostly) due to its fully asynchronous nature. The mysterious libsydney project is supposed to fix this and a lot more. libsydney is mostly the Dukem Nukem
Forever of audio APIs right now, but in contrast to DNF I didn't really announce it publicly yet, so it doesn't really count. ;-)

But, most importantly: please stop misusing the existing APIs. I am doing my best to allow all current APIs to run without hassles on top of PA, but due to the sometimes blatant misues, or even brutal violations of those APIs it is very hard to get that working for all applications (yes, that means you, Adobe, and you, Skype). Don't expect that mmap is available on all audio devices -- it's not, and especially not on PA. Don't use /proc/asound/pcm as an API for enumerating audio devices. It's totally unsuitable for that. Don't hard code device strings. Use default as device string. Don't make assumptions that are not and cannot be true for non-hardware devices. Don't fiddle around with period settings unless you fully grok them and know what you are doing. In short: be a better citizen, write code you don't need to be ashamed of. ALSA has its limitations and my compatibility code certainly as well, but this is not an excuse for working around them by writing code that makes little children cry. If you have a good ALSA backend for your program than this will not only fix your issues with PA, but also with Bluetooth, you will have less code to maintain and also code that is much easier to maintain.

Or even shorter: Fix. Your. Broken. ALSA. Client. Code. Thank you.

:::::::::::::

http://0pointer.de/blog/projects/lca2008.html

Maybe that's the current way to go for Wine; see that it works together with PA when using the ALSA backend.

Have you tried the esound backend? That works just fine with PulseAudio on Fedora 8.

While it worked for me, there was a delay of ~ 1 second between playing the sound and hearing the sound :(

Well with this patch: http://www.winehq.org/pipermail/wine-patches/2008-February/050561.html commited and a little bit of work on the PulseAudio side, the ALSA Wine plugin should work with PulseAudio. (bug 10910), but on the DirectSound-side of life, it still does not work.

Just for reference, have a look at some comments here:
http://bugs.winehq.org/show_bug.cgi?id=13090

*** Bug 14103 has been marked as a duplicate of this bug. ***

*** Bug 14876 has been marked as a duplicate of this bug. ***

Before this bug gets closed, I want to repeat something I sent to the list:
while those patches, that hit 1.1.3 do help,
they don't fully fix the problem.
Observed with pulseaudio 0.9.11.
With those patches, sound is played, but much faster than it should.
Referring to http://source.winehq.org/git/wine.git/?a=commitdiff;h=944cb7ea15a3e8cbdded643b91ba85acbac827c8 :
when I change period_time from 20000 to 40000, sound seems to be played at correct rate.

(In reply to comment #26)
----

> when I change period_time from 20000 to 40000, sound seems to be played at
> correct rate.
>
That's for playing sound. What about recording sound? Did you test that?

Using what ?
While `aplay -d 3 < /dev/urandom` works nicely,
if you just want to see if the sound works,
I don't think it's what you have in mind.
I use wine mostly to have a look at a few games
(and while I enjoy games, I'm not using them often
and those games I tested were not the ones you'd call timing-reliant).

As my mails seem to have been lost,
I'll repeat their main point:
it seems that period_time is a magic number,
that worked for the person who dropped those patches into the git,
but it doesn't work for me.
My value is a magic number too, it seems to work
for me, but I don't know if there's any reason behind it.
I simply tested a few values, significantly smaller than 20000 didn't make a change, slightly larger wasn't enough, but 40000 seems to be enough.

Now, unless the author will reveal the reason behind those numbers,
this won't help anybody.

A breaking news !!!
With wine 1.1.4, pulseaudio 0.9.11 and today's git of alsa plugins,
sound just works, no patches needed.
It looks like the most important part is the git,
cause the pulse plugin was nearly rewritten.

Well, anyway, pulseaudio author is the one, who submitted those patches,
so let's simply enjoy (and thank him).

Damn, looks like I spoke too soon.
But it did seem to work.
However, when I tried it again today, it failed to.
When I recompiled with period_time changed, it works again.

The only thing that changed between today and the previous test was
that my system load is a lot lighter today, but why should it matter ?
And does that magic number really depend on system load ?

Created an attachment (id=16189)
PulseAudio support for Wine

PulseAudio support for wine. This proves the viability. DSound works very well with low latencies, even over a local network. The code works better than the wine esd driver. WaveIn support is not included (yet) and there is currently no code dealing with connection losses. I'm putting this out there so others can build from it and make improvements as they see fit.

First of all, you mark an attachment as a patch only if it's plain text,
if it's plain text, if it's compressed, there's no point of it.

On a not quite related note, no changes in 1.1.5 with pulseaudio 0.9.12,
still it sometimes works, sometimes not with period_time=20000 and
seems to work every time with period_time=40000.

Created an attachment (id=16246)
PulseAudio support for wine

Not compressed this time :P. Now includes basic WaveIn support as well as some cleanups and improvements to WaveOut. Deals with connection losses and stream errors a little better now.

Hi Art,

Wine hasn't worked for me since Ubuntu introduced Pulse Audio.
I only play a few old games and most of them work horribly with pulseaudio.I have a dual core 1.6 Ghz processor, 1GB RAM, Ati Radeon X1150 video card, so performance on those games shouldn't be a problem.

With the alsa plugin
Counter Strike non-source 1.6 has very low performance 10-15 fps
Disciples II ROTE the game lags a lot, even the mouse moves laggy
Starcraft you can notice some lag.
Heroes III the only game that works good for me.

With the OSS plugin the games play a few times better, but still the performance is bad.

If I disable the sound all games run like before.

The really bad thing is that before pulseaudio most games had good performance, CounterStrike even had better fps than in WINDOWS and lower ping.

So Art can you tell us more about your patch, and if it will fix the pulse audio performance problem?

Also will it be included in wine, because for me the performance drop is a huge drawback from using wine anymore?

Most distributions use Pulseaudio so a solution should be found.

Hello

This patch adds native support for pulseaudio. It should allow better performance of over the esound driver. As for problems with performance, the short answer is, it depends. How are the games seeming to run slow. Personally I have a pentium-m 1.6 gHz, ATI Radeon 7500 32mb, 1gb ram and I can play Max Payne 2 without issue (no pixel shaders thought ;-) ), with audio going over the network or locally.

If the performance slowdown you experience is because of the pulseaudio daemon, I would check it's configuation (how is it accessing the hardware, what's the default sample spec vs the sink sample specs, what resampling algorithm is being used).

On the other hand, if the poor performance is due to windows apps not expecting a large audio buffer, larger than usual latencies, or that wavehdrs will be return monotonically rather than in bursts, this patch will help. The patch's method for returning wavehdrs to the app is based entirely on timing functions rather than stream position estimates or written totals. This ensures that audio data appears played at a consistent rate. In fact, if this is your main problem with audio, this patch will preform better than _any_ of the other drivers, as really, we are lying to the app here.

A waveout app controls how large it's audio buffer is by how many and how large of wavehdrs it queues. Apps do not queue more wavehdrs than this size, thus if no wavehdrs are returned, no new ones will be given. This is a problem if the size of the app's desired buffer is smaller than pulse's prebuffer, as pulse will not start playback until the prebuffer is full. If pulse doesn't start playback, no wavehdr's are returned, no new wavehdr's come in, no new data, prebuffer will never fill, nothing happens. To deal with this if a stall in the prebuffer is detected this code will start the wavehdr releasing clock earlier than when the audio actually starts playing. The upside is apps always work and seem to get the buffer size they want, the downside is that we are actually lying to the windows apps, and there really is an extra bit of latency that they just don't know about. Another upside is that pulseaudio is good at managing latencies.

WaveIn support in this patch is still hack-ish as I wrote and tested it early in the morning.

I have tried your patch but I don't have any PulseAudio choice in the list of drivers, why ? I like PulseAudio so if I can help developing a PulseAudio driver, it will be nice.

Created an attachment (id=16263)
Add pulseaudio to know audio drivers in winecfg

Pulseaudio would not appear in winecfg as winecfg's list of possible audio drivers is static. This patch adds winepulse.drv to winecfg. Without this patch to enable the pulseaudio driver, edit HKCU->Software->Wine->Drivers->Audio to "pulse" (or a comma separated list of drivers, with pulse in front.)

Althought i'm sceptical about the aproach I included the patches in the hacks repo (www: http://repo.or.cz/w/wine/hacks.git ).

Created an attachment (id=16412)
PulseAudio support for Wine

A newer patch here. Much better handling of stream and connection failures, more useful trace information and multiple playback instances per device. Removed wavein support for now.

Created an attachment (id=16753)
Add pulseaudio to build system and stub pulseaudio driver

As I was asked to split this patch up, this is part 1 of 2. This patch adds a pulseaudio driver which only supports listing devices and retrieving device properties.

Created an attachment (id=16754)
Waveout functionality for winepulse

Part 2 of 2. Now should detect and support pulesaudio versions prior to 0.9.11

Created an attachment (id=16977)
new patch

OK, wine 1.1.7, pulseaudio 0.9.13 with all the git patches,
that rawhide took (without them that version is simply broken).

New patch then.
Most of it is updating to alsa 1.0.18 (yes, released today).
In case of waveout.c, I'm not sure whether it should be
snd_pcm_avail or snd_pcm_avail_update.
The only independent change is frames -> 3*frames.
Again, a magic number.

*** Bug 15998 has been marked as a duplicate of this bug. ***

*** Bug 16022 has been marked as a duplicate of this bug. ***

Created an attachment (id=17378)
patch I'm using now

While 3 was enough for some programs, some still failed.
So I simply put a comment on that line and those programs worked.

This worked even with heavy swapping, but I'm not sure how it affects timing.

I'd like to test pulseaudio support, but can't figure out what patches should I apply. Should I use patches from Art Taylor first and from Rafał Mużyło after that or there is another order/way?

Speaking only for myself, I believe the patches are independent of each other. My patches attempt to add a new audio driver winepulse.drv to wine which communicates directly to the pulseaudio server using libpulse. The patches from Rafał Mużyło attempt to make the existing wine audio driver winealsa.drv work better when it is outputting to the alsa-pulse alsa-io-plug which allows most alsa apps to use pulseaudio. I believe both patches can be used at the same time. You can select which method is being used by the registry.

I've already mentioned it in a different bug,
but it's time to do it here.

It seems that with wine 1.1.10, sound just works.

At least it does for me on:
pulseaudio 0.9.13 (patched)
alsa 1.0.18 (lib and driver)
AC'97 (intel8x0)

On the other hand, it seems that people on
0.9.10 complain now about extra echo...

Patch in bug 16416 comment 6 seems to solve the echo problem too.

Created an attachment (id=19505)
winepulse [1 of 2]: Add checks for pulseaudio in configure

The patch is against 1.1.15. Adds checks for libpulse >= 0.9.8 to configure, defines HAVE_PULSEAUDIO=1 if found and tells configure to build dlls/winepulse.drv/Makefile.

Created an attachment (id=19506)
winepulse [2 of 2]: New winmm driver for pulseaudio

This patch does not modify any existing files, it only creates the new winepulse.drv winmm driver under dlls/winepulse.drv. Patch contains pulseaudio support for WaveIn, WaveOut and DirectSound output. To build apply the patches for configure.ac and this one, autoreconf, and build. Once built you have to tell wine to use the pulseaudio driver by setting the registry key HKCU->Software->Wine->Drivers->Audio to "pulse." I have also put these instructions at http://art.ified.ca/?page_id=40 . To see if winepulse.drv is in use or to debug it set the WINEDEBUG environment variable to "+wave,+dspulse"

Please read the comments again: Wine is not going to include new semi-working
sound drivers, what you need to do to improve existing ones to work well with
pulseaudio.

Please test code: this driver is _more_ complete than existing drivers and provides the best possible way for wine to interact with pulesaudio. I stand by that statement. Frankly the existing wine audio drivers are all scary and suffering from rot. Many are outdated, or have been over tweeked over the years. Particularily winealsa.drv, although the most feature-full, needs a good shake.

Sorry if I over reacted, but let me restate why winepulse should be seriously considered:

Reading the comments reveals:

"If someone wants to write a pulseaudio driver, he should feel free to do so,
but he should be aware that just writing a simple 20 line linear PCM out driver
is not sufficient." - Done

Second, this code does _not_ inhibit the possibilities of improving winealsa.drv and alsa-pulse's interactions, or the ability for hard-core gamers to use alsa mmap (with pasuspender.)

Third, this code allows for devices to be selected by the applications. Audio apps can choose which sinks or sources to play or record from the pulse server.

Fourth, code does not require that a new connection to the server and new audio stream be made every call of waveOutReset et a la unlike when we try to use pulseaudio behind the alsa api.

Fifth, it is possible to get audio latency down to 25ms in directsound, maybe less depending on your pulseaudio server. We are talking one memcpy removed from hardware for local audio, and the memcpy happens in the realtime scheduled pulseaudio daemon.

Sixth, wavehdr's are returned to the app based on a timer which is close to actual playback time, causing a more smooth and accurate playback for applications which use when a wavehdr is returned for timing info. This is not the case for wineesd.

I suggest to just post it for review to either wine-patches or wine-devel.

Created an attachment (id=19513)
WINEDEBUG=+wave,+dspulse wine hl -game cstrike

Sound doesn't work if the registry key “Audio” in "HKCU\Software\Wine\Drivers" is set to "pulse" with CounterStrike 1.6 NonSteam. I'm running on Fedora 10 i386 with pulseaudio 0.9.14 on WINE 1.1.15 patched with winepulse-0.17.patch and winepulse-0.17-configure.ac.patch

Wild guess: did you regenerate configure (./autogen.sh, autoconf) before rebuilding?

(In reply to comment #57)
> Wild guess: did you regenerate configure (./autogen.sh, autoconf) before
> rebuilding?
>
I did autoreconf after applying both patches as described at http://art.ified.ca/?page_id=40

OK. I was just making sure we aren't missing something obvious. Cheers!

Seems in that log that the pulseaudio server crashed or killed the connection. I would suggest first testing without using capture/wavein and seeing if the problem is repeatable. I do confess to never having run counterstrike ever in my life. I would like to hear more about this, but to avoid bugspam we should move this off bugzilla by either emailing me (and maybe cc wine-devel) or the wine forums.

Created an attachment (id=19517)
Patch to add WinePulse in the winecfg, all languages

A little contribution, to make it easier.

Can you create a .deb with wine and your patch applied.
I would really like to test it, but I really don't like compiling things.
Ever since PulseAudio I can't play any of my favorite games on linux because of huge performance loss.

(In reply to comment #62)
> Can you create a .deb with wine and your patch applied.
> I would really like to test it, but I really don't like compiling things.
> Ever since PulseAudio I can't play any of my favorite games on linux because of
> huge performance loss.
>

If you would like to test PulseAudio without compiling thing then from some time there is non official wine-pulseaudio-1.1.12-1.fc10.rpm for Wine 1.1.12 in Fedora 10.

Patches which are present in Fedora 1.1.14 rpm do not work for me.

I have posted a new version of the winepulse patch on my blog at http://art.ified.ca/?page_id=40 . I would not suggest using the fedora RPMs. No one from red-hat has been in contact with me and I have no idea how old those patches are (methinks they are ancient.) That said, if someone from red-hat wishes to contact me I'll be more than happy to talk :) . I'm not sure how old the patches to the wine-hacks git repository are as well. As for building debs for debian I'm not sure I know how to do that. Personally I run gentoo and have little (but some) experience with Debian / Ubuntu. I develop with the git versions of both the pulseaudio and wine. Best of luck. For people who experience problems with directsound I suggest testing with "hardware acceleration" set to both "emulation" and "full" in winecfg.

Not sure how recent the Fedora patches are, but I know they were added at the time 1.1.12 was built:
http://cvs.fedoraproject.org/viewvc/rpms/wine/devel/

I've tested the winepulse driver on Mandriva cooker, and I must say that it works very well, even better than ALSA driver : better audio quality and sound glitches disappeared. Very nice work !
I've tested in on Half Life 2 and Dungeon Keeper 2.

I think the patches should be integrated into main tree, since this is the end of sound nightmares on modern main distros which have pulseaudio as default.

(In reply to comment #67)
> works very well, even better than ALSA driver : better audio quality and sound
> glitches disappeared. Very nice work !
You want to say Wine->Pulse->ALSA works better then Wine->ALSA->Pulse->ALSA? Well DOH! How about Wine->ALSA? Any better?

(In reply to comment #68)
> You want to say Wine->Pulse->ALSA works better then Wine->ALSA->Pulse->ALSA?
> Well DOH! How about Wine->ALSA? Any better?

Please refrain from unconstructive comments on this bug report in the future. It is just noise.

(And I am sorry to be making noise myself. I will not say this a second time.)

This is a point about inclusion of this driver into Wine. It's been stated why it's a bad idea. I've explained AGAIN why. Unless person comparing apples to apples any arguments like "gee it works better then broken ALSA driver" are not going to cut it.

As for the patches themselves:
One of the core functions is not properly implemented (not sure how anything really works for you especially in games where timing of audio events is really critical):

+static HRESULT WINAPI IDsDriverBufferImpl_GetPosition(PIDSDRIVERBUFFER iface,
+ /* These values are fake, and must remain so */
+ if (lpdwPlay)
+ *lpdwPlay = (This->buffer_read_offset + This->buffer_length - This->fraglen * 5) % This->buffer_length;
+ if (lpdwWrite)
+ *lpdwWrite = This->buffer_read_offset;

This is wrong (obviously needs more work):
+static HRESULT WINAPI IDsDriverImpl_CreateSoundBuffer(PIDSDRIVER iface,
+ That->buffer = pa_xmalloc0(That->buffer_length);

+ if (That->buffer)
+ HeapFree(GetProcessHeap(), 0, That->buffer);
+ if (*ippdsdb)
+ HeapFree(GetProcessHeap(), 0, That);

At last, comments on the code itself :D

For the second example cited from wine/dlls/winepulse.drv/dsoutput.c I'm not sure what you are trying to show, it looks alright to me. The first instance That->buffer = pa_xmalloc0(That->buffer_length) allocates the buffer through the libpulse function pa_xmalloc0 which initializes That->buffer to 0 and in the case off OOM terminates the application. Should HeapAlloc be used in this instance instead? As for the HeapFree() calls on That->buffer and *ippdsdb (which is the value of That), those calls are only reached on error:

    return DS_OK;

err:
    pa_threaded_mainloop_lock(PULSE_ml);
    if (That->stream) {
 if (pa_stream_get_state(That->stream) == PA_STREAM_READY)
     pa_stream_disconnect(That->stream);
 pa_stream_unref(That->stream);
 That->stream = NULL;
    }
    pa_threaded_mainloop_unlock(PULSE_ml);
    if (That->buffer)
 HeapFree(GetProcessHeap(), 0, That->buffer);

    if (*ippdsdb)
 HeapFree(GetProcessHeap(), 0, That);
    *ippdsdb = NULL;
    WARN("exiting with failure.\n");
    return ret;
}

For the first example, the answer is more difficult. It is very hard to place the play pointer, so we set it to be just lagging the write cursor by how much we commit at a time to pulse. The location of This->buffer_read_offset is always correct. It is always a multiple of the fragment size, just like it is for WaveOut Dsound HEL.

I'm waiting until WaveIn support works better before submitting the patches for inclusion because I think that is the right thing to do. Comments? As an aside note, I endorse the fedora packages, if that means anything ;)

Please keep this bug report on topic: better interaction between pulseaudio and wine. You cannot believe that all users will stop using pulseaudio just for the sake of wine. In the long run as pulse becomes and more common and most all applications support it, as current trends suggest, having to manually deal with killing pulseaudio for wine apps to get sound will not look bad for pulseaudio but for wine as it will not "just work." Please be constructive. Commenting on the code is helpful, discrediting the intelligence of people trying the patches is not.

(In reply to comment #71)
> At last, comments on the code itself :D
You'll get much more of them if you send patches (a series of patches not one big huge as you have here that's impossible to review) to wine-patches ML as RFC.

> For the second example cited from wine/dlls/winepulse.drv/dsoutput.c I'm not
> sure what you are trying to show, it looks alright to me. The first instance
> That->buffer = pa_xmalloc0(That->buffer_length) allocates the buffer through
> the libpulse function pa_xmalloc0 which initializes That->buffer to 0 and in
> the case off OOM terminates the application. Should HeapAlloc be used in this
> instance instead?
You can't allocate something via one method and free it via another one. pa_xmalloc0 and HeapAlloc do not allocate the same memory.

> As for the HeapFree() calls on That->buffer and *ippdsdb
> (which is the value of That), those calls are only reached on error:
Don't check for ptr != NULL before freeing it. HeapFree does that already.

No one shown arguments how pulseaudio any different then most other sound servers (other then minor cosmetic fixes accumulated over the years of arts/esd neglect). Any sound server is just that - a sound server that introduces extra latency and restricts direct sound access. If it can not be disabled programmatically then it's the sound server's bug, not application's that want to access sound directly.

> Please keep this bug report on topic: better interaction between pulseaudio and
> wine.
If you want to make it better fix pulseaudio to be properly suspendable when another applications needs ALSA. Not adding more layers on top. Or at least fix those layers to work properly.

This bug`s name is "Wine should support PulseAudio" and 37 people have already voted that they want it on their wine.
If anyone don`t like pulse, this is not a place for him, especially because OTHER PEOPLE USE THEIR TIME TO SOLVE IT.
On the other hand code discussions are welcome :)

As was stated many times "Wine should support PulseAudio" means that
*existing* sound drivers in Wine should be fixed to work better with
PulseAudio, introducing a new driver is not a solution of any kind.

(In reply to comment #74)
> As was stated many times "Wine should support PulseAudio" means that
> *existing* sound drivers in Wine should be fixed to work better with
> PulseAudio, introducing a new driver is not a solution of any kind.

As an end user, I disagree. PulseAudio is the only sound solution that works properly with my sound setup (ALSA can't handle 6-channel dmixing on my sound card) and I use PulseAudio's ability to set different levels for different streams all the time. I am using PulseAudio very successfully for every other multimedia application in my system. Having to suspend PulseAudio just for wine is an annoyance. Not being able to adjust the sound levels for wine without affecting the rest of the system is an annoyance. Having to manually kill wineserver since my games lock up when I try to run winealsa through a "type pulse" device is an annoyance.

The winealsa driver may need some love as well, but the native PulseAudio driver is the one that I am waiting to use.

My personal opinion is that if Wine is going to provide any real support for pulseaudio that a new driver is suitable, like with NAS or ESD. However, it would be nice if pulseaudio would play nice with winealsa (which is not the case currently, nor is it an issue with Wine). If pulseaudio improves its ALSA layer (e.g. making it work beyond "here's a stream I want you to play", I suspect buffering issues are the main problem), Wine may not need any special work at all.

If Wine developers are going to commit a new audio driver, it should be (almost) complete. It's been said before, but we don't need another half-a*** ... I mean half-working audio driver in Wine (like jack, NAS or ESD).

It has also been argued that the *nix world doesn't need another sound daemon. I agree with that, but pulse still exists (unlike arts and ESD), and it would be nice (at least in theory) if Wine could work seamlessly with it. pulse has the capacity to work seamlessly for most ALSA and OSS applications, but its support is not complete enough to keep Wine, Skype and some other applications/games happy.

(In reply to comment #74)
> As was stated many times "Wine should support PulseAudio" means that
> *existing* sound drivers in Wine should be fixed to work better with
> PulseAudio, introducing a new driver is not a solution of any kind.

That day is almost here. Using PulseAudio 0.9.15-test5 git and the latest wine
git one can get audio to work through winealsa.drv using the pulse alsa plugin
with reasonable success. That said, it makes wine a second-class citizen of
pulseaudio. Some of it's best features, such as the glitch-free playback method
(dynamic hardware buffer size), latency handling and complex audio configurations cannot be exposed or efficiently used.

(In reply to comment #72)
> If you want to make it better fix pulseaudio to be properly suspendable when
> another applications needs ALSA.

pasuspender <command> can do exactly that. This is through the functions
pa_context_suspend_sink_by_index() and pa_context_suspend_source_by_index with
PA_INVALID_INDEX as an argument.

[quote]Wine->Pulse->ALSA works better then Wine->ALSA->Pulse->ALSA?
[/quote]
Wine->Pulse->ALSA sounds a lot better for me.

Sure any sound server also has disadvantages. But Pulse is there per default in the majority of the current LINIX desktops and this is for good reasons. Gnome, KDE, XFCE all use Pulse. Thus it is not just one more sound server but currently the sound server for LINUX.

There really should be no need for Wine to suspend Pulse.

It should only be necessary as an extra option for special requirements but not for the average user.

Thus it is no question for me that Wine needs a Puls audio driver. The question is if there is somebody willing and capable of writing one with sufficient quality and support.

This seems to be the case. Thus supporting the people who write the driver would be much more efficient then arguing against it.

That there would be much less need for a Pulse driver if Pulse should improve the ALSA layer is not an argument against a Pulse driver.

I have to second Volker's opinion. I'm using an Alesis IO|2 USB sound interface was designed for musicans. As such, it does not provide software mixing - just 2 outputs fixed to 24bits with 48/44.1kHz. Since ALSA does NOT support software mixing on that device for some reason, I decided to go via PulseAudio, and as of today, it is supported by most applications I use.

Since it would not be possible to use VirtualBox and WINE software (and even Firefox with Flash Plugins) at the same time since all three are open virtually all day, it absolutely makes sense to support PulseAudio.

From an end user's point of view, I do not care how it works - it just should work. This is not the case with ALSA and OSS, maybe it would work somehow if I would switch to another soundcard, but that's not a good solution either.

I don't mind if the PulseAudio-Support has higher latency issues - a bad solution is often better than no solution at all.

You may try to make this work from the other way around: request PulseAudio
to support Wine properly.

(In reply to comment #78)
> Sure any sound server also has disadvantages. But Pulse is there per default in
> the majority of the current LINIX desktops and this is for good reasons. Gnome,
> KDE, XFCE all use Pulse. Thus it is not just one more sound server but
> currently the sound server for LINUX.

Big falsehood here. Gnome and KDE on *some* distributions (Ubuntu, Fedora, Mandriva come to mind) use pulse by default. They are all capable of using ALSA (with dmix if required) directly. XFCE does not use pulse, nor does xubuntu from what I've heard.

(In reply to comment #78)
> There really should be no need for Wine to suspend Pulse.
>
> It should only be necessary as an extra option for special requirements but not
> for the average user.

Pulseaudio itself is a special requirement because its ALSA layer is broken.

(In reply to comment #78)
> Thus it is no question for me that Wine needs a Puls audio driver. The question
> is if there is somebody willing and capable of writing one with sufficient
> quality and support.
>
> This seems to be the case. Thus supporting the people who write the driver
> would be much more efficient then arguing against it.
>
> That there would be much less need for a Pulse driver if Pulse should improve
> the ALSA layer is not an argument against a Pulse driver.

Yes it is. One of the main points about pulseaudio is that it's meant to work with <insert sound system here> without the application needing modifications. This is true for the majority of ALSA/OSS applications. Wine doesn't *need* a pulse driver if:
1) winealsa is improved to work better with current pulseaudio
2) pulseaudio is improved to have a fully working ALSA compatibility layer

Both of these options have the advantage that no new driver needs to be included and maintained.

I can confirm that these patches work very well for me.

Until now, this seems to be the only way to get a Wine game and a native program (e.g. a VoIP client like Mumble) working with sound simultaneously.
Imagine the stupidity of the situation before: I had to chose if I either wanted to hear the people I'm playing with speaking OR ingame sound.

Fedora has been shipping those patches for a long time now and I did not run into any problem except that sound just works fine - no matter if I listen to music or not. Output is set to ALSA.

Well, I'm still trying to improve the patches in my spare time as a slight hobby. Time has just been kind of short because of travel and work. If somebody has a good suggestion of a simple Directsound Capture application to test with other than the wine directsound tests I would appreciate it.

Some were asking for binary packages. Well, here you are.
I created .debs with the WinePulse patches (currently based on Wine 1.1.21) for Ubuntu Jaunty in my PPA (https://launchpad.net/~nh2/+archive/ppa).
Feel free to test, link or copy them - whatever you want.
(You may add them via sources.list or just download the deb package; they might work well on Debian, too.)

As a coment to people suggesting suspending Pulse is the solution - a lot of people play WoW with a Ventrilo client and need to hear the sound from *both*, also it is common to have some relaxing music in the background from a non-Wine source. Pulse and DMix can provide that, but DMix is a pain to configure, while Pulse looks to be nicely preconfigured out-of-the-box in latest distributions, so supporting such mode of operation by default would be very useful.

*** Bug 18740 has been marked as a duplicate of this bug. ***

http://0pointer.de/blog/projects/guide-to-sound-apis.html

If we want PulseAudio to work well, we have to limit ourselves to the safe
subset of the ALSA API.

DONTS:

    * Do not use "async handlers", e.g. via snd_async_add_pcm_handler() and
friends. Asynchronous handlers are implemented using POSIX signals, which is a
very questionable use of them, especially from libraries and plugins. Even when
you don't want to limit yourself to the safe ALSA subset it is highly
recommended not to use this functionality. Read this for a longer explanation
why signals for audio IO are evil.
    * Do not parse the ALSA configuration file yourself or with any of the ALSA
functions such as snd_config_xxx(). If you need to enumerate audio devices use
snd_device_name_hint() (and related functions). That is the only API that also
supports enumerating non-hardware audio devices and audio devices with drivers
implemented in userspace.
    * Do not parse any of the files from /proc/asound/. Those files only
include information about kernel sound drivers -- user-space plugins are not
listed there. Also, the set of kernel devices might differ from the way they
are presented in user-space. (i.e. sub-devices are mapped in different ways to
actual user-space devices such as surround51 an suchlike.
    * Do not rely on stable device indexes from ALSA. Nowadays they depend on
the initialization order of the drivers during boot-up time and are thus not
stable.
    * Do not use the snd_card_xxx() APIs. For enumerating use
snd_device_name_hint() (and related functions). snd_card_xxx() is obsolete. It
will only list kernel hardware devices. User-space devices such as sound
servers, Bluetooth audio are not included. snd_card_load() is completely
obsolete in these days.
    * Do not hard-code device strings, especially not hw:0 or plughw:0 or even
dmix -- these devices define no channel mapping and are mapped to raw kernel
devices. It is highly recommended to use exclusively default as device string.
If specific channel mappings are required the correct device strings should be
front for stereo, surround40 for Surround 4.0, surround41, surround51, and so
on. Unfortunately at this point ALSA does not define standard device names with
channel mappings for non-kernel devices. This means default may only be used
safely for mono and stereo streams. You should probably prefix your device
string with plug: to make sure ALSA transparently reformats/remaps/resamples
your PCM stream for you if the hardware/backend does not support your sampling
parameters natively.
    * Do not assume that any particular sample type is supported except the
following ones: U8, S16_LE, S16_BE, S32_LE, S32_BE, FLOAT_LE, FLOAT_BE, MU_LAW,
A_LAW.
    * Do not use snd_pcm_avail_update() for synchronization purposes. It should
be used exclusively to query the amount of bytes that may be written/read right
now. Do not use snd_pcm_delay() to query the fill level of your playback
buffer. It should be used exclusively for synchronisation purposes. Make sure
you fully understand the difference, and note that the two functions return
values that are not necessarily directly connected!
    * Do not assume that the m...

Is there any hope that the list of DONTS in Scott Richies bug report:
   http://bugs.winehq.org/show_bug.cgi?id=18740

And the analysis of Roderick Colenbrander in
   http://www.winehq.org/pipermail/wine-devel/2009-June/076112.html

brings Wine any further on this topic?

"I have quickly checked the code and this are I think some of the
'easy' DONTs we violate:
- we use snd_config_xxx(), this is replaceable by snd_device_name_hint()
- we use snd_card_xxx(), this can be replaced by snd_device_name_hint()
- we hard code device strings (e.g. plughw0)
- we use snd_pcm_avail_update and snd_pcm_delay
(there might be some more but those are less trivial to check)

The most critical are the following:
- Do not assume that all devices support MMAP style buffer access.
- Do not assume that the hardware pointer inside the (possibly mmaped)
playback buffer is the actual position of the sample in the DAC. There
might be an extra latency involved.
- Do not try to recover with your own code from ALSA error conditions
such as buffer under-runs. Use snd_pcm_recover() instead.
- Do not touch buffering/period metrics unless you have specific
latency needs. Develop defensively, handling correctly the case when
the backend cannot fulfill your buffering metrics requests. Be aware
that the buffering metrics of the playback buffer only indirectly
influence the overall latency in many cases. i.e. setting the buffer
size to a fixed value might actually result in practical latencies
that are much higher.

Especially the first one direct sound is all about direct card access
and hence mmap ..

Roderick
"

(In reply to comment #86)
> As a coment to people suggesting suspending Pulse is the solution - a lot of
> people play WoW with a Ventrilo client and need to hear the sound from *both*,
> also it is common to have some relaxing music in the background from a non-Wine
> source. Pulse and DMix can provide that, but DMix is a pain to configure, while
> Pulse looks to be nicely preconfigured out-of-the-box in latest distributions,
> so supporting such mode of operation by default would be very useful.

dmix should not require configuration. It should Just Work(TM) with default settings (i.e. no asound.conf or .asoundrc files).

Created an attachment (id=21805)
winepulse [2 of 2]: Winmm driver for pulseaudio

Adds winmm driver dlls/winepulse.drv providing support for audio playback and capture from pulseaudio. See comment 50 for the required configure script checks. See comment 61 for adding support to winecfg. See http://art.ified.ca/?page_id=40 for more information.

(In reply to comment #91)
> Created an attachment (id=21805) [details]
> winepulse [2 of 2]: Winmm driver for pulseaudio

Adding such an attachment is wrong and useless. Please keep this separate
from this bug, since
1. this will never be committed to WineHQ (the reasons are mentioned
numerous times in this bug)
2. bugzilla is not an appropriate storage place for not acceptable patches

(In reply to comment #92)

> 1. this will never be committed to WineHQ (the reasons are mentioned
> numerous times in this bug)
Only comments against the _inclusion_ of such a driver are:
comment 4 - assumes the cassical view of audio hardware (what about USB? Bluetooth headsets? Networked? Hotplugged? Device change-on-fly?)
comment 6 - assumes that the only use of wine is for games. What about media players? Audio development environments? Telephony/VoIP?
comment 52 - claims non-existent or non-factual previous comments as proof

"Serious gamers" can always continue to use direct alsa. This is in no way changed by the inclusion of a pulse winmm driver.

The text of this bug is "Wine should have a PulseAudio output plugin" not "Wine should clean up its alsa code"

Using a pulseaudio wine driver it is easy for me to capture audio from live playback or hardware inputs by recording software. This is not easy under alsa. Multiple stream instances per device in both directions are supported. Easy network transparency, better hardware buffer control, better volume control. All are possible.

I personally have been contacted by many wine users who have championed my efforts and offered support. I cannot believe that a project the size of wine would allow the misguided best interests of few to alienate users.

(In reply to comment #92)
> (In reply to comment #91)
> > Created an attachment (id=21805) [details] [details]
> > winepulse [2 of 2]: Winmm driver for pulseaudio
>
> Adding such an attachment is wrong and useless. Please keep this separate
> from this bug, since
> 1. this will never be committed to WineHQ (the reasons are mentioned
> numerous times in this bug)
> 2. bugzilla is not an appropriate storage place for not acceptable patches

There are plenty of "hacks" floating around bugzilla. This patch is actually useful, there is really no need to just shrug it off.
It should probably be uploaded on hacks.git, as well.

(In reply to comment #92)
> Adding such an attachment is wrong and useless. Please keep this separate
> from this bug, since
> 1. this will never be committed to WineHQ (the reasons are mentioned
> numerous times in this bug)
> 2. bugzilla is not an appropriate storage place for not acceptable patches

Please stop referencing these dummy reasons and admit that Codeweavers is going to make its next product with "exclusive" PulseAudio suport. Art sounds absolutely sane - PulseAudio has its demand between Wine users and you know it. I'm sick of ALSA plugin for PulseAudio and using Wine with PulseAdio patches. Thank you Art for your efforts.

(In reply to comment #95)
> (In reply to comment #92)
> > Adding such an attachment is wrong and useless. Please keep this separate
> > from this bug, since
> > 1. this will never be committed to WineHQ (the reasons are mentioned
> > numerous times in this bug)
> > 2. bugzilla is not an appropriate storage place for not acceptable patches
>
> Please stop referencing these dummy reasons and admit that Codeweavers is going
> to make its next product with "exclusive" PulseAudio suport. Art sounds
> absolutely sane - PulseAudio has its demand between Wine users and you know it.
> I'm sick of ALSA plugin for PulseAudio and using Wine with PulseAdio patches.
> Thank you Art for your efforts.

You're free to compile Wine with Puleaudio drivers, the source is there. The PulseAudio driver won't be accepted as is for the reasons mentioned.

-A volunteer wine developer with no Codeweavers' ties

(In reply to comment #95)
> Please stop referencing these dummy reasons and admit that Codeweavers is going
> to make its next product with "exclusive" PulseAudio suport.
I'm pretty sure we won't.

You could of course try submitting the patch anyway and watch it drop. Last time someone submitted this patch Michael Stefaniuc actually reviewed part of it (http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html). As far as I can see the issues he brought up aren't even fixed in this version.

(In reply to comment #95)
> Please stop referencing these dummy reasons and admit that Codeweavers is going
> to make its next product with "exclusive" PulseAudio suport.

Please stop thinking that other people tend to do what you do think is
appropriate by your own merits.

> Art sounds
> absolutely sane - PulseAudio has its demand between Wine users and you know it.

Please carefully re-read all the comments in this bug report from the very
start.

> I'm sick of ALSA plugin for PulseAudio and using Wine with PulseAdio patches.

Patches are always welcome.

(In reply to comment #98)
> Please carefully re-read all the comments in this bug report from the very
> start.

Just did it. There are 2 types of comments here:
1) From users who got their stuff working with winepulse.
2) From developers speaking about a)hardcore gaming and b)redundant code.

a)References to "hardcore" gamers make me smile, they use Windows or native games. Btw didn't Vista bury DirectSound?
b)Technically you are right, there is no reason to make something already done.
There is very interesting comment #89 pointing to http://www.winehq.org/pipermail/wine-devel/2009-June/076112.html.

Quote:
>> > First, I talked with a Pulseaudio expert about what we can do to make
>> > things work better. He said that if we want good compatibility we will
>> > need our ALSA stack to use the Pulseaudio safe subset:
>> > http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a
>> > metabug tracking this here:
>> > http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset
>> > can cause most problems with stuttering or even complete dropoff.

So, your opinion is that someone has to rewrite ALSA stack in Wine to close this bug. Fine. Any ideas when?
Why not to use native backend when it solves the problem? End users are interested only in convenience and stability.

<offtopic> I wonder why all the ancient sound backends still live in the code tree. Doesn't ALSA and Jack cover all user needs? <offtopic/>

In my opinion http://bugs.winehq.org/show_bug.cgi?id=18740 is not a DUPREC of this message and hence should be reopened.

This message here is about getting a PulseAudio driver in Wine.

The other message is about using the known save ALSA API for the ALSA driver.

Both could help to change the situation for the better.

Force the people to switch of PulseAudio until PulseAudio supports the complete ALSA API flawlessly is not an option. You should really read
http://0pointer.de/blog/projects/guide-to-sound-apis.html
to understand that this will never happen.

Once Wine uses the known save ALSA API and there are still problems with PulseAudio I'm sure that the colleagues from PulseAudio are willing to iron out the remaining issues.

PulsAudio is the most important sound system on contemporary LINUX systems. It doesn't end with Mandriva, Fedora and Ubuntu. ESD e.g. is virtually dead.

I suggest to reopen bug 18740 and discuss here what is needed to get the PulseAudio driver into Wine.

Developers should support each other instead of running useless discussions. The situation is somewhat similar to the DIB engine saga and is not helpful for Wine on the long run.

(In reply to comment #99)
> So, your opinion is that someone has to rewrite ALSA stack in Wine to close
> this bug. Fine. Any ideas when?

As was pointed out in the recent wine-devel topic, there's not anyone actively maintaining the sound code. Volunteers/patches would be welcome to do this work.

> <offtopic> I wonder why all the ancient sound backends still live in the code
> tree. Doesn't ALSA and Jack cover all user needs? <offtopic/>

People forget that wine is used on more than just Linux...OpenSolaris, for instance, has no support for ALSA and depends on OSS.

(In reply to comment #101)
> As was pointed out in the recent wine-devel topic, there's not anyone actively
> maintaining the sound code. Volunteers/patches would be welcome to do this
> work.

1. The Wine maintainers want volunteers/patches for the sound code.
2. Art voluntarily writes a very popular patch to the sound code.
3. The Wine maintainers tell Art to go away and take his patches with him.

Maybe Wine needs to try some other way of attracting new maintainers?

(In reply to comment #102)
> (In reply to comment #101)
> > As was pointed out in the recent wine-devel topic, there's not anyone actively
> > maintaining the sound code. Volunteers/patches would be welcome to do this
> > work.
>
> 1. The Wine maintainers want volunteers/patches for the sound code.
> 2. Art voluntarily writes a very popular patch to the sound code.
> 3. The Wine maintainers tell Art to go away and take his patches with him.
>
> Maybe Wine needs to try some other way of attracting new maintainers?

Adding a large new feature != maintaining old stuff.

Getting some smaller fixes in and proving you know what you're doing in the wine source code would help with getting the pulseaudio driver in.

As has been said before, rather than adding new features and causing new regressions, let's start by fixing the easy stuff first, by making winealsa behave better.

(In reply to comment #100)
> In my opinion http://bugs.winehq.org/show_bug.cgi?id=18740 is not a DUPREC of
> this message and hence should be reopened.
>
> This message here is about getting a PulseAudio driver in Wine.

The original post was, but it has also become related to getting winealsa to talk to pulse better, hence the DUPLICATE.

> Force the people to switch of PulseAudio until PulseAudio supports the complete
> ALSA API flawlessly is not an option. You should really read
> http://0pointer.de/blog/projects/guide-to-sound-apis.html
> to understand that this will never happen.

Blogs are not generally good references for unbiased information on any subject, however there is some very interesting information in this article.
1) "PulseAudio is not useful in professional audio production environments."
2) "I want to do professional audio programming, hard-disk recording, music synthesizing, MIDI interfacing! Use JACK and/or the full ALSA interface."
3) "I want to write audio software for the plumbing layer! Use the full ALSA stack."

Wine has to be able to provide a professional-quality audio system for those apps and users who need it. Though this does not impair the inclusion of a pulseaudio driver for those who *don't* need professional audio, point #2 implies that Pulseaudio support will be crippled or insufficient even for more common tasks.

I also suspect that Wine fits into the #3 category. Remember that Wine is not a regular application but a compatibility layer between win32 and Unix-likes. By definition, it does weird stuff.

> Once Wine uses the known save ALSA API and there are still problems with
> PulseAudio I'm sure that the colleagues from PulseAudio are willing to iron out
> the remaining issues.

Once someone proves that it is even possible for Wine to use *only* the safe ALSA API for everything (ideally with patches), this might be a valid point to argue.

> PulsAudio is the most important sound system on contemporary LINUX systems. It
> doesn't end with Mandriva, Fedora and Ubuntu. ESD e.g. is virtually dead.

Pulseaudio is NOT the most important sound system on Linux; ALSA is (some would argue OSS is, but they usually mean OSS4 which is not included in kernel upstream). You couldn't have sound daemons without the ALSA (or OSS) drivers and (in the case of ALSA) the userspace libraries supporting them.

ALSA is guaranteed (barring user fiddling) to be installed with software mixing capabilities superior to Pulseaudio (as in not restricting to the "safe" ALSA call subset) on all Linux systems. OSS is virtually guaranteed to be available on other Unix-likes (coreaudio for MacOSX, I believe). Pulseaudio is still at best an optional extra for most, and probably should still be optional for everyone using Mandriva, Fedora and Ubuntu due to the number of problems with the architecture.

Pulseaudio is a return to the ancient, pre-dmix-by-default architecture of driver + daemon (that produced the now dead esd and arts daemons) to provide software mixing to cards that don't have hardware mixing. It SHOULD have been a drop-in replacement for dmix, but it's far from it.

Long post. Short version is: Pulseaudio driver is uns...

> Pulseaudio is a return to the ancient, pre-dmix-by-default architecture of
> driver + daemon (that produced the now dead esd and arts daemons) to provide
> software mixing to cards that don't have hardware mixing. It SHOULD have been a
> drop-in replacement for dmix, but it's far from it.

Pulseaudio is far superior to dmix from the end-user functionality - there is a trivial interface provided to adjust volume for each application individually with a live feed of sound level alongside it to see the effect, applications can be transferred from one sound to another without interrupting playback and with no need to support this transition in any way in the application itself, this includes hot-plug support for sound devises such as usb headphones, bluetooth headsets and soundcards connected to remote computers. Try running 'padevchooser' on Ubuntu 9.04 and explore the options there to see what I am talking about.

I was a sceptic of PA seeing it as just another ESD replacements, but the fact is PulseAudio is much more - it has finally brought real and usable control over the sound in Linux systems. All other options that we currently have in Linux do not even come close.

JACK is only needed for sound editing, where you must have guaranteed real-time latency (which Wine does not provide anyway) and it is possible that FPS players could benefit by disabling PA and using ALSA directly to gain a few miliseconds in audio latency. However for the rest of Wine users PulseAudio is the ultimate option in usability.

(In reply to comment #105)
> > Pulseaudio is a return to the ancient, pre-dmix-by-default architecture of
> > driver + daemon (that produced the now dead esd and arts daemons) to provide
> > software mixing to cards that don't have hardware mixing. It SHOULD have been a
> > drop-in replacement for dmix, but it's far from it.
>
> Pulseaudio is far superior to dmix from the end-user functionality

Not for Wine (currently), nor is that an issue relating to this bug. It's not developer-friendly. Your discussion of end-user features is irrelevant to this discussion. It is still a sound daemon, with all the limitations thereof (e.g. no hardware mixing), and plug pulse still SHOULD have been a drop-in replacement for dmix.

> I was a sceptic of PA seeing it as just another ESD replacements, but the fact
> is PulseAudio is much more - it has finally brought real and usable control
> over the sound in Linux systems. All other options that we currently have in
> Linux do not even come close.

So fix it. Write a per-stream volume control plugin for ALSA/dmix or JACK.

> JACK is only needed for sound editing, where you must have guaranteed real-time
> latency (which Wine does not provide anyway)

Wine's support for latency is not the real issue here, nor are you correct about JACK *only* being needed for sound editing, but that's all off-topic here.

> and it is possible that FPS
> players could benefit by disabling PA and using ALSA directly to gain a few
> miliseconds in audio latency. However for the rest of Wine users PulseAudio is
> the ultimate option in usability.

Not when it doesn't work. And "a few milliseconds" is much more significant than you may think, especially when it's adding to already existing latency issues (which is the current problem with winealsa and plug pulse).

Regardless, you're not adding much (if anything) to this discussion ... Which option are you voting for, the "winepulse driver" option or the "fix winealsa" option?

(In reply to comment #106)
> Regardless, you're not adding much (if anything) to this discussion ... Which
> option are you voting for, the "winepulse driver" option or the "fix winealsa"
> option?

There's no vote going on! Everyone agreed winealsa needs to be fixed. What still is undetermined is whether, once fixed, there will still be a need for a winepulse driver.

(In reply to comment #107)
> (In reply to comment #106)
> > Regardless, you're not adding much (if anything) to this discussion ... Which
> > option are you voting for, the "winepulse driver" option or the "fix winealsa"
> > option?
>
> There's no vote going on! Everyone agreed winealsa needs to be fixed. What
> still is undetermined is whether, once fixed, there will still be a need for a
> winepulse driver.

Sorry, I didn't mean to imply the vote was valid :)

http://www.winehq.org/pipermail/wine-devel/2009-June/076575.html

"I would still continue to work and maintain the pulseaudio winmm
patches externally, but I will not try for inclusion."

(In reply to comment #106)
> > Pulseaudio is far superior to dmix from the end-user functionality
>
> Not for Wine (currently), nor is that an issue relating to this bug. It's not
> developer-friendly. Your discussion of end-user features is irrelevant to this
> discussion.

You contradict yourself just a few lines down where you talk about latency. Pulseaudio provides what is desired by users, so a suggestion to just disable it to run Wine is likely to be greeted just like a suggestion to just disable X and run Wine in a framebuffer.

> > All other options that we currently have in
> > Linux do not even come close.
>
> So fix it. Write a per-stream volume control plugin for ALSA/dmix or JACK.

That is not possible - an ALSA device changing the amount of mixers it has at runtime will break all kinds of funny things. And why should I write a completely new sound driver in the kernel or a subsystem in Jack just because you don't want to accept a new feature or a subsystem in Wine?

> > JACK is only needed for sound editing, where you must have guaranteed real-time
> > latency (which Wine does not provide anyway)
>
> Wine's support for latency is not the real issue here, nor are you correct
> about JACK *only* being needed for sound editing, but that's all off-topic
> here.

And yet you bring up latency as the reason why adding PulseAudio to the stack is unacceptable and do not provide an example of widespread Jack use outside audio editing circles.

> > and it is possible that FPS
> > players could benefit by disabling PA and using ALSA directly to gain a few
> > miliseconds in audio latency. However for the rest of Wine users PulseAudio is
> > the ultimate option in usability.
>
> Not when it doesn't work.

PulseAudio works just fine. It has far less bugs than ESD had when driver for it was introduced into Wine.

> And "a few milliseconds" is much more significant
> than you may think, especially when it's adding to already existing latency
> issues (which is the current problem with winealsa and plug pulse).

And if that is so, then no pro-gamer would choose Wine anyway, so why cater to them?

> Regardless, you're not adding much (if anything) to this discussion ... Which
> option are you voting for, the "winepulse driver" option or the "fix winealsa"
> option?

I *advocate* that both bugs - the wishlist bug of a new driver for pulse and a bug that wine uses nonsafe ALSA API should be fixed.

With the way Ubuntu and Fedora are pushing for PulseAudio, I would not be surprised if the respective maintainers would pick this patch up and apply it in these distributions, regardless of your personal opinion on the matter. It would be better if such features were included and cleaned up upstream, however.

(In reply to comment #110)
> Pulseaudio provides what is desired by users, so a suggestion to just disable
> it to run Wine is likely to be greeted just like a suggestion to just disable X
> and run Wine in a framebuffer.

I don't follow the logic, unless you can provide a working X11 emulator for framebuffer that provides hardware accelerated OpenGL. It'd be more like if XCB wasn't written to be fully backwards compatible with libx11, and the developers of XCB saying "fix your broken X11 apps so they'll work with our shiny new XCB".

> > So fix it. Write a per-stream volume control plugin for ALSA/dmix or JACK.
>
> That is not possible - an ALSA device changing the amount of mixers it has at
> runtime will break all kinds of funny things. And why should I write a
> completely new sound driver in the kernel or a subsystem in Jack just because
> you don't want to accept a new feature or a subsystem in Wine?

libasound is userspace, not kernel.

> > > JACK is only needed for sound editing, where you must have guaranteed real-time
> > > latency (which Wine does not provide anyway)
> >
> > Wine's support for latency is not the real issue here, nor are you correct
> > about JACK *only* being needed for sound editing, but that's all off-topic
> > here.
>
> And yet you bring up latency as the reason why adding PulseAudio to the stack
> is unacceptable and do not provide an example of widespread Jack use outside
> audio editing circles.

1) JACK is completely off-topic for this bug.
2) "not the real issue" for JACK. JACK needs real-time kernel support for real low-latency stuff. Same as Pulse in this way.
3) I did not bring up latency; I was responding to someone else who did.

> > > and it is possible that FPS
> > > players could benefit by disabling PA and using ALSA directly to gain a few
> > > miliseconds in audio latency. However for the rest of Wine users PulseAudio is
> > > the ultimate option in usability.
> >
> > Not when it doesn't work.
>
> PulseAudio works just fine.

No it doesn't. If it did, we wouldn't need a discussion on the best way to improve Pulseaudio support in Wine.

> It has far less bugs than ESD had when driver for
> it was introduced into Wine.

Difference is that ESD and Arts daemons did not provide an ALSA compatibility layer. Pulseaudio does, but it doesn't suit Wine's current needs.

> > And "a few milliseconds" is much more significant
> > than you may think, especially when it's adding to already existing latency
> > issues (which is the current problem with winealsa and plug pulse).
>
> And if that is so, then no pro-gamer would choose Wine anyway, so why cater to
> them?

Who said anything about GAMING? Wine is not just used by gamers, nor is Linux. Even so, Wine's goal is to cater to *everyone*. Low-latency is required for professionals, but it doesn't matter for regular users. So you're suggesting Wine should explicitly say "we don't want professionals, only casual users" by saying latency is not an issue.

> > Regardless, you're not adding much (if anything) to this discussion ... Which
> > option are you voting for, the "winepulse driver" option or the "fix winealsa"
> > option?
>
> I *advocate* that b...

(In reply to comment #111)
> > PulseAudio works just fine.
>
> No it doesn't. If it did, we wouldn't need a discussion on the best way to
> improve Pulseaudio support in Wine.

PulseAudio works fine, any application using natively PulseAudio doesn't have problem. There is no way to say "this application doesn't work fine" just because you don't want to use it.

> Difference is that ESD and Arts daemons did not provide an ALSA compatibility
> layer. Pulseaudio does, but it doesn't suit Wine's current needs.

And Wine provide compatibility layer for Windows application, doesn't it ? And I note that so much applications doesn't work, it doesn't suit users' needs so ?

> Who said anything about GAMING? Wine is not just used by gamers, nor is Linux.
> Even so, Wine's goal is to cater to *everyone*. Low-latency is required for
> professionals, but it doesn't matter for regular users. So you're suggesting
> Wine should explicitly say "we don't want professionals, only casual users" by
> saying latency is not an issue.

Wine is not the solution for professional, they use Windows, as gamers. And we don't say "remove ALSA and Jack drivers", they have to still in Wine, for these aims. We just need a PulseAudio driver, because no other driver provides what a PulseAudio one can : simple software mixing without latency (for human ear).

And PulseAudio can use ALSA and/or OSS to output sound, so a common WinePulse driver is a good solution about "OSS or ALSA"-platform choice.

> These patches are not supported by WineHQ in any way. If Ubuntu and Fedora
> package maintainers do so, then it is their responsibility to manage any bugs
> or technical support relating to Pulse and Wine. Users with prepackaged
> winepulse drivers that post on the WineHQ forum, users mailing list or IRC
> channel will be inevitably turned away and sent to the relevant distro-specific
> forum.

Fedora does it yet, and does fine. They are thinking about users, and all main applications in Fedora works fine with PulseAudio.

But why discuss about that ? The driver is here. It needs some improvement, I agree, but it works. Will another sound driver in Wine broke it ? We need the ALSA driver, for hardware stuff, but we need PulseAudio too.

(In reply to comment #111)
> (In reply to comment #110)
> > Pulseaudio provides what is desired by users, so a suggestion to just disable
> > it to run Wine is likely to be greeted just like a suggestion to just disable X
> > and run Wine in a framebuffer.
>
> I don't follow the logic

That is obvious. A new technology comes along that is by many account better than the one before it and that build upon the previous technology. And instead of supporting the new technology directly you demand that users disable the new technology to use your software.

> > PulseAudio works just fine.
>
> No it doesn't. If it did, we wouldn't need a discussion on the best way to
> improve Pulseaudio support in Wine.

Pulseaudio works just fine. Wine is the one that fails to provide support for pulseaudio.

> > It has far less bugs than ESD had when driver for
> > it was introduced into Wine.
>
> Difference is that ESD and Arts daemons did not provide an ALSA compatibility
> layer. Pulseaudio does, but it doesn't suit Wine's current needs.

So, Pulseaudio is being penalized befause it is better??? You are getting ridiculous here.

> > > And "a few milliseconds" is much more significant
> > > than you may think, especially when it's adding to already existing latency
> > > issues (which is the current problem with winealsa and plug pulse).
> >
> > And if that is so, then no pro-gamer would choose Wine anyway, so why cater to
> > them?
>
> Who said anything about GAMING?

Please read back the bug thread your are replying to (starting with comment number 4 and 7). All specific examples related to latency mentioned here were about gaming, first-person shooters to be exact. If you want to provide another example where overhead of Pulseaudio would be significant, please provide examples with testable use cases.

> > I *advocate* that both bugs - the wishlist bug of a new driver for pulse and a
> > bug that wine uses nonsafe ALSA API should be fixed.
>
> This is no longer a considered a "wishlist for driver" bug; it is considered to
> be for improvement of winealsa to talk to Pulse better.

You can consider it what you want. The bug is a feature request for adding a PulseAudio output driver to Wine and nothing else. Restricting Wine's ALSA driver to the safe subset of the API is a separate bug that has nothing to do with this one ( http://bugs.winehq.org/show_bug.cgi?id=18740 ).

I will stop replying to you comments now, because you have not provided a single logical objection to Pulseaudio output driver besides 'I am too lazy to potentially have to look at it at some point later on'.

(In reply to comment #112)
> > Difference is that ESD and Arts daemons did not provide an ALSA compatibility
> > layer. Pulseaudio does, but it doesn't suit Wine's current needs.
> And Wine provide compatibility layer for Windows application, doesn't it ? And
> I note that so much applications doesn't work, it doesn't suit users' needs so
> ?

But you still go and complain here instead of telling say Adobe to fix
Photoshop CS4 to use a "safe Win32 API subset supported by Wine"?

Maybe the problem is that wine maintainers don't want to merge winepulse because they don't know what would occur once it's merged, who will maintain it? Who will take care of bugs opened for winepulse? What will occur if Art doesn't want to maintain winepulse in the future?

Of course, I am not against its merging (well, I am a simple wine user), it's a conjecture about the reasons of not including more sound plugins in wine.

*** Bug 18740 has been marked as a duplicate of this bug. ***

(In reply to comment #113)
> (In reply to comment #111)
> > I don't follow the logic
>
> That is obvious. A new technology comes along that is by many account better
> than the one before it and that build upon the previous technology. And instead
> of supporting the new technology directly you demand that users disable the new
> technology to use your software.

Obviously you do not feel you need to read a post to respond to it. This "new technology" is not all it seems - they promised seamless support for current ALSA apps for one.

> > Difference is that ESD and Arts daemons did not provide an ALSA compatibility
> > layer. Pulseaudio does, but it doesn't suit Wine's current needs.
>
> So, Pulseaudio is being penalized befause it is better??? You are getting
> ridiculous here.

Twist my words as much as you like. You ignored the bit that said "doesn't suit Wine's current needs". That means that winealsa doesn't work with Pulse's ALSA layer through no fault of Wine.

> > Who said anything about GAMING?
>
> Please read back the bug thread your are replying to (starting with comment
> number 4 and 7). All specific examples related to latency mentioned here were
> about gaming, first-person shooters to be exact. If you want to provide another
> example where overhead of Pulseaudio would be significant, please provide
> examples with testable use cases.

The examples of cases where low-latency are required are off-topic. We don't need to saturate this bug with more useless situations. Just that it is known that low-latency is important is enough.

> > This is no longer a considered a "wishlist for driver" bug; it is considered to
> > be for improvement of winealsa to talk to Pulse better.
>
> You can consider it what you want. The bug is a feature request for adding a
> PulseAudio output driver to Wine and nothing else. Restricting Wine's ALSA
> driver to the safe subset of the API is a separate bug that has nothing to do
> with this one ( http://bugs.winehq.org/show_bug.cgi?id=18740 ).

18740 was correctly marked a duplicate - twice - as there has been no attempt improve winealsa to be more Pulse-friendly. As a result, there is no proof that a driver is even required.

> I will stop replying to you comments now, because you have not provided a
> single logical objection to Pulseaudio output driver besides 'I am too lazy to
> potentially have to look at it at some point later on'.

No loss of mine if you refuse to read my posts or *all of the rest of this thread*.

(In reply to comment #115)
> Maybe the problem is that wine maintainers don't want to merge winepulse
> because they don't know what would occur once it's merged, who will maintain
> it? Who will take care of bugs opened for winepulse? What will occur if Art
> doesn't want to maintain winepulse in the future?
>
> Of course, I am not against its merging (well, I am a simple wine user), it's a
> conjecture about the reasons of not including more sound plugins in wine.

If anything, the problem is that there is no one actively maintaining the current audio code, and no one even submitting patches to make winealsa more Pulse-friendly.

* The Wine sound architecture needs some improvements. Nobody disputes this, but there's nobody who's willing to fix it either.

* I'd love to fix it, but the day has only 24 hours. I am busy with d3d, university, and I want some free time with my friends too. Replace "I" with everybody else who's working on Wine, and you get an idea about why nobody seems to care.

As has been adequately expressed in this bug, Wine is not perfect. There are many, many areas that need attention, and Wine has maybe 20 full and part time developers. And ranting that we don't care about users if we don't instantly buckle down and support the 15th sound API on Linux won't help.

* You can't fix problems in the core sound architecture by adding yet another sound plugin based on the broken core.

--> Anybody complaining in this bug report, check out the git code and fire up your favorite text editor and fix the issues. What needs to be done has been expressed multiple times here and on wine-devel. Now stop posting ranty wishlists and start fixing the problems.

Just to add a comment about Art Taylor's work - Art has done the right thing. Instead of complaining he has actually done some constructive work to fix the problem. Unfortunately there were technical issues with it, which could be debated in an orderly fashion and fixed. Unfortunately, the only constructive contribution to this bug has been collateral damage in the flamewar this bug caused.

Again, for anyone attempting to fix this bug: This is not a weekend's task, expect it to take a while, and expect to run into setbacks in the form of incorrect and not accepted solutions. And don't get distracted by flamewars. And you may have to get patches accepted by Pulse, which probably has its own challenges.

Very nice factual words from Stephan.

Wine needs both, evaluate the usage of save ALSA API and a PulseAudio driver.

The problem is that there is nobody who is able to do it, is willing to do it and has time to do it.

Read through the complete bug an through man posts all over the mailing lists. It's not only simple Wine users who are rantig, but some Wine devs, too.

Marking bug http://bugs.winehq.org/show_bug.cgi?id=18740 as a DUPREC and hijacking this message does not help at all so solve the problem.

Ranting against PuleAudio is fighting against windmills.

LINUX/Unix sound system will basically consist of the following elements:
 - ALSA/OSS for hardware access
 - PulesAudio for desktop sound server
 - JACK for low latency professional needs

Many issues with PulseAudio are already fixed or they are in work:
 - Coexistence of JACK and PulseAudio is one of the topics e.g. Fedora is working on.
 - KDE 4 just learn to use PulseAudio with Phonon
 - many latency issues are actually kernel issues

PulseAudio offers easy access to all kind of sound features for the ordinary user. They just want to plug in their USB device or BlueTooth device and it should work. They want to ability to mute it individually etc. More and more people use network streaming etc.

Sure, not everybody needs PulesAudio. JACK is needed from even less people, and people who need JACK usually have the ability to configure their system according their needs.

But PulseAudio is needed by many users without any detailed computer knowledge and I'm quite happy that it is preinstalled on many distros nowadays.

Please just leave these two bugs open and help motivating someone to work on it. Putting both topics in one bug only clutters this one.

Don't rant against much needed progress in LINUX/Unix. And yes, PulseAudio is a big step in the right direction.

(In reply to comment #120)
> Please just leave these two bugs open and help motivating someone to work on
> it. Putting both topics in one bug only clutters this one.

Leaving two bugs open for the same problem doesn't make sense, hence the closed DUP.

> Don't rant against much needed progress in LINUX/Unix. And yes, PulseAudio is a
> big step in the right direction.

I personally think Pulseaudio does it the wrong way, but whatever. It's there and people are using it.

What we DON'T need on this bug are more posts saying "Pulseaudio is awesome for these reasons". It's a waste of time, energy, space and emails. No matter how awesome it is for whoever, support won't magically appear without patches.

Sure, there are the winepulse driver patches here, but consensus of established devs seems to be that it's the wrong way to go about it, and that the existing winealsa code should be made more Pulse-friendly. For anyone new to this thread, *that* is what is meant by the "Wine should support PulseAudio" summary. Only once that has been proven impossible should a winepulse driver be considered.

(In reply to comment #120)
> LINUX/Unix sound system will basically consist of the following elements:
> - ALSA/OSS for hardware access
> - PulesAudio for desktop sound server
> - JACK for low latency professional needs
>
> Many issues with PulseAudio are already fixed or they are in work:
> - Coexistence of JACK and PulseAudio is one of the topics e.g. Fedora is
> working on.
> - KDE 4 just learn to use PulseAudio with Phonon
> - many latency issues are actually kernel issues
I am not the one who designs the Linux sound APIs, but there are number of flaws in this approach:

*) If I want gaming(a low latency audio application) I don't want to do something manually to get it. PulseAudio on a default Ubuntu setup gets me about 300 milliseconds latency. That is enough to make Tuxracer not fun. You can't have 5 solutions for 5 different applications. You need one solution for all of them. Windows can do it. MacOS can do it.

Likewise Wine users should not have to configure manually whether they want low latency(alsa plugin) or software mixing(pulse plugin). There has to be one solution for all.

*) Low latency audio in multiple apps worked with Alsa + Dmix. Before Pulse arrived, I could listen to my MP3s and play Counter Strike, and actually hear gunfire before I was dead. PulseAudio is a network daemon, which cannot get low latency by design without realtime hacks. Blaming that on kernel issues is the wrong way to work around design flaws IMHO.

*) If you write an app that claims it has a compatibility layer for Alsa, and 50% of the apps out there need adjustments(KDE, Skype, Wine, apparently even Tuxracer), then the compatibility layer is not actually compatible.

*) PulseAudio is like the 15th sound API on Linux. All the reasons cited why PulseAudio is good were cited for ESD and Arts before. I am still not convinced why Pulse is suddenly going to fix all that. ESD and Arts were dropped for good reasons. For a while SW mixing was done by dmix, until people went back in time and reinvented ESD and Arts under a different name.

/me anticipates the same flamewar in one or two years when Wine urgently needs to support, say, SpeedAudio, which will be the definite solution to all sound issues on Linux.

(In reply to comment #122)
> ... Blaming that on kernel issues is the
When more that 230 ms come from the kernel it is fair to blame the kernel. The Fedora kernel gives less than 5 ms in the same scenario. On the current Fedora system you don't have these latency issues with PulseAudio.

On a good configured system you don't need to change anything for 99% of the users and 99% of the use cases.

"Hard Core" gaming with PulseAudio is just fine.

This is how it should be.

To ask casual computer users to switch off PulseAudio in order to get Wine working will not work on the long run.

> *) PulseAudio is like the 15th sound API on Linux. All the reasons cited why
> PulseAudio is good were cited for ESD and Arts before. I am still not convinced
> why Pulse is suddenly going to fix all that. ESD and Arts were dropped for good
> reasons.
And PulesAudio was developed for good reasons and has learned a lot from the "14" predecessors. It is far more than a network daemon and software mixer. It is the integrated sound system LINUX/Unix was missing so bitterly.

ESD was not simply dropped, it was replaced by PulseAudio.

It is fine when DMIX is enough for your needs, but you can't reduce the level of sound support on this level. It is simply not sufficient for average users any more.

> /me anticipates the same flamewar in one or two years when Wine urgently needs
> to support, say, SpeedAudio, which will be the definite solution to all sound
> issues on Linux.
This time it is not just a KDE or Gnome project. Not even a LINUX project. It is on the way to become the standard desktop sound system at least on LINUX for normal desktop usage. Give it a chance. I don't believe that we will see SpeedAudio in the next ten years ...

(In reply to comment #123)
> (In reply to comment #122)
> > ... Blaming that on kernel issues is the
> When more that 230 ms come from the kernel it is fair to blame the kernel. The
> Fedora kernel gives less than 5 ms in the same scenario. On the current Fedora
> system you don't have these latency issues with PulseAudio.

Not when the reported latency in the kernel does not exist with dmix.

> On a good configured system you don't need to change anything for 99% of the
> users and 99% of the use cases.

Good luck finding one. The "real-time" kernel hacks are still hacks and not in upstream sources.

> "Hard Core" gaming with PulseAudio is just fine.

Only on one of your mystical "good configured" systems. Pulseaudio's latency certainly does not help the matter.

> To ask casual computer users to switch off PulseAudio in order to get Wine
> working will not work on the long run.

That's what pasuspender is for. I don't believe PulseAudio will survive in the long run (or at least, not as the default soundsystem of the strong-user distros). Something better will come along to replace it.

> And PulesAudio was developed for good reasons and has learned a lot from the
> "14" predecessors. It is far more than a network daemon and software mixer. It
> is the integrated sound system LINUX/Unix was missing so bitterly.

It "learnt" from maybe one of them - esd (and forks thereof). Biggest problem was that while running the daemon you couldn't have ALSA or OSS playing. Pulse fixes that, but wait, it doesn't work (for many pre-Pulse apps, and some continuing apps such as Wine and Skype)! Thus it's not integrated.

> It is fine when DMIX is enough for your needs, but you can't reduce the level
> of sound support on this level. It is simply not sufficient for average users
> any more.

Average user wants sound to Just Play(TM). dmix is sufficient for that. Fancy features like per-app volume control or sending the audio to another computer on your network are in reality not necessary for the average user.

> > /me anticipates the same flamewar in one or two years when Wine urgently needs
> > to support, say, SpeedAudio, which will be the definite solution to all sound
> > issues on Linux.
> This time it is not just a KDE or Gnome project. Not even a LINUX project. It
> is on the way to become the standard desktop sound system at least on LINUX for
> normal desktop usage. Give it a chance. I don't believe that we will see
> SpeedAudio in the next ten years ...

I agree with Stefan. There are too many problems with Pulse. It will get redesigned, it will get replaced by something with full ALSA/OSS compatibility, and when that happens, Ubuntu and Fedora users will no longer rant about how awesome Pulse is and how Wine should have supported it (in difficult-to-maintain and broken ways) 20 billion years ago.

Everyone, please. As Stefan said, more comments here don't help. It distracts developers from fixing bugs when they have to read through more long comments about PulseAudio.

Unless you're working on fixing the wine alsa/sound bugs and have questions or are uploading test patches, please refrain from posting in this bug.

Regardless of one's opinion on the merits of PulseAudio, more and more wine users will be left out in the cold if no work is done to improve the current situation. Asking general users not to use pulse is probably unrealistic, thus the energy should be focused on improving the way in which the two interact.

To those using wine with pulseaudio on 64-bit systems, beware of older version 32-bit binary pulse libraries. I'm not sure if this affects winealsa->libasound->pulse but it does for winepulse->pulse. Gentoo in particular ships (shipped?) old 32-bit pulse libraries. These would contain errors, causeing the local shm transport to fail, falling back to tcp which will inevitably lock up from protocol issues of the older more buggy libraries. Ideally the version of the 32-bit libraries should be identical to the 64-bit.

(In reply to comment #125)
> Everyone, please. As Stefan said, more comments here don't help. It distracts
> developers from fixing bugs when they have to read through more long comments
> about PulseAudio.

This is why http://bugs.winehq.org/show_bug.cgi?id=18740 should have been kept separately. The decision to mark it as a duprec lead to very much noise here. 18740 would be ideal to find someone to work on the save ALSA API.

Maybe the save ALSA API is an idea for the next SOC?

It is one thing not to accept a new PulseAudio driver in Wine due to concerns about maintenance. It is another thing to sabotage the usage of winehq.org to discuss and provide a separately maintained driver which has the chance to mature and enrich Wine in the future.

But it is your decision and I promise not to post here anymore until I have some really meaningful to say ...

I think the safe API has limitations which hinder using it for dsound currently. (snd_pcm_avail and mmap assymptions for instance)

This bug is now 10th most voted for bug in this database.

If you are working with Ubuntu and testing the latest release of the distribution then you can help improve the PulseAudio driver for Wine.

I have created a version of the wine1.2 package that includes the native PulseAudio driver for Wine. This package is targeted at the Karmic distribution, so if you are testing out the new release can you try this package and see if it improves the Wine sound on Ubuntu for you.

If you try it, can you report back your experiences in Launchpad please, rather than winehq.

https://bugs.launchpad.net/wine/+bug/371897

You can install the software from my PPA

https://launchpad.net/~neil-aldur/+archive/ppa

To install the software follow the instructions on Launchpad (https://help.launchpad.net/Packaging/PPA/InstallingSoftware)

Wine is now slower in adapting to new technologies than closed-source software - Skype has PulseAudio support.

I must say however that I see less problems with wine 1.1.29 alsa backend interaction with pulseaudio that there were before.

(In reply to comment #131)
> Wine is now slower in adapting to new technologies than closed-source software
> - Skype has PulseAudio support.
>
> I must say however that I see less problems with wine 1.1.29 alsa backend
> interaction with pulseaudio that there were before.

Isn't it acceptable to just use either the aoss wrapper or the padsp command with your wine app? I've been doing it for a couple of years now, I think, and I've had very few issues indeed. If the wine devs could somehow make wine take into account the presence of pulseaudio in a system so we didn't have to use these commands, that'd be great. I don't know for sure about things like audio latency with pulseaudio using this method, but from my own experiences, it shouldn't be a big deal at all, since I've been using pulse for both native and wine multiplayer games for some time now.

biiig +1 from me. just patched wine with WinePulse (http://art.ified.ca/?page_id=40) and it works like a charm. no more killing of media player audio streams when starting wine.

(In reply to comment #129)
> This bug is now 10th most voted for bug in this database.

So there are 9 things that should be fixed before this? Sounds fine to me ;)

(In reply to comment #131)
> Wine is now slower in adapting to new technologies than closed-source software
> - Skype has PulseAudio support.

The main reason why Wine doesn't have a pulse driver in upstream is because it doesn't need one. We have tools like padsp or aoss that work for some people and pasuspender for everyone else.

Another reason, as has been discussed, is that pulse adds unreasonable latency to be used as a general purpose software mixer (as in one that is suitable for professional applications).

Furthermore, no one has proven that a pulse driver is actually NEEDED. The preferred solution is to modify, if possible, winealsa and/or wineoss drivers to work nicely with pulse. In this case, a pulse driver would *never* be needed.

(In reply to comment #134)
> Another reason, as has been discussed, is that pulse adds unreasonable latency
> to be used as a general purpose software mixer (as in one that is suitable for
> professional applications).

Dude, that's an argument against PulseAudio in general; not a valid reason for Wine not to support a native Pulse output (not that there aren't valid reasons). The fact is that most desktop distributions are shipping PulseAudio by default, and audio not working is a major paper cut for less technical users.

> Furthermore, no one has proven that a pulse driver is actually NEEDED. The
> preferred solution is to modify, if possible, winealsa and/or wineoss drivers
> to work nicely with pulse. In this case, a pulse driver would *never* be
> needed.

That said, I am already very happy with Wine's ALSA output. It works beautifully with Pulse through the Alsa plugin these days. However, timing is an issue -- lip sync still doesn't work properly with my Bluetooth headset (which adds a 0.25sec latency), but lip sync is now perfect with native Linux apps (e.g. GStreamer apps).

(In reply to comment #135)
> (In reply to comment #134)
> > Another reason, as has been discussed, is that pulse adds unreasonable latency
> > to be used as a general purpose software mixer (as in one that is suitable for
> > professional applications).
>
> Dude, that's an argument against PulseAudio in general; not a valid reason for
> Wine not to support a native Pulse output (not that there aren't valid
> reasons). The fact is that most desktop distributions are shipping PulseAudio
> by default, and audio not working is a major paper cut for less technical
> users.

Agreed, but my point is that Wine is a general-purpose solution that has to cater for professional-level applications. It is my understanding that Wine is simply incapable of doing that with pulse due to the latency issues and the design of pulse.

2009/9/27 <email address hidden>:
> The main reason why Wine doesn't have a pulse driver in upstream is because it
> doesn't need one. We have tools like padsp or aoss that work for some people
> and pasuspender for everyone else.

Why are the JACK and OSS drivers needed then? By that argument they could be stripped and the whole sound driver selection dialog could be removed. Surely, if your argument holds, there is a whole batch of simplification that could take place. Why not do that if a single ALSA driver is the one true path?

pasuspender always seems like a good answer until your softphone fails to ring because your ALSA layer is locked out and you miss an important call.

The truth is that the Wine ALSA layer drives ALSA hard. Much harder than Pulseaudio's abstraction layer can ever provide. That generates an impedence mismatch that results in skips and broken streams.

>
> Another reason, as has been discussed, is that pulse adds unreasonable latency
> to be used as a general purpose software mixer (as in one that is suitable for
> professional applications).

Last time I looked you could select which audio driver you require. Nobody is saying remove the ALSA driver or requiring that 'professional' applications use Pulseaudio. Neither is anybody suggesting that Wine should default to the Pulseaudio driver in the main installation. Distributions could make that choice as required in their build configuration.

Professional level applications are likely to use JACK anyway.

>
> Furthermore, no one has proven that a pulse driver is actually NEEDED. The
> preferred solution is to modify, if possible, winealsa and/or wineoss drivers
> to work nicely with pulse. In this case, a pulse driver would *never* be
> needed.

The proof is straightforward. Altering the ALSA driver to work with pulse would require that the ALSA driver work at the lowest common denominator and that all the fancy twiddles you can do for a *local* sound card installation would have to be disabled for Pulse due to its inherent remote nature. The alternative is a complex mess where you're checking all the time what is going on - or the current abstraction layer which fails when Wine ALSA asks for a 'fancy' option that PulseAudio simply can't provide (like access to the hardware).

In other words the ALSA driver would have to be compromised to support Pulse, either in capability or structurally. That is unnecessary code coupling that would affect those users who want a clean ALSA driver .

The alternative is that you have an ALSA layer that can assume it is sat directly on ALSA all the time and can fully exploit the interface plus a Pulseaudio module that does all the compromising - but keeping Wine informed of the compromises so you don't get errors.

Plus pragmatically we have somebody who is interested in maintaining a Pulseaudio layer and apparently nobody who is interested in maintaining the ALSA layer beyond keeping the existing system running. That ought to count for something.

This is not an either/or situation. I don't see how it is helpful to portray it as such.

(In reply to comment #137)
> 2009/9/27 <email address hidden>:
> > The main reason why Wine doesn't have a pulse driver in upstream is because it
> > doesn't need one. We have tools like padsp or aoss that work for some people
> > and pasuspender for everyone else.
>
> Why are the JACK and OSS drivers needed then? By that argument they could be
> stripped and the whole sound driver selection dialog could be removed. Surely,
> if your argument holds, there is a whole batch of simplification that could
> take place. Why not do that if a single ALSA driver is the one true path?

Because JACK and in-kernel-tree OSS do not provide ALSA compatibility. Pulse does, but it's broken for the purposes of Wine. The solution is therefore to fix winealsa to be pulse-friendly, to not use pulse (e.g. pasuspender) or trick pulse into likeing Wine (e.g. padsp, which only works for some people). A separate pulse driver is not needed.

> pasuspender always seems like a good answer until your softphone fails to ring
> because your ALSA layer is locked out and you miss an important call.

Then use a system that works properly and doesn't hate Wine like ALSA's built-in dmix. Or don't use Wine with audio.

> The truth is that the Wine ALSA layer drives ALSA hard. Much harder than
> Pulseaudio's abstraction layer can ever provide. That generates an impedence
> mismatch that results in skips and broken streams.

So you're saying Wine can never provide a satisfactory pulse driver because of limitations of pulse? On this point, we are agreed.

> Last time I looked you could select which audio driver you require. Nobody is
> saying remove the ALSA driver or requiring that 'professional' applications use
> Pulseaudio.

If pulse is "officially" supported by Wine, then the implication is there that it will be suitable for the general-purpose nature that Wine has.

> > Furthermore, no one has proven that a pulse driver is actually NEEDED. The
> > preferred solution is to modify, if possible, winealsa and/or wineoss drivers
> > to work nicely with pulse. In this case, a pulse driver would *never* be
> > needed.
>
> The proof is straightforward.
-- snip --
> In other words the ALSA driver would have to be compromised to support Pulse,
> either in capability or structurally. That is unnecessary code coupling that
> would affect those users who want a clean ALSA driver .

There is as of yet no demonstration that the ALSA driver cannot be reduced to the "pulse-safe" subset without compromising features or performance. I suspect this is the case, but if you have read the discussion, Wine's core developers require a definite and demonstrated (by code) NEED for a separate pulse driver before it will be considered for upstream.

> Plus pragmatically we have somebody who is interested in maintaining a
> Pulseaudio layer and apparently nobody who is interested in maintaining the
> ALSA layer beyond keeping the existing system running. That ought to count for
> something.

Enthusiastic developers have been known to disappear completely. "Someone is willing to maintain it" certainly goes in favour of the pulse driver, but does not satisfy the remaining objections.

> This is not an e...

(In reply to comment #138)
> [...]to not use pulse (e.g. pasuspender) or tric pulse into likeing Wine
> (e.g. padsp, which only works for some people).
sry, but imo pasuspender/padsp are non-solutions as for me they break more than they fix.
> Then use a system that works properly and doesn't hate Wine like ALSA's
> built-in dmix. Or don't use Wine with audio.
that's also a non-solution
> So you're saying Wine can never provide a satisfactory pulse driver because of
> limitations of pulse? On this point, we are agreed.
nope, he said that wine sometimes does some nasty stuff in its alsa-driver and thus can't be expected to work 100%.
> There is as of yet no demonstration that the ALSA driver cannot be reduced to
> the "pulse-safe" subset without compromising features or performance. I suspect
> this is the case, but if you have read the discussion, Wine's core developers
> require a definite and demonstrated (by code) NEED for a separate pulse driver
> before it will be considered for upstream.
I can give them a demo-system with non-working alsa-driver (as it kills other audio streams) and working pulse-driver. if that's not enough I may say I'm a little annoyed by that policy.
> Enthusiastic developers have been known to disappear completely. "Someone is
> willing to maintain it" certainly goes in favour of the pulse driver, but does
> not satisfy the remaining objections.
jeah, and maybe he gets hit by a car next week, who knows. and maybe all the devs have the same faith and we should cancel the project alltogether -.-
No, seriously: it could work the same way it does in the kernel where drivers with no maintainer get flagged and removed in subsequent releases.

just m2c

(In reply to comment #138)

> > The truth is that the Wine ALSA layer drives ALSA hard. Much harder than
> > Pulseaudio's abstraction layer can ever provide. That generates an impedence
> > mismatch that results in skips and broken streams.
>
> So you're saying Wine can never provide a satisfactory pulse driver because of
> limitations of pulse? On this point, we are agreed.

You have to remember that Pulse might not be talking to Alsa at the back end. It might be talking to an Apple Airport or even another Windows machine. Therefore it can only offer an Alsa subset that is the lowest common denominator between Alsa and the native pulse capabilities.

Also by definition if you can't create a native Pulse driver, then operating through the abstraction layer would be worse because you lose access to native knobs and twiddles. An abstraction layer can't offer more than the native.

So again if your argument holds, then it holds for modifying the alsa driver to work with pulse. So it is not rational that the ALSA driver can be made to work with Pulse, but a Pulseaudio driver can never be constructed. That suggests there is more to your position than objective technical and logistical issues.

> So if it is possible (in code) to make the ALSA driver work nicer with
> pulse (apparently there has already been movement in this direction), then that
> is definitely the way to go.

If it is possible, and there are people to do the work, then it should be attempted. From my position 1.1.29 is a lot better than before, but we're still losing streams randomly. So there is a way to go there, but the improvement is to be congratulated for all involved.

I also have a great deal of sympathy for the maintenance argument. I may be worth examining the commonality between JACK, OSS, ALSA and Pulse to see if unification is possible. Then everything can be native with very little code and the maintenance overhead can be reduced.

(In reply to comment #139)
> (In reply to comment #138)
> > [...]to not use pulse (e.g. pasuspender) or tric pulse into likeing Wine
> > (e.g. padsp, which only works for some people).
> sry, but imo pasuspender/padsp are non-solutions as for me they break more than
> they fix.

Sorry, but IMO, pulse is a non-solution because it breaks more than it fixes.

> I can give them a demo-system with non-working alsa-driver (as it kills other
> audio streams) and working pulse-driver.

Sounds like your dmix is broken, in which case you're comparing apples and oranges.

(In reply to comment #140)
> Also by definition if you can't create a native Pulse driver, then operating
> through the abstraction layer would be worse because you lose access to native
> knobs and twiddles. An abstraction layer can't offer more than the native.

The question remains, are those knobs and twiddles actually necessary for a fully-functional ALSA driver? So far no one has answered that question.

(In reply to comment #141)
> (In reply to comment #139)
> > (In reply to comment #138)
> > > [...]to not use pulse (e.g. pasuspender) or tric pulse into likeing Wine
> > > (e.g. padsp, which only works for some people).
> > sry, but imo pasuspender/padsp are non-solutions as for me they break more than
> > they fix.
>
> Sorry, but IMO, pulse is a non-solution because it breaks more than it fixes.

Ben you know better than to troll on this kind of subject. You are forcing the user to use another application to fix something that doesn't work properly within wine, that's like saying "We won't fix the wine problems with MSWord, use Open Office instead".

Ubuntu Fedora and other major distributions are using PulseAudio for nearly two years now.
Professionals can use ALSA on whatever distribution or operating system they want, BUT still most linux users use PulseAudio by default.
So according to wikipedia
http://upload.wikimedia.org/wikipedia/commons/0/00/Pulseaudio-diagram.svg
using ALSA on a PulseAudio system, adds more delay because of the use of 'libalsa Pulse' on the library layer, and causes even more problems.
Remember that this is the current situation for MOST linux users.

So using ALSA is more professional (you can just let it be the default), but not providing native PulseAudio driver hurts the masses.
Of course, we can try forcing all those users to use ALSA, or event force them to use windows... You forget that linux (most Wine users use it) is about freedom.

And yes there is someone who is willing to be a maintainer, it`s him who will write the code not you (PulseAudio haters) so stop complaining.

+1 to Jerome

Probably the largest problem for audio in WINE is the WaveOut/WaveIn API's. Currently the WaveOut and WaveIn API's are the base for the other audio api's in WINE (except openAL.) The audio api, designed probably in the early 90s for PCs of the day seems to have been the first implemented in wine, and all audio api's fall-back to it (except openAL and DSound on OSS and ALSA in special occasions.) Probably the biggest pro-native-pulseaudio reason is the waveout functions. Through libalsa pulse, calls such as waveOutReset() and waveOutResume() require a reconnection to pulseaudio each call. Using a native pulseaudio driver we can write audio data into pulseaudio and do the pause, resume and reset calls without penalty.

My two cents is that audio in wine is long overdue for an overhaul. Probably the best way would be to implement some sensible abstracted buffer situation and then have _one_ waveout/wavein driver written to use it. Currently the winmm drivers each contain parallel implementations of the code required to set up another thread to manage feeding the hardware, timing wavehdr's and calling back to the application. Probably the biggest problem with winealsa.drv is that it will exhibit different behavior if it receives different behavior from whatever audio device it is using. The different behavior has to be dealt with by the windows application, which may have it's own issues. The same is probably true of wineoss or others. This is not the native audio api's fault IMO, but the failure of WaveOut/In. In winepulse tried to make it behave the same all the time. The argument that this different behavior is the fault of the alsa driver is also not acceptable. We cannot believe that it is still 1994 and every audio device behaves like we are writing straight to a 10ms DAC buffer.

What is the state of audio in windows these days? I shudder to think that the only way to play audio on a windows box is dsound or waveout. Surely there is a new audio api out of redmond that will require implementing anyways?

In either case, in lue of further progress I'm maintaining a (blasphemous) patch for a native wine pulseaudio backend, and shall continue to maintain it so long as it is useful.

For your info, on Karmic beta using wine1.2 (1.1.30) from the Ubuntu repositories, it is impossible for me to get foobar working properly. The only possibility is to use padsp and kill all other applications which use the sound engine. This is really frustrating.

Thus, I applied the PulseAudio patch and now I can use foobar again without problems! I think this patch should be added to the main tree, as there is a maintainer and the current audio solutions are not sufficient.

(In reply to comment #145)
> For your info, on Karmic beta using wine1.2 (1.1.30) from the Ubuntu
> repositories, it is impossible for me to get foobar working properly. The only
> possibility is to use padsp and kill all other applications which use the sound
> engine. This is really frustrating.
>
> Thus, I applied the PulseAudio patch and now I can use foobar again without
> problems! I think this patch should be added to the main tree, as there is a
> maintainer and the current audio solutions are not sufficient.

Wine1.2? What?

In Ubuntu Karmic, there are two wine packages: wine and wine1.2.
wine is the 'stable' version: wine 1.0.1
wine1.2 is the latest version: wine 1.1.30

(In reply to comment #147)
> In Ubuntu Karmic, there are two wine packages: wine and wine1.2.
> wine is the 'stable' version: wine 1.0.1
> wine1.2 is the latest version: wine 1.1.30

Yet another reason why we shouldn't be bound by anything that a particular distro does.

Sure what a crime from Scott to offer both, the 1.0 and the dev release.

And the stupid user who simply want their sound to work are just annoying.

I'm so happy that there are biased stubborn devs who take care for the needs of professional users.

I'm sorry, I just try to reflect what I found in this message. I tried to keep quiet for some time now but it's very hard when you read the comments here.

Average users don't have any problems with the latency of a good configured pulse audio.

Professional users who need very low latency need JACK.

To ask 90% of the unexperienced user to deeply manipulate their system to have sound work in order to make it easier for a handful "professionals" sounds very wise to me.

There exists a dev who is willing and able to deliver a solution but instead of a welcome he earns only prejudice.

The wine betas are provided by an Ubuntu "wine1.2" package because:
1) It needs to be named different from the stable Wine since it's a different package
2) Renaming a package is not an easy task (as upgrades are done based on name)
3) They will eventually be replaced by the real Wine 1.2 (which shouldn't be any worse than their current status)

So while "wine1.2 version 1.1.30-0ubuntu4" might sound like a weird package name, it will never be seen by anyone unless they're running terminal commands (it's called "beta release" in the Software Center, for instance)

(In reply to comment #149)
> Sure what a crime from Scott to offer both, the 1.0 and the dev release.

"wine1.2" is a poor choice though. Even "wine-1.2" would be better. Debian has "wine-unstable" now.

> Average users don't have any problems with the latency of a good configured
> pulse audio.

Except when using Wine, Skype etc. Hence the issue. And given that dmix does not suffer from these same latency issues, it's obviously a problem with pulse. Face it, pulse is virtually broken by design, and was adopted far too early by distros like *buntu and Fedora.

> Professional users who need very low latency need JACK.

Or hardware-accelerated ALSA, which is disabled by pulse.

> To ask 90% of the unexperienced user to deeply manipulate their system to have
> sound work in order to make it easier for a handful "professionals" sounds very
> wise to me.

Wine can't support a broken distro. If it's really so difficult to disable pulseaudio, it's not Wine's fault but the distro's.

> There exists a dev who is willing and able to deliver a solution but instead of
> a welcome he earns only prejudice.

There have been specific objections to the proposed winepulse *code* (not just the concept) before and I as far as I know the few people who have worked on it are no longer attempting to get it accepted upstream. Patches have to be sent to wine-patches mailing list for review.

(In reply to comment #151)

Arguing the merits of PulseAudio is periphery. Some people use it, some people also use wine. You cannot "fix" people into not trying to use them together. That said...

> Except when using Wine, Skype etc. Hence the issue. And given that dmix does
> not suffer from these same latency issues, it's obviously a problem with pulse.
> Face it, pulse is virtually broken by design

Substantiate? Dynamic latency management is probably one of pulse's most wonderful features. Is it for a professional, static, audio situation? No. Is it for real-life, dynamic audio situation? Yes. 50ms total latency is common.

> Or hardware-accelerated ALSA, which is disabled by pulse.
Most audio hardware has no hardware accelerated mixing, which makes it difficult to implement hardware-accelerated mixing.

> There have been specific objections to the proposed winepulse *code* (not just
> the concept) before and I as far as I know the few people who have worked on it
> are no longer attempting to get it accepted upstream. Patches have to be sent
> to wine-patches mailing list for review.

That was a /long/ time ago. I've stopped trying to get it accepted in vanilla wine because arguing the concept to people with prejudgments seems barrier enough.

IMO the audio aspects of wine should be redesigned (nobody's fault, things evolve over time.) However, such an undertaking is a lot of work. Meanwhile the wine-pulse code exists and works better for people who use pulseaudio to using an different audio api in parallel or emulated on top of pulseaudio.

If wine's implementation of the (depreciated) MME was consolidated from per-driver to one location and then a common audio interface abstraction for MME was written, I would lobby for the inclusion of pulse as a target backend into official wine.

(In reply to comment #152)
> (In reply to comment #151)
>
> Arguing the merits of PulseAudio is periphery. Some people use it, some people
> also use wine. You cannot "fix" people into not trying to use them together.
> That said...

Equally cannot "fix" people trying to use Wine on Windows natively.

> > Except when using Wine, Skype etc. Hence the issue. And given that dmix does
> > not suffer from these same latency issues, it's obviously a problem with pulse.
> > Face it, pulse is virtually broken by design
>
> Substantiate? Dynamic latency management is probably one of pulse's most
> wonderful features. Is it for a professional, static, audio situation? No. Is
> it for real-life, dynamic audio situation? Yes. 50ms total latency is common.

50ms latency from pulse is only achievable with the -rt branch kernel. For everything else, dmix does not suffer from such serious latency issues (especially in Wine, Skype etc).

> > Or hardware-accelerated ALSA, which is disabled by pulse.
> Most audio hardware has no hardware accelerated mixing, which makes it
> difficult to implement hardware-accelerated mixing.

*Professional* audio users, those addressed by the comment, are most likely to use cards that have hardware mixing in hardware and drivers.

> > There have been specific objections to the proposed winepulse *code* (not just
> > the concept) before and I as far as I know the few people who have worked on it
> > are no longer attempting to get it accepted upstream. Patches have to be sent
> > to wine-patches mailing list for review.
>
> That was a /long/ time ago. I've stopped trying to get it accepted in vanilla
> wine because arguing the concept to people with prejudgments seems barrier
> enough.

If you've stopped trying to get Wine upstream to support pulse, this whole discussion is moot. So much for the "developer willing to maintain" argument.

> IMO the audio aspects of wine should be redesigned (nobody's fault, things
> evolve over time.) However, such an undertaking is a lot of work.

Then someone needs to start working on it. I believe you just volunteered, Art :P

> If wine's implementation of the (depreciated) MME was consolidated from
> per-driver to one location and then a common audio interface abstraction for
> MME was written, I would lobby for the inclusion of pulse as a target backend
> into official wine.

Assuming this is even possible. Even just a Proof of Concept would be helpful here.

(In reply to comment #153)

> 50ms latency from pulse is only achievable with the -rt branch kernel. For
> everything else, dmix does not suffer from such serious latency issues
> (especially in Wine, Skype etc).

/me is using the linus branch and pulse releases. *scratches head*

> If you've stopped trying to get Wine upstream to support pulse, this whole
> discussion is moot. So much for the "developer willing to maintain" argument.

I am, outside of wine currently.

> Assuming this is even possible. Even just a Proof of Concept would be helpful
> here.

Problem with writing a proof-of-concept for the wine project is that while it may be better, it will be regarded as too large a change and rejected unless it could be done incrementally. It's hard to make a horse and buggy into an automobile without being allowed to replace logical parts in their entirety.

(In reply to comment #154)
> > If you've stopped trying to get Wine upstream to support pulse, this whole
> > discussion is moot. So much for the "developer willing to maintain" argument.
>
> I am, outside of wine currently.

But you're not willing to submit your patches upstream, so you're not willing to maintain it as a part of Wine (which is what the argument against "developer willing to maintain" is).

> Problem with writing a proof-of-concept for the wine project is that while it
> may be better, it will be regarded as too large a change and rejected unless it
> could be done incrementally. It's hard to make a horse and buggy into an
> automobile without being allowed to replace logical parts in their entirety.

Defeatism isn't healthy. You don't know until you try. If it is possible, it would as you say make *all* sound drivers easier to maintain, and I'm sure the core devs would consider such an improvement seriously.

(In reply to comment #151)
> > Average users don't have any problems with the latency of a good configured
> > pulse audio.
>
> Except when using Wine, Skype etc. Hence the issue. And given that dmix does
> not suffer from these same latency issues, it's obviously a problem with pulse.
> Face it, pulse is virtually broken by design, and was adopted far too early by
> distros like *buntu and Fedora.
Of course. It's important to have low latency on these audio streams I can't
hear since my card is blocked by another application.

> Wine can't support a broken distro. If it's really so difficult to disable
> pulseaudio, it's not Wine's fault but the distro's.
Again: If I disable software mixing by pulse, I cannot use a voice application
and watch a video simultaneously.

About the whole latency issue: Who cares? There is a checkbox to choose another
audio backend whenever you want; each winecfg user is capable of using ALSA or
JACK if latency disturbs him.

While this flamewar here was going on, Maarten Lankhorst sent a few patches to improve our Alsa backend with PulseAudio. During this process, he also reported a number of bugs to the PulseAudio developers, so PA can be improved. This doesn't produce angry attack mails, but it does improve the situation.

I think this whole discussion has reached a dead end. I think this issue can't be fixed in PulseAudio alone, and it can't be fixed in Wine alone. The sound infrastructure in Linux still seems broken after years of replacing one solution with a better solution.

First of all, it apparently isn't impossible to get this right. MacOS has low latency(subjectively 0 ms) sound. I can play music in iTunes and play counterstrike at the same time, and I am sure I could also use TeamSpeak/Ventrillo if I wanted to. I haven't seen any problem on Windows either, although I barely use it.

I have little personal interest in Linux sound at the moment - I'm working on 3D, and currently my main development platform is a Mac, where sound just works. But still, here's my suggestion:

0) Stop this flamewar here. It doesn't fix the problem. (Yeah, I know my posting violates this). Instead, help Maarten's work by coding or useful bug reports.

1) Accept that PulseAudio is here to stay, and that we have to work with it. Don't deny it, but don't deny that PulseAudio needs a lot of work as well(Ask Maarten for details - I don't know them)

2) Help the PA developers to make PA work. If we fight PA, and persuade distro's to drop it, its just a matter of time before someone else has starts up a new sound daemon called SpeedAudio. PA is a typical case where someone invented a new solution instead of fixing the existing one. They didn't yet succeed at fixing the problem, but they succeeded at adding this to all distros. If we attack PA, all we'll get is yet another broken replacement.

3) Possibly try to arrange a meeting between PulseAudio developers and Wine devs. A personal meeting doesn't lead to a flamefest, and might produce a useful set of isolated bugs to work on. (Unfortunately that is expensive, and I don't know any established meeting that might provide a backdrop for this)

4) Make sure Alsa + Pulse works well enough for users.

5) I think Art has done a great work with trying to fix this by adding a PA driver to Wine, but currently, as he correctly states, this cannot be accepted. Instead of trying to get yet another copy of wineoss.drv + a few changes into Wine, someone should fix the Wine sound infrastructure. I know this is unsexy work, and hard to make Alexandre like it. Maybe I should persuade Jeremy White to throw some $$$ at this process. We're having trouble with sound on CrossOver as well, so I guess he might be open to that.

6) Once the Wine sound infrastructure is fixed, we can monitor the situation and see where the Linux sound development leads to. If PulseAudio is nevertheless replaced with SpeedAudio in 2 years, punch some distro maintainers in the face. If PulseAudio remains the sound server of choice, but most other apps keep talking to it via the Alsa interface, stick to winealsa.drv, same if PA is dropped in favor of plain alsa+dmix. If Pul...

(In reply to comment #157)
> 6) Once the Wine sound infrastructure is fixed, we can monitor the situation
> and see where the Linux sound development leads to. If PulseAudio is
> nevertheless replaced with SpeedAudio in 2 years, punch some distro maintainers
> in the face. If PulseAudio remains the sound server of choice, but most other
> apps keep talking to it via the Alsa interface, stick to winealsa.drv, same if
> PA is dropped in favor of plain alsa+dmix. If PulseAudio is used pretty much
> everywhere, and all other apps use it, add a winepulse.drv and drop
> winealsa.drv. I think we should only add a pulse driver if it can either be
> shown that there are issues that can't be fixed with alsa by design, or if we
> can drop winealsa in exchange.

Dropping winealsa would annoy everyone who has a *REAL* soundcard, has no need for pulse, and uses a distribution that hasn't already forced pulse down the users' throats.

You could argue a similar case for winejack - either drop winealsa in favour of winejack (because jack can be used on top of alsa without problems) or drop winejack in favour of winealsa (because winejack is generally unmaintained and buggy).

The only case where winealsa should be dropped is if some other driver (e.g. pulse) provides a hybrid winefoo/winealsa support, which would defeat the purpose of having *any* different sound drivers IMO. It's my understanding that the winepulse driver should use libpulse calls and not libalsa calls to do everything.

So..... I'm tired of everyone saying get rid of OSS and just have ALSA because everything supports ALSA. FYI, BSD only supports OSS, and ALSA has OSS emulation, so if we drop anything, it should be everything but OSS. OSS has been around forever and virtually everyone supports it.

That being said, I'm pro-pulse. As an "average" non-heavy-gamer user, I do crap like run Quicken through wine, where I like my little ka-ching sound when I add a transaction, and I don't want to suspend my music via rhythmbox to get it.

The idea is if you want to tweak every last ounce of performance out of your sound server, then let them, keep ALSA or JACK or OSS. Pulse is moving to be an "average" user solution. Is it bug free? absolutely not. Then again, what is? Are the pulse devs willing to improve it? As far as I can tell yes. But their primary users are "average" joe. They use ALSA as a base because it has the drivers, but they provide a simple yet powerful front end to users.

So please, read Stefan's advice in Comment 157. I especially like #3, and would love to know where to donate to make this happen =). Art, Thank you so much for your patch. Even if it isn't accepted, it's a step in the right direction.

(In reply to comment #159)
> So..... I'm tired of everyone saying get rid of OSS and just have ALSA because
> everything supports ALSA. FYI, BSD only supports OSS, and ALSA has OSS
> emulation, so if we drop anything, it should be everything but OSS. OSS has
> been around forever and virtually everyone supports it.

OSS4 has ALSA emulation (and software mixing), and I hear it's quite good. However, OSS4 won't get into the Linux kernel due to licensing issues ...

> Are the pulse devs willing to improve it? As far as I can tell yes. But their
> primary users are "average" joe. They use ALSA as a base because it has the
> drivers, but they provide a simple yet powerful front end to users.

Technically, ALSA isn't the only backend that pulse supports, it's just that it's the primary backend on Linux systems because OSS in Linux is terrible by modern standards.

But part of the problem is that pulse is marketed as a general solution to all audio problems. They claim it has low latency etc., which fuels calls for it to replace every other audio API. However, on closer inspection, it's unsuited to anything more than the most basic usage.

The point remains that winepulse will only be accepted if a definite, demonstrated need is presented - i.e. that winealsa (and other drivers) can't be made pulse-friendly. The suggestion of redesigning wine's audio subsystem, although time-consuming and resource heavy, is the first stepping stone in this direction.

(In reply to comment #160)
> But part of the problem is that pulse is marketed as a general solution to all
> audio problems. They claim it has low latency etc., which fuels calls for it to
> replace every other audio API. However, on closer inspection, it's unsuited to
> anything more than the most basic usage.
the only difference being that it works quite well for my needs (in contrast to some "advanced" solutions) and offers some nifty features.

> The point remains that winepulse will only be accepted if a definite,
> demonstrated need is presented - i.e. that winealsa (and other drivers) can't
> be made pulse-friendly.
So, to rephrase this: right now we have a working solution (winepulse) and one that "we may get compatible some day" (winealsa) and you are telling us is that "all we have to do" is to _prove_ that winealsa "can't be made pulse-friendly"? what kind of logic is that?
> The suggestion of redesigning wine's audio subsystem,
> although time-consuming and resource heavy, is the first stepping stone in this
> direction.
woohoo, maybe we get pulse-support in 2012 -.-

(In reply to comment #158)
Again another great contributione to the flameware. Do you have any idea what Stefan was writing about? Maybe you should read his comment again.

(In reply to comment #160)
> But part of the problem is that pulse is marketed as a general solution to all
> audio problems. They claim it has low latency etc.,
This is not true. JACK ist the sound server of joice for low latency needs. It does not claim to be a low latency solution. Pulse and JACK devs work on making both sound servers working together nicely.

> The point remains that winepulse will only be accepted if a definite,
> demonstrated need is presented - i.e. that winealsa (and other drivers) can't
> be made pulse-friendly.
I don't know the Wine set-up in detail but AFAIK it is not your decision and I'm very glad about that.

You simply don't know what Pulse is good for and cultivate your prejudice.

ALSA via Pulse does have a higher latency than a direct Pulse API. Thus you demand a "definite, demonstrated need" on one side but claim that latency is the highest priority on the other side.

To keep the flames burning:

1. It's not license issues that keep OSS4 out of the kernel.
If you filter out personal bickering between those two teams
(about 95% of that discussion - in a way, same as here),
there are some technological issues too, i.e.
using float processing in kernel space.

2. My opinion here is rather biased, as I don't use wine
for anything resource heavy and though having a crappy soundcard
(just onboard AC'97), pulseaudio works just fine for me,
at least for playback (IIRC, never tried capture).

3. For me, comment 157 sums up this problem best
- there's a need to redesign whole Wine audio infrastructure,
not simply tweak old (or add new) drivers. winepulse could
be an acceptable temporary solution, the problem is that
often there's nothing longer living than a temporary hack.
If somebody found time for that redesign, winepulse could
be useful till things really get fixed, otherwise it would
eventually end up as an unmaintained hack. After all, pulseaudio
already went a few times through changes, that broke its
plugins in other libs/programs.

(In reply to comment #162)
> (In reply to comment #158)
> Again another great contributione to the flameware. Do you have any idea what
> Stefan was writing about? Maybe you should read his comment again.

So you argue that Linux users be forced to either use an inferior OSS or install pulseaudio and live with it if they happen to want sound in Wine?

The main argument for supporting pulse *at all* is that people use it. People still use plain ALSA, and with good cause. It's hypocritical to drop winealsa in favour of winepulse *unless* some other driver takes over the job of winealsa and provides native ALSA support.

> > The point remains that winepulse will only be accepted if a definite,
> > demonstrated need is presented - i.e. that winealsa (and other drivers) can't
> > be made pulse-friendly.
> I don't know the Wine set-up in detail but AFAIK it is not your decision and
> I'm very glad about that.
>
> You simply don't know what Pulse is good for and cultivate your prejudice.

Obviously you have no interest in ending the flamewar. Your accusation, correct or not, of my contribution to the war is hypocritical.

> ALSA via Pulse does have a higher latency than a direct Pulse API. Thus you
> demand a "definite, demonstrated need" on one side but claim that latency is
> the highest priority on the other side.

In this case, latency and performance are not synonymous. Apparently, improvements have already been made to winealsa that make it pulse-friendlier. If those improvements continue enough, there is no need for winepulse.

It seems to me that pulse is used by people to whom latency isn't an issue as long as it is "good enough". If winealsa can be made equally "good enough" for pulse users, then it should be.

I think my previous statement wasn't quite clear. What I intended to say is that the only situation in which I'd favor a winepulse.drv is when nobody needs winealsa.drv because the pulse native API has become the a de-facto standard, and there's nobody who does not use PulseAudio.
(I personally don't think this is likely to happen)

If under such circumstances there are still users who prefer not to use PA, a winealsa.drv could be test-wise maintained out-of-tree to see if it retains critical mass. In case anyone says this would be developer ignorance: Our resources are limited. We have to be ignorant sometimes. Currently, the situation that Linux changes sound APIs like underwear forces us to deal with this situation instead of doing the work we'd actually want to do: Make Windows apps run better.

The fundamental problem is that it's more sexy to write something new, rather than fixing existing solutions.

(In reply to comment #165)
> I think my previous statement wasn't quite clear. What I intended to say is
> that the only situation in which I'd favor a winepulse.drv is when nobody needs
> winealsa.drv because the pulse native API has become the a de-facto standard,
> and there's nobody who does not use PulseAudio.
> (I personally don't think this is likely to happen)

Why do you assume a need for dropping winealsa.drv?
If you really absolutely need to drop a driver to add a new one - drop the obsolete wineesd.drv in favor of the working winepulse.drv.

EsounD is EOL and PulseAudio is it's replacement. PulseAudio isn't going to go away, especially not on the large desktop distros - even Skype and Adobe accepted that one.

The patches are there, they compile, seem to work (at least here) and they are a solution to a realworld problem: Running Windows Games with sound hassle-free via Wine on a modern desktop distro like openSUSE, Fedora or Ubuntu. And, to be honest - those are the main targets for people switching from Windows. And Wine targets exactly those people: http://wiki.winehq.org/ImportanceOfWine#head-5de2e9203c0811bff87c77b0fa026f0b0753a117

Sure, when the new sound system hits Wine, all of that needs to be implemented again. But a good solution today is better than a perfect solution tomorrow - even if it's just a stop-gap solution.

I thought wineesd had been dropped a long time ago, along with winearts. The main reason for dropping drivers are maintenance efforts.

I am fine with having multiple drivers to deal with different OSes. winecoreaudio for OSX. Wineaudioio for solaris. winealsa for Linux, etc. I don't understand why Linux needs 5 different audio APIs, while every other system works just fine with one. I don't care what it's name is, just give me one system that (a) is available everywhere, (b) doesn't need manual user setup, (c) provides low latency and (d) allows software mixing. Windows gets that done. OSX gets that done. How hard can it be?

(In reply to comment #167)
> How hard can it be?

Pretty hard, obviously. ;)

The thing is, while ALSA alone may catch a) and c), b) and d) always were an issue for a normal user.

PulseAudio, on the other hand, certainly excels in b) (just look at the new gnome-volume-control) and obviously d). While it's not yet as optimized for c) - the latency of winepulse.drv is way better than the up-to-1s latency of wineesd.drv when connected to PulseAudio.

As for a), PulseAudio is the choice for the desktop distributions - and, while technically irrelevant to Wine because of ARM chipsets, even Nokia's Maemo and Palm's WebOS use PulseAudio on mobiles.

Any sound system that's supposed to be configuration-free shouldn't need a wiki page like this: http://www.pulseaudio.org/wiki/PerfectSetup . Or this: http://alsa.opensrc.org/DmixPlugin.

I personally didn't have any issue with software mixing or manual configuration with Alsa+dmix, ie, without PA in the past 3 years. Yeah, a long time ago I had to config dmix manually. On my two Ubuntu distros I get long sound delays with PA, even in Tuxracer. But as this discussion indicates, other people had different experiences.

Let me define my personal criteria for when the Linux sound system is useable: I have a lot of different computers here. I am using a few non-wine Linux apps with sound(skype, ut2004, quake 3, amarok, some other voip app, tuxracer.

To stick with the number 6: I want to be able to download 6 different distros, install them on any of my computers. I don't care what the sound system name is, but it should be the same on all of them. I don't care what kind of API it uses. I don't care what API the different apps talk to it with. But I want sound in all of my 6 sound apps working out of the box in all 6 distros on all of my 6 computers. Once these 6*6*6=216 combinations work out of the box, I'll say that the Linux sound system is useable.

This discussion is quite unnecessary and off-topic, but I guess most people participating already know that.

Personal opinions about PulseAudio aside, the way to get a PulseAudio driver into Wine would be to first fix Wine's audio driver architecture, and implement the driver afterwards. Neither of those is entirely trivial, but most people (understandably) probably aren't interested in the first part. I think it's extremely unlikely that anything said in this bug will change any of that. If the goal is improved sound support for Wine with PulseAudio, improving winealsa/PulseAudio interactions on both sides is probably a more realistic option.

(In reply to comment #169)
> Any sound system that's supposed to be configuration-free shouldn't need a wiki
> page like this:

Sure, that's why there is the new Volume Controle in GNOME 2.28, making use of PulseAudio's capability to be reconfigured on runtime.

Give it a try.

(In reply to comment #170)
> Personal opinions about PulseAudio aside, the way to get a PulseAudio driver
> into Wine would be to first fix Wine's audio driver architecture, and implement
> the driver afterwards.

Why would the first part be a prereuisite?

Sure, it's the nice way of doing it, but there are people waiting to use Wine. Those would really apreaciate a stop-gap solution like the working, existing winepulse.drv.

(In reply to comment #171)
> > Personal opinions about PulseAudio aside, the way to get a PulseAudio driver
> > into Wine would be to first fix Wine's audio driver architecture, and implement
> > the driver afterwards.
>
> Why would the first part be a prereuisite?
>
Because the current architecture doesn't scale that well. You're free to try of course, but I think you'd have a hard time trying to make a convincing case to Alexandre that that part can be skipped. Realistically, I don't think that requirement will go away anytime soon.

Doing that part would also make a more convincing case that you (whoever would implement it) know what you're doing, which would make the second part more likely to go in, but that's secondary here.

> Sure, it's the nice way of doing it, but there are people waiting to use Wine.
> Those would really apreaciate a stop-gap solution like the working, existing
> winepulse.drv.
Well, winepulse.drv exists, it's just not supported by the Wine project. That creates issues for people reporting bugs while using it, but that's the trade they make.