Bug Description

Binary package hint: wine

I'm running the Spotify Windows application on two laptops under Wine with both internal and external USB sound card. With both cards you get the occasional pop and click in the sound suggesting some data loss somewhere.

I've selected the alsa drivers in winecfg and the whole thing is running via the alsa compatibility layer in pulseaudio.

It's more pops and clicks - suggesting either a latency delay for a
few milli-seconds or the odd usb packet loss. My gut feeling is that
it is delay rather than loss.

Spotify caches tunes in the Windows file system and you get the same
problem replaying a track from the cache - so it doesn't appear to be
buffer exhaustion due to delay over the TCP network. When you get that
the music usually stops for several seconds while it finds a better
peer.

2009/5/5 Steve Dodier <email address hidden>:
> Hello,
>
> What do you mean by sound drops ? Do you mean that it stops and you have
> to restart Wine, or the music stops for a few seconds and then runs
> again ?
>
> ** Changed in: wine (Ubuntu)
> Status: New => Incomplete
>
> --
> Occasional sound drops in Wine
> https://bugs.launchpad.net/bugs/371897
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm not sure Spotify caches the *whole* song, because songs can't be played at all if you're offline. How is your CPU when you listen to music ? Thats not likely but if you abuse your CPU or if it's really old, it could be latency while decyphering the songs, too (since they're encrypted).

Also, you might want to try Wine 1.1.20. I used Spotify a few days ago on Jaunty, with this version, and I didn't have any lags, despite my terribly low bandwidth !

I'll run up the latest 1.1.20 packages from WineHQ and see if it makes
any difference. I don't think the processor is that taxed - usage is
in the 20% range. The first laptop is a brand new Acer Aspire Netbook
with a dual core Atom processor and the other laptop is a T5300 -
which isn't that much of a slouch.

The problem is more pronounced on the slower netbook while using the
USB Audio interface to the external DAC unit.

And regrettably I don't get any of these issues if I switch to the
Dark Side of the Force and run Spotify in Windows.

2009/5/5 Steve Dodier <email address hidden>:
> I'm not sure Spotify caches the *whole* song, because songs can't be
> played at all if you're offline. How is your CPU when you listen to
> music ? Thats not likely but if you abuse your CPU or if it's really
> old, it could be latency while decyphering the songs, too (since they're
> encrypted).
>
> Also, you might want to try Wine 1.1.20. I used Spotify a few days ago
> on Jaunty, with this version, and I didn't have any lags, despite my
> terribly low bandwidth !
>
> --
> Occasional sound drops in Wine
> https://bugs.launchpad.net/bugs/371897
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Alright, there is something I forgot, as I'm myself not using it :
PulseAudio :)

Try to shut PulseAudio down (set ALSA in your sound preferences, everywhere,
then "ps aux | grep pulse" then for each PID (second number from the left)
"kill -9 PID", and make sure it doesnt spawn back by doing another ps aux
after - if it does spawn back, modify /etc/pulse/client.conf with a text
editor, and change autospawn to false).

Once Pulse is down, change the sound driver of Wine to ALSA in winecfg, and
tell me how the sound is.

The Wine devs are extremely aware of the problem with PulseAudio, but I
don't think it's a priority, as they currently work on Wine 64bit
applications and Directx10, amongst other things. There isn't much we can do
by the meanwhile. I'm personnally under Xubuntu, I don't have PA and Spotify
rocks here.

I have created a version of the wine1.2 package that includes a native PulseAudio driver for wine. This packaged 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.

I've encountered this issue recently with the customized builds from the ~neil-aldur/+archive/ppa repo. The sound works perfectly for a while, but after a while it ends up messing up pulseaudio and I don't get any sound till I start a new session. I'll try to get a debug report next time it occurs.

Can you try the vanilla wine1.2 in the archives (which will go via the
pulse alsa redirector) and see if you get the same problem.

Pulseaudio has been much improved and I want to see if there is still
a problem with just going via the alsa redirector.

2009/9/10 Matt Walker <email address hidden>:
> I've encountered this issue recently with the customized builds from the
> ~neil-aldur/+archive/ppa repo. The sound works perfectly for a while,
> but after a while it ends up messing up pulseaudio and I don't get any
> sound till I start a new session. I'll try to get a debug report next
> time it occurs.
>
> I had this issue with the 1.1.28 version of the neil-aldur Wine
>
> --
> Occasional sound drops in Wine via PulseAudio
> https://bugs.launchpad.net/bugs/371897
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Mon, Oct 12, 2009 at 12:02 PM, Phil Moorhouse
<email address hidden> wrote:
> Spotify will play somewhere between 2 and a dozen tracks, and then start
> to stutter and not recover until it's restarted. This is not a network
> issue as it happens with cached playlists also.

