Occasional sound drops in Wine via PulseAudio

[Neil Wilson]

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.

Jaunty 9.04 UNR and standard Ubuntu desktop.

wine:
  Installed: 1.0.1-0ubuntu6
  Candidate: 1.0.1-0ubuntu6
  Version table:
 *** 1.0.1-0ubuntu6 0
        500 http://gb.archive.ubuntu.com jaunty/universe Packages
        100 /var/lib/dpkg/status

pulseaudio:
  Installed: 1:0.9.14-0ubuntu20
  Candidate: 1:0.9.14-0ubuntu20
  Version table:
 *** 1:0.9.14-0ubuntu20 0
        500 http://gb.archive.ubuntu.com jaunty/main Packages
        100 /var/lib/dpkg/status

[Steve Dodier-Lazaro (sidi)]

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 ?

[Neil Wilson (neil-aldur)]

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

--
Neil Wilson

[Steve Dodier-Lazaro (sidi)]

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 !

[Neil Wilson (neil-aldur)]

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

--
Neil Wilson

[Steve Dodier-Lazaro (sidi)]

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.

Cordially, SD.
--
Steve Dodier
OpenPGP : 0E5E4ECB
IRC : SiDi on irc.freenode.net
Jabber : <email address hidden>
<email address hidden>
https://launchpad.net/~sidi

[Neil Wilson (neil-aldur)]

The idea of filing this bug is to work our how to get Spotify/Wine to
work *with* pulseaudio and the standard Ubuntu audio stack.

Yes getting rid of Pulseaudio eliminates the problem, but it also
eliminates the ability to switch streams 'on the fly' between
different output devices.

How do we fix pulseaudio so that it works properly?

2009/5/5 Steve Dodier <email address hidden>:
> 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.
>
> Cordially, SD.
> --
> Steve Dodier
> OpenPGP : 0E5E4ECB
> IRC : SiDi on irc.freenode.net
> Jabber : <email address hidden>
> <email address hidden>
> https://launchpad.net/~sidi
>
> --
> 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.
>

--
Neil Wilson

[Steve Dodier-Lazaro (sidi)]

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.

[Neil Wilson (neil-aldur)]

There seems to be an ongoing debate as to whether to add a direct Pulseaudio driver to wine, or improve the ALSA conversion layer in Pulseaudio.

I think we need to get a consensus on which direction to take first - and that will determine which package gets this bug.

[tomten (fredrik-corneliusson)]

I had the same problem.
I found a workaround solution here (you do not have to disable PA just use OSS wine output instead):

http://www.matt-helps.com/how-to-stop-spotify-on-linux-audio-skipping

[Neil Wilson (neil-aldur)]

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.

If you try it, can you report back your experiences here please.

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)

Read more about the Winepulse patches and why they're not in the upstream source: http://art.ified.ca/?page_id=40

[Neil Wilson (neil-aldur)]

Note that once you install the package you will need to configure Wine to use the PulseAudio driver.

Select 'Configure Wine' from Applications menu.
Click the audio tab.
Select the PulseAudio Driver and deselect the one you are currently using.
Click apply.

Click Test Sound and if you hear a noise then you are in business!

[Ynot (tatkinson321)]

This patch to Wine works perfectly

I can successfully run WoW, Ventrillo & any number of native apps at the same time

Can we please get this patch into the main wine1.2 package? as the pulseaudio driver for Wine fixes all the little problems I had

Many thanks to all the people involved

[Matt Walker (matthaeus123)]

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

[Neil Wilson (neil-aldur)]

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

--
Neil Wilson

[Neil Wilson (neil-aldur)]

The latest karmic pulseaudio and wine1.2 packages appear to solve the sound skipping issue on all my platforms.

Is anybody still having problems with wine sound?

[Neil Wilson (neil-aldur)]

Updated wine1.1.30 with Winepulse 0.30 uploaded to ppa:neil-aldur/ppa

[Phil Moorhouse (phil-moorhouse)]

