Ubuntu

Occasional sound drops in Wine via PulseAudio

Reported by Neil Wilson on 2009-05-04
226
This bug affects 48 people
Affects Status Importance Assigned to Milestone
Wine
Confirmed
Wishlist
pulseaudio (Ubuntu)
Undecided
Unassigned
wine (Ubuntu)
Low
Maarten Lankhorst

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.

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) wrote :

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

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

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

--
Neil Wilson

Steve Dodier-Lazaro (sidi) wrote :

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) wrote :

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

summary: - Occasional sound drops in Wine
+ Occasional sound drops in Wine via PulseAudio
Steve Dodier-Lazaro (sidi) wrote :

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) wrote :

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.

Changed in wine (Ubuntu):
status: Incomplete → New
Changed in wine (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in wine:
status: Unknown → Confirmed
tomten (fredrik-corneliusson) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

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) wrote :

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) wrote :

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

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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.

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

macstevejb (macstevejb) wrote :

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) wrote :

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

Ernst (ernst-blaauw) wrote :

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) wrote :

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

Ernst (ernst-blaauw) wrote :

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.

1 comments hidden view all 517 comments
Dundun Orrestad (dundun-f) wrote :

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

Daniel T Chen (crimsun) wrote :

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) wrote :

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

Ernst (ernst-blaauw) wrote :

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) wrote :

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) wrote :

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.

Changed in pulseaudio (Ubuntu):
status: New → Fix Released
Changed in wine:
importance: Unknown → Wishlist
Jack Leigh (leighman) on 2010-10-29
Changed in pulseaudio (Ubuntu):
status: Fix Released → New
Changed in pulseaudio (Ubuntu):
status: New → Confirmed
437 comments hidden view all 517 comments

please just merge Maarten's patch to master. users want to play skyrim with pulseaudio!

I'd like to report as well that Maarten's patch used by Ubuntu Wine Team on launchpad actually fixes every sound issue I was experiencing, and it actually allows me not to worry about restarting pulse and wine every 30 minutes or so... And I'm somehow getting better overall performances too

I confirm. "Ubuntu Wine Team" deb package works great.

Confirmed. Dota2 stopped crashing after installing wine 1.5.5-0ubuntu1~ppa1~precise1+pulse17 from the "Ubuntu Wine Team"'s PPA, instead of using wine1.4. This is actually awesome!

In , Lt73 (lt73) wrote :