When I use the default "wine1.2" (1.1.31) in karmic, with its default of ALSA audio output, the sound in World of Warcraft is extremely jittery. When I play a test sound with the ALSA audio output plugin configured (in winecfg), it jitters out part of the sound and then freezes.

When I use Neil Wilson's PPA of wine w/ pulseaudio, and then configure wine to use the pulseaudio plugin, sound works perfectly (so far).

I'm not very happy about using a version of wine that's not condoned by the wine upstreams, but they (or the Ubuntu developers) need to fix *something* for wine audio to work in karmic.

With Spotify I get very heavy jitter and stuttering right after a
track change using the Alsa driver on 1.1.31. Even closing Spotify and
restarting often has no effect. The only solution is a logoff, or to
kill the pulseaudio daemon.

The new 0.32 Winepulse driver is a smoother experience and the hanging
appears to have gone. However there were occasional pauses last night
that I couldn't work out if it was network congestion or the driver.

Pulseaudio + Wine (Spotify) still has random problems in Karmic beta (9.10) with all the updates applied as of today (14 oct 2009, 01:43am GMT-7). Audio from Wine occasionally makes clicking sounds, and sometimes the audio is completely garbled. Seems a random issue associated with changing songs in Spotify. As Neil pointed out above, a solution which sometimes works is restarting pulseaudio and/or Spotify. I have not experienced this in Ubuntu 9.04.

With all updates applied as of 14 Oct, 10:00am BST using vanilla wine1.2 (1.1.31-0ubuntu1) from the Kamic sources, I'm still experiencing occasional pops and crackles fairly regularly, and then eventually permanent stuttering that can only be resolved with a restart of Spotify. Please see attached trace.

I spent the last couple of days running Neil's package and did not experience any stuttering during that time - I've moved back to the vanilla package to try and give some feedback on this issue.

The standard Karmic wine1.2 does not produce any normal sound in foobar - it's stuttering.
The wine1.2 packages from Neil Wilson solve those problems - thanks! I hope this patch can be included in the wine1.2 package from Ubuntu.

Another question: if the standard ubuntu repo's do update their wine version earlier than the ppa, I will get an unpatched version which will destroy my wine sound experience. Is it possible to block wine1.2 updates from Karmic's repo's?

I also installed Neil's version of Wine w/pulseaudio and I'm pretty satisfied (had all sorts of clicking and popping before). However, the sound will still occasionally drop out completely and the only way to get it back is to restart whatever application in wine (I'm usually playing WoW). Not sure if this is an issue with this version of wine or with pulseaudio itself. Anybody have any ideas how to track down the main culprit?

I also installed Neil's version of Wine w/pulseaudio and I'm pretty
satisfied (had all sorts of clicking and popping before). However, the
sound will still occasionally drop out completely and the only way to
get it back is to restart whatever application in wine (I'm usually
playing WoW). Not sure if this is an issue with this version of wine or
with pulseaudio itself. Anybody have any ideas how to track down the
main culprit?

@Robert Shaw: I've experienced the exact same problem with audio dropping out entirely while in WoW using Niel's Wine-pulse. For the record, apparently you don't need to restart it entirely; you can just get WoW to reinitialize its audio stack by going into sound preferences and toggling "use hardware" (which doesn't seem to do anything in wine, as far as I can tell, but does get it to give audio a kick-start).

2009/10/22 Christopher Armstrong <email address hidden>:
> @Robert Shaw: I've experienced the exact same problem with audio
> dropping out entirely while in WoW using Niel's Wine-pulse. For the
> record, apparently you don't need to restart it entirely; you can just
> get WoW to reinitialize its audio stack by going into sound preferences
> and toggling "use hardware" (which doesn't seem to do anything in wine,
> as far as I can tell, but does get it to give audio a kick-start).
>
> --
> Occasional sound drops in Wine via PulseAudio
> https://bugs.launchpad.net/bugs/371897
> You received this bug notification because you are a direct subscriber
> of the bug.
>

> Is that with the up to date package?
>
> 2009/10/22 Christopher Armstrong <email address hidden>:
> > @Robert Shaw: I've experienced the exact same problem with audio
> > dropping out entirely while in WoW using Niel's Wine-pulse. For the
> > record, apparently you don't need to restart it entirely; you can just
> > get WoW to reinitialize its audio stack by going into sound preferences
> > and toggling "use hardware" (which doesn't seem to do anything in wine,
> > as far as I can tell, but does get it to give audio a kick-start).
> >
> > --
> > Occasional sound drops in Wine via PulseAudio
> > https://bugs.launchpad.net/bugs/371897
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>
> --
> Neil Wilson
>
> --
> Occasional sound drops in Wine via PulseAudio
> https://bugs.launchpad.net/bugs/371897
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I just upgraded my karmic system to all the latest packages (including PulseAudio and the stock Wine package) and my sound on WoW now works fine using the ALSA wine output plugin. I no longer need Neil Wilson's wine-pulse PPA.