I'm having major problems trying to use spotify under wine1.2 package in Karmic beta (ALSA driver).

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.

Please see attached trace.

[Daniel T Chen (crimsun)]

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.

You should reproduce this symptom using current Karmic.

[Neil Wilson (neil-aldur)]

The Winepulse version on my PPA has been updated to winepulse0.32.
This has a fix that it supposed to prevent stream stalling.

The new 1.1.31 wine1.2 package on the main archives has sound fixes in
the version.

Can everybody with Wine sound problems retry the new vanilla 1.1.31
uplolad and if possible the Winepulse version on my PPA
(https://launchpad.net/~neil-aldur/+archive/ppa).

Please report your findings back here about the quality of the sound.

--
Neil Wilson

[Christopher Armstrong (radix)]

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.

[Yuri Alvarez (yurialvarez1984)]

I tried wine1.2 from Neil's PPA in Karmic Beta, and the sound problem is solved. Actually I didn't changed the audio config in winecfg. It works immediately after installing the package.

Thanks!

[Scott Ritchie (scottritchie)]

Yuri, you may just have had good luck when running the game right after changing packages - in my experience the jitter/cut out of sound is an intermittent problem that only occurs some of the time.

[Neil Wilson (neil-aldur)]

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.

--
Neil Wilson

[Andris Sprūds (aspruds)]

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.

[Phil Moorhouse (phil-moorhouse)]

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.

[Phil Moorhouse (phil-moorhouse)]

Also, as mentioned it seems to be more prevalent when the audio stops and starts, either between songs or after being paused.

[macstevejb (macstevejb)]

Installed wine 1.2 from Neil's PPA and running Spotify, I can confirm that my sound problems have been resolved with pulseaudio driver selected in the wine config settings. Using Karmic Beta.

[Andris Sprūds (aspruds)]

Winepulse version from Neil's PPA seems to work well. Have not had any problems since I installed them.

[Ernst (ernst-blaauw)]

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?

[Gustav Nilson (gustavnilsson)]

Wonderful winepulse version from Neil's PPA! Now Spotify sounds much better!

[Ernst (ernst-blaauw)]

Currently, I get (normal) audio from wine by setting the audio driver to ALSA and 'full' instead of 'emulation' in the audio tab of winecfg.

[Dundun Orrestad (dundun-f)]

I agree with Gustav, wonderful! Tried all available fixes and workarounds to make Spotify work under 9.10, with no luck. Neil's Wine and pulse audio works flawlessly.

[Robert Shaw (rshaw3)]

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?

[Daniel T Chen (crimsun)]

You'd need to disable autospawn and enable verbose logging:

echo autospawn = no|tee -a ~/.pulse/client.conf

killall pulseaudio

pulseaudio -vvvv >~/pulseaudio.log 2>&1

On Oct 22, 2009 11:16 AM, "Robert Shaw" <email address hidden> wrote:

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?

-- Occasional sound drops in Wine via PulseAudio
https://bugs.launchpad.net/bugs/371897 You receiv...

[Christopher Armstrong (radix)]

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

[Neil Wilson (neil-aldur)]

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

[Ernst (ernst-blaauw)]

I have the same symptoms as Robert and Christopher, and I'm running:$
apt-cache policy wine1.2
wine1.2:
  Installed: 1.1.31-0ubuntu1+winepulse0.32~ppa1
  Candidate: 1.1.31-0ubuntu1+winepulse0.32~ppa1
  Version table:
 *** 1.1.31-0ubuntu1+winepulse0.32~ppa1 0
        500 http://ppa.launchpad.net karmic/main Packages
        100 /var/lib/dpkg/status
     1.1.31-0ubuntu1 0
        500 http://nl.archive.ubuntu.com karmic/universe Packages

On Thu, Oct 22, 2009 at 19:50, Neil Wilson <email address hidden> wrote:

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

[Christopher Armstrong (radix)]

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.

[Christopher Armstrong (radix)]

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.

Back to Neil's PPA... configured to use the pulse backend...

and it's working again. I guess I'll have to pin it for now.

[Phoenix-g (phoenix-g)]

Is there any progress on pulseaudio support?

[Maurizio Stefano Oliveri (6tsukiyami9)]

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

[Austin English (austinenglish)]

(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

The patch was last sent before the code freeze, back in May:
http://www.winehq.org/pipermail/wine-patches/2013-May/124406.html

it hasn't been sent since the code freeze ended.

[Maurizio Stefano Oliveri (6tsukiyami9)]

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)?

I'd also like to add that using the wine-multimedia git repository (the one with the pulseaudio driver) I'm not experiencing this gstreamer related bug: http://bugs.winehq.org/show_bug.cgi?id=30557

[Scott Ritchie (scottritchie)]

I'm not sure this should be a pulseaudio bug in launchpad anymore.

[Ben Shadwick (benshadwick)]

I guess if it's been satisfactorily addressed on the Wine side, then it should be okay.

[kotoroshinoto (mgooch)]

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.

[Dimesio (dimesio)]

(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?

[kotoroshinoto (mgooch)]

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

[Maurizio Stefano Oliveri (6tsukiyami9)]

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

[Ben Shadwick (benshadwick)]

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.

[Sorceror (shacklein)]

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

[Maurizio Stefano Oliveri (6tsukiyami9)]

(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?

[Austin English (austinenglish)]

Bugzilla is not for discussion, as has been pointed out, e.g., http://bugs.winehq.org/show_bug.cgi?id=10495#c251.

Please take the discussion somewhere else.

[Maurizio Stefano Oliveri (6tsukiyami9)]

(In reply to Austin English from comment #406)
> Bugzilla is not for discussion, as has been pointed out, e.g.,
> http://bugs.winehq.org/show_bug.cgi?id=10495#c251.
>
> Please take the discussion somewhere else.

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.

[Dimesio (dimesio)]

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.

[Felipe Contreras (felipec)]

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

[[e-mail] (ruedii)]

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.

[Andrew Eikum (aeikum)]

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.

Please post your test results here, or email me directly if you prefer.

[Susan Cragin (susancragin)]

> Please post your test results here, or email me directly if you prefer.

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.

[Susan Cragin (susancragin)]

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.

[Maurizio Stefano Oliveri (6tsukiyami9)]

(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?

[Susan Cragin (susancragin)]

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

Susan

[Susan Cragin (susancragin)]

> I set pulseaudio autospawn to No, killed pulseaudio, and started Natspeak
> wine. Natspeak worked great.

Actually, this is wrong. I hadn't uncommented the autospawn setting and pulseaudio was still running. Whoops.

[Dawid Gan (deveee)]

Wine developers on all places seem to say that winepulse is not needed and that alsa plugin works fine. No, it doesn't work properly. I have a problem with crackling sounds since I started to use pulseaudio (since Ubuntu 13.04 to 14.10 currently). And it's not a problem with distributions modifications as you suggest in this note: https://forum.winehq.org/viewtopic.php?f=8&t=16895. Exactly the same I have with non-modified manually compiled version. These modifications only show that problem exists.

Any other native pulseaudio application in my system doesn't have such issues. Also winepulse works properly.

I "fixed" my problem with crackling sounds by using following environment variable:
PULSE_LATENCY_MSEC=60
I don't know if standard latency is higher or not, but it works fine for me. And it doesn't affect whole system, but only single application.

[Cheako+winehq (cheako+winehq)]

From what I understand the main blocking reason for this commit is because the following works as a solution:

/etc/init.d/pulseaudio stop

-- Facepalm --

[Maurizio Stefano Oliveri (6tsukiyami9)]

We should all acknowledge that they're not gonna add pulseaudio support, due to reasons that lack any technical relevance (whatever you say, "use a plugin for alsa" makes any argument used along a *joke*). After all, this project belongs to AJ & his crew, so we really can't do anything to force a change or a feature request.

The best thing to do about it right now is to either use Maarten Lankhorst's git repository and build wine ourselves ( http://repo.or.cz/w/wine/multimedia.git ) or, for ubuntu/debian users to use this repository: https://launchpad.net/~ubuntu-wine/+archive/ubuntu/ppa .

It's sad, but it's been like this since 2007, and the best answer so far has been "try this patch to our alsa driver!"... I doubt anyone actually checks this bug report anymore (if any dev ever did), we'll just have to live with it, and be grateful that the Wine project is actually here, or we wouldn't be able to run Windows programs on Linux at all. Audio-wise the project is stuck in 2007 but and everyone that have any relevance with its governance is fine like this, so... Just use patches to get PA support, updating this bug report has been quite useless for 5 years now.

[[e-mail] (ruedii)]

I agree with the sentiment that maybe the wine developers just need to make the wine alsa output play nicer with pulseaudio, and probably modernize it a bit.

Another option is to use a multimedia abstraction library for this and some other items (raster/vector rendering, OpenGL instance creation, input etc) to help better handle all OS-specific issues. SDL would work nicely for this.

If an abstraction layer was wanted solely for use in audio, OpenAL would probably work nicely.

[Stefaj (stefaj)]

Chris Robinson, the author of the main OpenAL implementation on Linux (openal-soft) has tried to handle Wine's audio purely with OpenAL, but ran into problems. I don't remember the details, but there are some things OpenAL does not handle, like MIDI.

Please, if you have problems with PulseAudio, post the following info: Which Application are you trying to run, which sound device do you use (lspci or lsusb info), which PulseAudio version you use and the module name of the sound driver (e.g. snd-hda-intel.ko, snd-usb-audio.ko).

PA is working fine for me with all Wine apps, *except* on my snd-usb-audio.ko-driven USB dongle. For the USB dongle setting default-fragments = 4 and default-fragment-size-msec in /etc/pulse/daemon.conf fixed the problem. Andrew Eikum says that PA is trying to read 50ms from a 10ms buffer Wine provides (Not sure if I remember the numbers right), which naturally causes trouble.

[Cheako+winehq (cheako+winehq)]

SDL would work great, if wine was an emulator.

I can't see how adding in another layer of abstraction would help. From what I understand the SDL portion(backend selection) is implemented as built-in dlls.

Switching to SDL now causes problems with current configuration. This bug is open because a single backend for every app was never going to work.

Currently I've apps that need the PA driver and apps that need alsa to PA and apps that need alsa with no PA. It's true that all apps would likely work without PA, but as my system uses SPDIF i'm dependent on PA for software mixing.... and for the last time dmix and SPDIF are mutually exclusive as dmix requires parts of a DAC that exist only on the other end of the optical cable(if they exist at all).

No one backend is closer to being a good fit than any of the others. For all use cases having a good selection of backends is essential.

If you can time travel a working wine version from the future that would be nice, but until you can offer a "does work in all cases", wine is broken for some cases and won't be fixed... By patching the alsa backend to support PA.

Though a patch for a native PA backend does exist and this solution is available for more than a few years, instead of a few years from now.

[Dawid Gan (deveee)]

@Stefan
Crackling sounds occurs in every game which I played under Wine. Of course not always. For example: Sims 3, Luxor 1, 2, 3, 4, Croc 2, Fifa 12, Bejeweled 2. I noticed that actually sounds are still playing, but much faster than they should.

lspci says:
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)

Current packages versions:
pulseaudio 4.0
libasound2 1.0.28

Pulseaudio works for me with PULSE_LATENCY_MSEC=60 environment variable (I hope it's not a case). But never worked properly with default settings.

[Andrew Eikum (aeikum)]

(In reply to Deve from comment #423)
> @Stefan
> Crackling sounds occurs in every game which I played under Wine. Of course
> not always. For example: Sims 3, Luxor 1, 2, 3, 4, Croc 2, Fifa 12,
> Bejeweled 2. I noticed that actually sounds are still playing, but much
> faster than they should.
>
> lspci says:
> 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family
> High Definition Audio Controller (rev 04)
>
> Current packages versions:
> pulseaudio 4.0
> libasound2 1.0.28
>
> Pulseaudio works for me with PULSE_LATENCY_MSEC=60 environment variable (I
> hope it's not a case). But never worked properly with default settings.

Have you tried the patch I uploaded here back in May?

https://bugs.winehq.org/attachment.cgi?id=48661

I believe it vastly improves audio for PulseAudio users that are not using USB devices. I'd be interested to know if it helps you.

I'm becoming convinced that the PA-ALSA plugin can't provide reliable playback when USB devices are used. There was a discussion about this back in October:

http://lists.freedesktop.org/archives/pulseaudio-discuss/2014-October/022043.html

The ALSA API just doesn't provide a way to update client applications that the buffer metrics have changed after the device was created. This occurs for USB devices with PulseAudio. USB devices used to work in PA, but their latency configuration was updated around PA 4 or 5, which caused bugs for applications that can't handle high latencies, like many Windows applications running in Wine:

https://bugs.freedesktop.org/show_bug.cgi?id=66962

I plan to send the above patch to improve winealsa. I had been hoping to include a fix for USB-over-PA devices in the patch, which is why I haven't sent it yet. As I showed above, I'm not convinced it's possible to support this. The limiting factor is my time, I'm afraid. I need to test the patch, over lots of test cases (a dozen applications on each of non-USB, USB, PA non-USB, PA USB) and come to a decision on USB-over-Pulse.

[Maurizio Stefano Oliveri (6tsukiyami9)]

I guess most people know it by now, but I've finally had some time to try it out myself, so...

https://github.com/wine-compholio/wine-staging/wiki/Installation

Wonder how long it'll take for pulse related patches to get into upstream Wine (if they ever will), but so far this is the closest thing to a solution to our common problem. Quite sad if you ask me, but that's the world we live in ^^

[Chris Y. (emailofchris)]

I use a Behringer Xenyx302 USB sound mixer as my sound device, which works great with Pulseaudio but not with Wine. I mainly use wine-staging now thanks to the built-in PulseAudio driver. I'd love to see this adopted into Wine.

[Austin English (austinenglish)]

Maarten's initial patches (+ fixes by Andrew et al) are now in Wine:
https://source.winehq.org/git/wine.git/commitdiff/3fe0c08992db43155677f02ec0cca423b9278f89
https://source.winehq.org/git/wine.git/commitdiff/84d1de17ebe381772880d3785af25a869205ea15
https://source.winehq.org/git/wine.git/commitdiff/6f632affa75ae27ce6a40f0c2f0cc25254400395
https://source.winehq.org/git/wine.git/commitdiff/d7eb9090b73b35b16c4bb281f13fea1ac615be70
https://source.winehq.org/git/wine.git/commitdiff/8f443077416fd820375b1bc0d1276286d23348fc

remaining issues should be in new bug reports

[Sebastian Lackner (slackner)]

Closing this bug was probably a bit rushed, to quote Andrews comment on wine-devel:

"""After those five, there are three more patches to implement missing
critical interfaces (volume, session, and marshalling)."""

I would assume the current state is not fully functional enough to actually use it.

[Dawid Gan (deveee)]

Thanks a lot!

[Sorceror (shacklein)]

(In reply to Sebastian Lackner from comment #428)
> Closing this bug was probably a bit rushed, to quote Andrews comment on
> wine-devel:
>
> """After those five, there are three more patches to implement missing
> critical interfaces (volume, session, and marshalling)."""
>
> I would assume the current state is not fully functional enough to actually
> use it.

Should wait to see if those additional patches are added. If they're not, then create new bugs for implementing those interfaces. This thread is already insanely long, and the primary issue (proper PulseAudio support) is now fixed upstream.

[Alexandre Julliard (julliard)]

Closing bugs fixed in 1.7.55.

[Gilboa Davara (gilboad)]

Many thanks.