(In reply to comment #364)
> I confirm. "Ubuntu Wine Team" deb package works great.

Agreed. This works great on Gentoo with wine-1.5.6. I was able to have wine Rhythmbox and Mumbler all go through wine and mix properly.

winedevs, why was this patch rejected?

(In reply to comment #362)

Andrew Aeikum has been working on getting Maarten's patch merged. Latest version is here:

http://source.winehq.org/patches/data/87234

(In reply to comment #367)
> (In reply to comment #362)
>
> Andrew Aeikum has been working on getting Maarten's patch merged. Latest
> version is here:
>
> http://source.winehq.org/patches/data/87234

thanks! this works perfect. Do you know will wine team merge this patch into master in future?

Probably, since they have Andrew working on it, but there's no way to tell when it will be ready to go in.

Apparently http://source.winehq.org/patches/data/87234 is now considered to be obsolete; http://repo.or.cz/w/wine/multimedia.git should be used instead.

> Date: Sat, 13 Oct 2012 00:46:08 +0200
> Subject: update wine pulse patch please
> From: Maarten Lankhorst <email address hidden>
> To: <email address hidden>
>
> I saw your ebuild still making mention of aeikum's ancient pulse patch, written
> in response to my original, unupdated patch, it's not the correct one and lacks
> proper pulseaudio support (technical problems).
>
> Please consider pulling http://repo.or.cz/w/wine/multimedia.git and leaving out
> all commits after 'valgrind prevent crash hack', the rtkit ones specify audio
> thread priority better, dsound has some love to make it work better against
> pulse, and winmm is changed to fall back to alsa midi if pulseaudio is used.
>
> The git tree usually gets updated on the same day or the day after a release,
> but only if the patch series fails to apply. :-)

(In reply to comment #370)
> Apparently http://source.winehq.org/patches/data/87234 is now considered to be
> obsolete; http://repo.or.cz/w/wine/multimedia.git should be used instead.
>
Well, neither of those will result in a build of Wine that can be supported by us. That's a distribution's own responsibility of course, up to a point, but please do take that into account when applying custom patches. When patches aren't in upstream Wine there's usually a good reason, certainly beyond what people sometimes perceive as "Wine hates PA".

As for the mail you received, Maarten Lankhorst has made it fairly clear that he doesn't agree with the way the Wine development process works. That's his good right, but at this point he isn't really associated with the Wine project anymore, at the very least not in the role of audio maintainer. In the mail you received he's speaking as the author of http://repo.or.cz/w/wine/multimedia.git, not on behalf of the Wine project.

(In reply to comment #371)
> Well, neither of those will result in a build of Wine that can be supported by
> us. That's a distribution's own responsibility of course, up to a point, but
> please do take that into account when applying custom patches.

Fair enough - but source-based distributions have some flexibility here because they can give users a choice about what goes into the build. Gentoo's wine package, for example, enables the unofficial pulseaudio support for those users who have the pulseaudio USE flag enabled.

So, what is the progress on this from the official Wine side? Is it still being worked on, as mentioned in Comment 369?

I've tried to stay clear of political discussions, sigh..

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?

I'm willing to rework the dsound patches to a cleaner state, and resend both them and winepulse though if wine devs are finally willing to review it instead of letting it rot in the patch list until it falls off. The main reason it's out of tree is that wine never chose to accept it in the first place.

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

(In reply to comment #373)
> So, what is the progress on this from the official Wine side? Is it still being
> worked on, as mentioned in Comment 369?
Afaik Andrew is still working on this, but he has other work to take care of as well.

(In reply to comment #374)
> I've tried to stay clear of political discussions, sigh..
I'm not sure why you're trying to start one here then.

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

> 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 #375)
Not to go into politics, but code freeze or not this comment is still inappropriate, and sounds more like "Not a chance in hell this will ever see the light of day" than "What are you thinking, submitting this now".

Regardless of the official position of Wine as a project, there are Wine developers who are simply against pulse and this is reflected in the attitude displayed towards the efforts put into the winepulse driver.

Take it like this: If pulse frustrates you, think how frustrating it must be to write a driver for it.

Many people who tried Maarten's winepulse can testify how well it works. Even if there'd been some misunderstandings in the past, he put much effort in his work, in an area where upstream wine's progress was non existent. Face it, "supporting" pulse via alsa-plugins is just not viable, it didn't work well in the past and it surely isn't working well now, winepulse is surely a better, fully functional alternative. Also, "use alsa instead of pulse" is just a way to avoid the issue which has been carried on for too long ( look when this all started: "2007-11-18 12:47:22 CST" ), most distros now ship with pulseaudio and sometimes getting alsa to work instead of it can be too difficult for a newbie user ( asound.conf, anyone? ).
Many things have been said in the past, but now wine 1.4 is out, there is no code freeze... Can't you give eachother another chance and try to work together, now that there aren't any real reasons not to review winepulse? Stubborness, on any side, doesn't get wine good pulse support...

IMO, given the facts that

- a huge part of wine's users intend to run windows applications comprising audio output with it (particularly games)

and

- PA-focused distros like Ubuntu and its derivates have an enormous market share, attracting an increasing number of users to the linux world,

supporting PA should definitely not be considered a matter of personal preferences or taste (Thereby I do not assume or imply that anybody does so).

Granted, PA is not the best sound server out there and the trouble it brings probably even outruns the benefits. Nevertheless it is being incorporated into a wide spectrum of distros, i.e. employed by a vast user base... and AFAIK there are no indications that this might change in the near future. So this is not just a temporary fashion but rather a part of the contemporary reality of wine use cases.

If I understand wine's goals correctly, they incude striving for the best possible out-of-the-box experience for most of its users. Given that this is the case, this goal is endangered by not adding PA support at least in the long term. Though, once more, I do not imply anyone blocking efforts in this context -- this is purely hypothetical.

So, as long as it does not break anything else, adding a *clean* and *structured* implementation of a PA driver to wine does no harm -- will it? However and doublessly, established wine development paradigms MUST be maintained in doing so. Anything else would be fatal in the context of such a huge project, in which the methods and practices of the leading devs have indeed turned out to be very successful.

But this is just my personal opinion... I hope it's helpful to anybody, providing food for thought.

At least I'm quite sure about this: There are many users out there thinking something like "my audio is not working properly when running my windows apps with wine -> linux is crap"... They'd be glad if you guys could somehow reconcile. :)

Or, to put it a little more direct and to pick up what Maurizio said above, stubbornness -- on any side -- has never gotten anyone anywhere. Especially not among apparently able developers.

Is there any chance of publishing audio driver interface? Then Maarten Lankhorst can work independently of the Wine team.

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

See above.

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

Download full text (6.3 KiB)

Oh fine, have the whole story as far as I know it.

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

Read more...

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.

Yet another user chiming in here (how many will it take?):

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.

This is not a user forum. User comments in here aren't especially helpful.

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.

Is that road possible? Is there help needed?

@comment #283

We shall see about that willingness..

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.

tom (fastumzug) wrote :

Set

default-fragments = 8
default-fragment-size-msec = 5

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?

Patches have been sent, people posted reviews/comments. E.g.,:
http://www.winehq.org/pipermail/wine-devel/2012-October/097482.html
http://www.winehq.org/pipermail/wine-devel/2012-October/097485.html
http://www.winehq.org/pipermail/wine-devel/2012-October/097486.html
http://www.winehq.org/pipermail/wine-devel/2012-October/097487.html
http://www.winehq.org/pipermail/wine-devel/2012-October/097602.html
etc. (check http://www.winehq.org/pipermail/wine-devel/2012-October/ and look for dsound).

One of the patches was resent yesterday:
http://www.winehq.org/pipermail/wine-patches/2012-November/119914.html

> 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

Is there any progress on pulseaudio support?

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

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

Changed in wine (Ubuntu):
assignee: nobody → Maarten Lankhorst (mlankhorst)
status: Triaged → Fix Released

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) wrote :

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

Changed in pulseaudio (Ubuntu):
status: Confirmed → Invalid
Ben Shadwick (benshadwick) wrote :

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

Displaying first 40 and last 40 comments. View all 517 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.