At least, this is true after about 10 minutes of play. I'll report if it goes downhill.

Sorry, I spoke too soon. It started going choppy for a few seconds at a time, and now it's choppy all the time, just like it used to be. I guess it's not totally deterministic; it must be sensitive to something environmental on my system, but I'm not sure what. All other sound-producing programs are working fine.

(In reply to comment #374)
>> The main reason it was not accepted was that julliard chose not to even review
>> my patches, so how am I supposed to get it merged in mainline then?
> You've made it clear you're not willing to work within the current Wine
> development process. I don't think it's unreasonable for us to avoid wasting
> time reviewing your patches in that case.
Please don't let facts get in the way.http://www.winehq.org/pipermail/wine-patches/2012-March/111968.html
"I no longer expect it for v1.4, but hopefully post 1.4 it will be included"

> The only 'review' I got was from Dmitry Timoshkov, see:
> "> Date: Thu, 28 Apr 2011 09:45:18 +0200"
> "You forgot to fix the date, 1 Apr would be more appropriate I'd guess."
>
> http://www.winehq.org/pipermail/wine-devel/2012-February/094459.html
That certainly wasn't the only comment you got, but regardless. The relevant
context there was of course that you submitted a huge patch about a week before
Wine 1.4 was released, when we were deep in code freeze. Of course nobody is
going to take you seriously then.

(In reply to comment #380)
> (In reply to comment #374)
> >> The main reason it was not accepted was that julliard chose not to even review
> >> my patches, so how am I supposed to get it merged in mainline then?
> > You've made it clear you're not willing to work within the current Wine
> > development process. I don't think it's unreasonable for us to avoid wasting
> > time reviewing your patches in that case.
> Please don't let facts get in the way.
> http://www.winehq.org/pipermail/wine-patches/2012-March/111968.html
> "I no longer expect it for v1.4, but hopefully post 1.4 it will be included"
>
That's a different mail than the one Dmitry responded to.

Anyway, I'm not interested in discussing the how and why of the situation further with you, it's pointless. If you want to think the reason your patches got rejected is because the Wine project is full of unreasonable people that's fine, for all I care. I just want to make a couple of things clear for everyone else:
- http://repo.or.cz/w/wine/multimedia.git is unlikely to ever be included in upstream Wine.
- You're not speaking on behalf of the Wine project when you're asking distributions to include http://repo.or.cz/w/wine/multimedia.git in their Wine package.
- Andrew is still working on a PulseAudio driver, it will get there eventually. Doing things right takes time and effort.

And before I start, I have nothing against any person named in here, just think the process of accepting patches could see some improvement. This is from my point of view, and from memory, so it may not actually have happened as I claim it to be, since I don't have a perfect memory, and I'm biased.

If I had to guess, this all goes back to winegstreamer in 2010, I was working on that and had the core code ready where gstreamer plugins could be used as a replacement for certain codecs wine was missing. The code itself was not perfect of course, but that was not the real reason for its rejection. I needed some code from dlls/quartz to make it work, but it was impossible to share code between since there had to be common code. Unfortunately without much more than terse feedback, I didn't know how to work on it and Aric Stewart was working on that instead. I said before he started working on it that the winegstreamer code was nearly ready, but the work on strmbase (common code) took a lot of effort. So in 1 way I was right, but the work on the common code caused a lot of delay, so in another way I was completely wrong. As you can see from git log dlls/winegstreamer, there have been a few fixes and some development to implement qos (frame dropping), but that was to be expected as more people started using it. The code is probably more complicated than it had to be, since I tried to act like the

Andrew Eikum was assigned to work on replacing the sound system for mmdevapi from the old openal based one which I was responsible for, and didn't turn out to be a good match for mmdevapi. Yes this was completely my fault, but I did think at the time, and still do, that openal-soft is really nice to have to replace our crappy dsound implementation with. Fortunately it's still possible, since the author of openal-soft added an extension so that we can use openal-soft to mix sound, but use our own sound system for playing the mixed sound. But I degress.

While the switching of audio stacks to mmdevapi was still in progress, I tried to do some work to convert dsound to mmdevapi too. But can't remember why it was not accepted, somewhere around april 2011. Around this time I also started to work on the winepulse mmdevapi driver, which was originally meant so I would have sound in the 2 games I played at the time, but not with enough quality to be used further. I always intended to get it done right since I already knew that winealsa + alsa-pulse would never work right for pulseaudio. I then took a break from wine, still sometimes sending patches but I didn't keep the git tree mentioned synced with my local tree, and I mostly used wine as a user, not as a dev.

Somewhere in januari or februari 2012 I noticed that there was interest in pulseaudio support again, and that wine finally accepted that winepulse just had to happen. So I did what I always intended to do, and cleaned up my winepulse patch. The
final version I submitted was nothing like the earlier versions, I completely reworked the capturing to be packet based like the mmdevapi tests indicate, and rendering I used the pulseaudio callbacks, so that whe...

Maarten, you have to understand that your reputation with the project is not very good right now. You didn't do anything to improve it by sending huge patches during code freeze and submitting a git-pull request when you know that isn't how Wine code submission works. No one is interested in reviewing a 3 kLOC patch from someone with a bad reputation.

This is why I asked you on IRC to work on improving your reputation first. As I've said, I'm happy to review reasonable-sized patches and ask that they be committed. You have to show that you're willing to work with the project, even the parts of it that you don't like, to have the trust level required for being responsible for important parts of the code.

(In reply to comment #382)
> I'm willing to resubmit the whole patch series of multimedia.git.

This is the problem. It takes a lot of trust to accept huge, difficult-to-review patch series. Start small and simple (I think you said you have dsound improvements?) and build up from there.

I know I'm just a user and I probably don't understand much of wine's developement, but Maarten put a lot of effort into a patch that fixes an issue ( or a serious lacking, up to you ) that wine'd had for 5 years now, shouldn't that be enough to prove himself to the devs' team? At least take a look at his work, everybody who tested it can say how well it works, and it's surely better than the other pulse patch around. Heck, it even makes games run smoother now that alsa/pa don't hog the cpus anymore.
Even if you still don't trust him, or if he committed some errors in the past, you have to face the actual situation: years ago pulseaudio was considered ( by some ) to be the future of sound management for linux, writing a driver for it was pretty much a gamble, especially since wine already had a ton of other drivers that could work with pa. Right now though, pa is the default on many distros, including the most popular ones, and it's actually been like that for a couple of years. How much longer will this have to carry on? Wine's support for pa should be a must right now, sticking with alsa is just not viable anymore ( you don't believe me? Check how many distros ship a patched wine with pa support ), and waiting for Maarten to "prove himself worthy" by doing unrelated work will just push back this necessary feature for how much? Months? Years? Even worse, the other pa patch could be included in wine before that, the one with many sound issues and that still causes cpu spikes, and that'd just make harder ( if not impossible, or "not worth it" ) to include the only working pa support we have right now.
Seriously, at least take a look at his work and give some technical reasons why you don't want to include it in upstream wine, else it'll keep looking like you just don't care about pa for personal reasons, as I ( and probably other people ) think. It's really time to catch up with the present.

As a user, I also agree that the patch should be reviewed. I have yet to see a valid reason for not reviewing the patch - it having been submitted while in code freeze has no relevance to the code itself, and while the size of the patch might mean that it will take a while to review, it is still better to do that sooner rather than later. It does not look like the patch is going to get smaller any time soon.

Of course, if there is something that Maarten can do to make the process easier - like splitting the patch into modular pieces - I would imagine it would be appreciated.

It's alright, it will happen eventually. The wine devs have gone through the denial phase (Pulse is "not capable", it's not shipped by default on "most distributions", "ALSA compatibility is a better solution" somehow). They're just finished the anger phase (completely badgering Maarten and his work). Now they're finally in the bargaining phase ("build some reputation again and maybe we can talk") where we can start making some progress.

It's a shame that the only basis the wine devs have to reject the patch any longer is based on "reputation issues" rather than actual technical arguments. There may have been some in the past, and now there isn't anymore so they're still struggling to find reasons to reject the patch in order to preserve the reality they've built for themselves over the entire 1,794 days during which this bug has been open. It's normal -- it's simply a defence mechanism; they don't want their own reality to crumble down, so they rationalize away their reasoning, which deep down they know to be flawed, but they convince themselves that it's not.

They'll get over it eventually, it will just take some more time. Until then, we as users should just keep using patched Wine releases and patiently wait for them to come out of their comfy artificial shell.

Now, one of three things is going to happen: Either they will simply ignore this post despite knowing it to be true, either they'll cherry-pick one or two statements and provide non-technical arguments as to why they don't stand (and somehow, refuting that subset of the post invalidates the entire post), or maybe (just maybe!) they'll see things for what they really are and actually start working *with* Maarten (and, by extensions, most users of Wine) instead of *against* Maarten.

I wish Maarten the best of luck in his work and his interactions with the Wine devs. I also want to express my appreciation towards his work, without which Wine would simply not be usable at all for me.

I see no mention here of technical objections to Maarten's work; in fact, it sounds as if the Wine development team turned their noses up at it without even looking it over. So Maarten committed a faux-pas by submitting his patch at a bad time; is this ***really*** such a harsh crime that you are doing right by the end-users in punitively ostracizing him? Seriously?

This all looks like more of the same silly bureaucratic/political posturing to me that we've been seeing here all along, which is a huge disservice to us end-users who are still waiting for this major 5-year-old issue to be properly resolved. You should be ashamed of yourselves for acting so self-righteous, both at the expense of us end-users and as an insult to the greater spirit of collaborative open-source software development.

My advice is to have Andrew stop wasting time reinventing the wheel, and at least review Maarten's work and collaborate with him to work through any issues prior to merging. We all know that Maarten has a very mature patch that is already being field-tested by hundreds (at least) of end-users, and he has been very eager for and responsive to feedback. We're not being fooled into thinking that Maarten or his work should be shunned.

While as a fellow developer I understand the point of core Wine developers of not accepting large and complex patches who, by previous experience, is unlikely to be there to maintain it in the future, thus putting the maintenance burden of this new code on the very same core Wine devs, ...

... at the same time considering the time frame of the bug, importance of the bug to a large fraction of Wine users and the fact that the solution is already well tested and used by most users of distribution packages, IMHO core developers should bite the bullet and try to review this code on its technical merits and have one of the core devs take over the responsibility for the patch, its further development and inclusion into core.

Continuing to keep this out-of-tree is guaranteed to keep the annoyance going for all parties involved.

Aside from political stuff, I guess we all agree we need traction in this feature.
If I got it correctly, Maarten has a fully functional patch, but it can't be reviewed because of its size and non-technical reasons already enough discussed. Also, Andrew seems to be working on the same thing, but apart from Maarten, having unnecessary additional work.

So there are two steps needed:
1.Small, punctual patches from Maarten, which can be reviewed one at a time, be accepted and improve both Pulse support state and Maarten reputation. Maarten said he already worked in splitting the patch before, so there's already a way to go.
2.Willingness from Wine devs to review Maarten patches. Andrew already said that's OK, so no issue.

I posted some patches on mailing list to knock some sense into the dsound mixer, pending moderation, and I have 3 more patches locally when those get accepted, one to make DSOUND_ReopenDevice never fail halfway any more no matter the error and save a copy in mixing to non-float, another to fix DSOUND_WaveQueue, and another to remove device->state.

In my local tree (patched with rtkit and winepulse) I could run dsound with 1 ms total queue latency, and there were not enough underruns to fail the interactive dsound tests. Of course there were still some, but I didn't disable my cpu's higher C-states, plus the latency itself is so ridiculously low that it's really only meant for testing.

@comment #289

No, I've been actively maintaining it in ubuntu-wine ppa, updating it every 2 weeks, and fixing bugs when people report them.

So, it's been a month since the last update about this... How are things going? Will winepulse make it into upstream? Has there been an actual collaboration between Maarten and the devs?
Also, just for the record: http://www.phoronix.com/scan.php?page=news_item&px=MTIxOTg
By the way, I think this should be changed to major, since the lack of sound in most (if not all) applications should be probably considered a "major loss of functionality for a wide range of applications"

(In reply to comment #392)
> So, it's been a month since the last update about this... How are things going?
> Will winepulse make it into upstream? Has there been an actual collaboration
> between Maarten and the devs?

> Also, just for the record:
> http://www.phoronix.com/scan.php?page=news_item&px=MTIxOTg
> By the way, I think this should be changed to major, since the lack of sound in
> most (if not all) applications should be probably considered a "major loss of
> functionality for a wide range of applications"

Check the first comment, it's a feature request => enhancement.

Pulseaudio is supposed to be compatible with ALSA, which Wine already supports, and sound does work for a lot of use cases.*

*Note: This is not meant to restart the debate about Pulseaudio/Wine/etc. I'm explaining why, as a bugzilla admin, I'm not marking it major.

(In reply to comment #393)
> Patches have been sent, people posted reviews/comments. E.g.,:
Thanks a lot for the info!

(In reply to comment #393)
> Check the first comment, it's a feature request => enhancement.
>
> Pulseaudio is supposed to be compatible with ALSA, which Wine already supports,
> and sound does work for a lot of use cases.*
>
> *Note: This is not meant to restart the debate about Pulseaudio/Wine/etc. I'm
> explaining why, as a bugzilla admin, I'm not marking it major.
Sounds fair, but since it's been 5 years since that post, I thought it was worth asking :p

(In reply to comment #396)
> I was waiting to ask this as well... Since wine 1.6 is out now, will winepulse
> be one of 1.8's goals? I haven't seen many references to this on the mailing
> list either lately

Just a friendly reminder, but after another 4 months of waiting, how is this being handled? Is pulseaudio support still considered trivial/unneeded, although it's mandatory on some systems (eg. those on which a good/easy way to control audio streams is needed)?

Predictions made by <email address hidden> (Martin Jürgens ) on "2007-11-18 13:13:06 CST" are basically already true today. Many distros have switched to using pulse audio as their default-shipped audio system, and many things have audio issues on these distros when run in wine, DESPITE the distros patching in winepulse support (that outside devs had to create because wine devs couldn't be bothered).

The reality of the situation is that pulse is not completely back-compatible to alsa,and this creates problems that could potentially be avoided by wine. It might be pulseaudio's fault, but defining where blame lies isn't important, a functional application that doesn't require extensive user intervention IS. You guys really ought to get on top of this sooner rather than later.

(In reply to Rosanne DiMesio from comment #400)
> (In reply to Michael Gooch from comment #399)
>
> > audio issues on these distros when run in wine, DESPITE the distros
> > patching in winepulse support (
> >
>
> Doesn't that just prove that a winepulse driver is NOT the answer to the
> audio problems some users still have?

It certainly proves that having a solution cooked up by the distro package managers isn't a proper solution.

However, asking users to disable winepulse and go through considerable configuration to avoid the audio stutter isn't really a solution either, its a hack around a problem that hasn't been solved. It also stands a very good chance of causing issues in non-wine apps if the OS or other apps expect pulse to still be configured according to release-specs and develop accordingly.

If the compatibility were wine-native instead of hacked in, theres a chance the wine devs' way of doing it would be far more efficient and better coded for the way wine works as they have a better knowledge of the wine backend than the distro package managers do.

Wine should just work, out of the box, without breaking in unexpected ways that force users to dredge the internet looking for configuration options to fix their system around this bug. If this were just a small number of relatively obscure distros i'd understand the thinking, but the major distros have made this switch, and wine now has to make a choice in how they're going to adapt to it. So far, they haven't adapted at all.

If you want to try to influence the various distros to dump pulse I'd support that idea, but chances are they're not going to.

(In reply to Rosanne DiMesio from comment #400)
> (In reply to Michael Gooch from comment #399)
>
> > audio issues on these distros when run in wine, DESPITE the distros
> > patching in winepulse support (
> >
>
> Doesn't that just prove that a winepulse driver is NOT the answer to the
> audio problems some users still have?

Following this logic, Wine is not the answer to run programs not natively ported on Linux, and it should've been dropped years ago.
This doesn't have to be perceived as criticism towards Wine of course, since it has improved greatly since it actually required a lot of work to make simple programs work on it. In fact, Wine is a good example of how something buggy can become more and more stable when people keep working on it... Wonder what would've have happened if the majority of its developers would've just said "screw developing Wine, just dual boot Windows" and dropped coding Wine.

Like it or not, Pulseaudio is a reality now (it has actually been such for quite a few years), and it is time to actually deal with it. Also, I'd like to note that alsa's support for pulse has always been buggy, and has made little to none improvement in the last years, at least not where it matters or enough to let wine provide a working, continuous and appreciable sound output. I understand it takes less effort to say "blame alsa-plugins, not us" than maintaining a proper pulse driver, but you actually already have some people who'd do that for you.

Also, please, stop pretending that at this point Pulseaudio can be dropped in favor of alsa. Doing that implies the loss of a good deal of features which may actually be essential to some users, and it is also quite foolish to suggest user to do so. What's the point of Wine becoming more stable and needing less and less tweaks to make programs run on it, when users would still have to do a good deal of tuning to force alsa into their systems (as long as it is still possible)?

Winepusle is buggy, yes, but it offers far better support to audio output than wine's alsa driver is doing right now. It's not perfect, indeed, but at least it offers FUNCTIONAL audio output. To be fair, I can't see how the issues that the current alsa driver is causing (from stuttering audio to the complete lack of it, passing through random and loud ear-unfriendly noises) isn't seen as a major (if not critical) bug, causing a good loos of functionality.

What's the point right now to keep winepulse out of Wine? It isn't doing worse than winealsa is, it'll make some people stop complaining, it'll save time for several packagers... And it wouldn't even mean the removal of winealsa, for those who don't want Pulseaudio on their system.

Please, just hear the users who have posted on this bug report since 2007: at first it was just a feature request, but as years passed it become something more, something necessary due to the evolution course of most Linux distros.

While I agree, there's sadly no point in arguing. The Wine devs are so irrationally close-minded about this issue that they even resorted to semi-personal attacks against people attempting to provide winepulse audio drivers and citing of silly procedural issues as an excuse to avoid having to incorporate fixes.

It's always sad and frustrating to see open source projects be so insensitive to the concerns of end-users, but when people go so far as to contribute actual code changes and still be rejected out of hand, there's just nothing to be done.

Situations like this are what cause a lot of projects to fork, which is the worst way for things to work themselves out because it causes the community to split their efforts.

(In reply to Ben Shadwick from comment #403)
> The Wine devs are so irrationally close-minded about this issue

OK, stop there before this descends into a flame-war.

> citing of silly procedural issues as an excuse to avoid having
> to incorporate fixes.

Those "procedural issues" relate to code quality and cooperative functionality with other modules. Winepulse is not up to scratch.

> It's always sad and frustrating to see open source projects be so
> insensitive to the concerns of end-users, but when people go so far as to
> contribute actual code changes and still be rejected out of hand, there's
> just nothing to be done.

I've been out of the loop for a while, but last time I was actively commenting on this bug Wine devs were planning an architectural change in the way audio drivers work. Even before that, they were hesitant to include ANY new audio drivers because the existing framework employs a lot of code duplication.

> Situations like this are what cause a lot of projects to fork, which is the
> worst way for things to work themselves out because it causes the community
> to split their efforts.

The only people to have successfully forked Wine are Codeweavers (Crossover Office et al) and that's only because they work closely with Wine devs. It's a huge project. Every bugfix is like a pharmaceutical drug: it may fix a problem, but will almost certainly have unforseen side-effects.

One of my major objections to the existing Winepulse code is that it seems to completely ignore MIDI support. Even without the other hurdles to inclusion, an audio driver simply would not be considered if it will completely break applications that ask for MIDI.

(In reply to Ben Klein from comment #404)
> One of my major objections to the existing Winepulse code is that it seems
> to completely ignore MIDI support. Even without the other hurdles to
> inclusion, an audio driver simply would not be considered if it will
> completely break applications that ask for MIDI.

Although that is a major flaw on winepulse's part, it is something that can be implemented (especially if more people can would work on it upstream), and the same goes for any other other feature. The current winealsa, on the other end, has to rely on a (bugged and not reliable, as it has proven itself) third party plugin to provide any audio output on most current distros, and it can't really be tweaked according to wine devs' desires.

That doesn't count at all? Or is someone actively working on a better solution to this 8 years old problem?

To avoid further discussion in this bug report, which seems to come back to life every so often, could you (Wine's staff) set up a place where it can be held, and where devs would actually give us (wine users) some kind of information about this issue? Mailing lists aren't so easy to follow when one doesn't have the time to dig through it all (I may be wrong, but the newest information regarding winepulse on wine-devel is months old), and having someone rationally explaining why winepulse is being kept away from upstream (in a non-wiki form, where users could actually ask questions and explain their perplexities and needs, and where they'd be able to hear actual devs explaining the technical difficulties, with a real interaction between the two) would prevent this bug report being flooded, AND it could also help to improve the general opinion of Wine devs (which some claimed to be narrow minded and refusing winepulse by personal believes/grudges rather than technical reasons).

Simple answers (eg. "we're working on it", "talk about it somewhere else", "read wine-devel") won't really prevent this discussion to spawn again in the future, isn't it better to face this problem now, after 8 years? I know users don't really have the right to make any demand to developers, but so far we've been ignored, threatened to being suspended from being able to post bug reports, and mocked (as it has been said in the forums sometimes, "install alsa or disable sounds" and such, which is plain mockery as some people actually need pulse for a reason or another), I believe we deserve some clear answers after all that.

So please, I beg you, set up a place where devs and users can, even for limited time, have a constructive chat about this issue, so that everyone can have an idea of what is actually gonna happen in the future regarding an upstream pulse driver.

For the record, no one's been advised to remove PulseAudio for years, not since the audio rewrite in 2011. The Sound wiki page explicitly advises against removing it, and that page is where I refer users to if the problem is not something obvious (e.g., user is missing 32 bit alsa-plugins). I have certainly never "mocked" anyone for using PulseAudio: I happen to use it myself.

(In reply to Ben Klein from comment #404)
> (In reply to Ben Shadwick from comment #403)
> > The Wine devs are so irrationally close-minded about this issue
>
> OK, stop there before this descends into a flame-war.

Stop what? To me this seems to be an accurate description of the actual issue we are facing here.

Ignoring the real issue is not going to get us anywhere.

> > citing of silly procedural issues as an excuse to avoid having
> > to incorporate fixes.
>
> Those "procedural issues" relate to code quality and cooperative
> functionality with other modules. Winepulse is not up to scratch.

I haven't been very involved in the Wine community, but I do recall another bug report about dwrite breaking Steam because it wasn't yet working correctly. Not only was the dwrite code in the source tree, it was enabled by default (it shouldn't be).

If incomplete code known to break important applications is part of source tree, why isn't wine pulse there?

You say there are some "issues" with it. Sure, I can believe there are issues, however, code doesn't have to be perfect in order to be merged.

Most code is merged after all the obvious issues found in code review are addressed, sometimes with known issues and TODO's. Eventually one by one the issues are addressed.

Not merging the code because it's not "perfect" is irrational, and that's a fact.

I agree about putting up a status page somewhere. The wiki would work nicely.

This way we can have a link to the code for the driver and direct indicators of what needs to be improved.

Also, I don't want to start another flame war, but I'm thinking the driver MIGHT be ready to have a tag in the bug database. This might be a good policy for all unofficial branches.

Specifically, they should change the request that any bug that is verified to be caused by the PulseAudio driver (i.e. it goes away when mapping through ALSA). That way we know EXACTLY how much work needs to be done.

Created attachment 48661
mmdevapi: More accurately track device position

Hi folks,

I have a significant patch to the ALSA driver which I hope will improve audio playback for PulseAudio users, especially users with audio that stops playing or is choppy. Before I push this for inclusion in Wine, I was hoping to get some feedback from users still having issues using Wine with PulseAudio.

The patch is attached to this comment. It will apply to wine-git (d6a59f755eff), it will not apply to Wine 1.7.19. Please build unmodified Wine with this patch and let me know if this results in any changes to your audio situation. Please confirm in winecfg that you are using the winealsa driver before testing.

Specifically I'm interested to know:

What problems did you have before when using the ALSA driver? Are there any noticeable changes as a result of applying this patch? Do any problems remain?

What type of audio hardware do you have (e.g. a USB headset, built-in audio)? If possible, what make/model is it? "aplay -L" may give you a hint.

Andrew, Hello.
I compiled biarch wine using your patch, and I am very pleased with it.
Background.
I use wine to run Dragon NaturallySpeaking.
NatSpeak is a resource hog and works best with Lubuntu and a low-latency kernel, which I have. But I had installed pulseaudio just to get wine sound working.
NatSpeak needs to be installed in a 32-bit wine prefix because it is a 32-bit program with "handles" to make it run on 64-bit systems.
Test.
You patch installed problem-free.
I tried running NatSpeak with my current wineprefix. It worked and then it didn't... I'm not sure what the problem was. So I created a new wine prefix and re-installed NatSpeak.
Success.
Winecfg showed me "default" and my two sound cards, including my Sennheiser PC363D headset. I have .asoundconfrc set to call up Card 1, so the default setting called up my headset. Hooray. Selecting the Sennheiser option in winecfg did NOT work. Boo.
So then I tested it.
Great sound. Great accuracy.
Checked alsamixer. The settings showed it was being accessed and had set the volume in the microphone.
Then, I opened a browser and tried a youtube video at the same time as NatSpeak on wine. Both worked simultaneously.

My above post is confusing in one regard. I was able to get Youtube music on my linux Firefox, and NatSpeak on my wine, simultaneously.
I did one more test.
I set pulseaudio autospawn to No, killed pulseaudio, and started Natspeak wine. Natspeak worked great.
Andrew, you may wish to ask the developer listserv if this patch should be included in the regular code.

(In reply to Susan Cragin from comment #413)
> My above post is confusing in one regard. I was able to get Youtube music on
> my linux Firefox, and NatSpeak on my wine, simultaneously.
> I did one more test.
> I set pulseaudio autospawn to No, killed pulseaudio, and started Natspeak
> wine. Natspeak worked great.
> Andrew, you may wish to ask the developer listserv if this patch should be
> included in the regular code.

Mh... Sorry, do you mean that you had to kill pulseaudio to get a good audio output, or that the patch works well with and without PA?

> Mh... Sorry, do you mean that you had to kill pulseaudio to get a good audio
> output, or that the patch works well with and without PA?

On NatSpeak running in wine, I did not have to kill pulseaudio to get good audio. My understanding is (from looking at winecfg settings) that wine used alsa. And I think Linux/Firefox/YouTube used pulseaudio. I was using the same headset to dictate into Natspeak/wine and listen to YouTube/Linux.

So the patch works well with and without. I am always looking for ways to make NatSpeak work faster and better because it's the only program I really care about, so I was happy to kill pulseaudio (and every other non-essential service).
I'm a bit of a nut in that regard.