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 when pulseaudio sends a callback, the position gets updated. The end result was a driver that matched native behavior exactly, and could be claimed to be the first driver in wine that actually passed all tests. I even found a bug in the tests themselves, see "mmdevapi: Fix broken test (required to pass all tests with winepulse)" However, somewhere during the rework it turns out Andrew Eikum was already working on his own driver based on mine, I did give it a look at the time, and found that it would be mostly identical in behavior to winealsa with pulse emulation, so I chose to put in a bit extra effort to make sure mine behaved exactly as a windows audio driver instead. This was the version I sent for review, and I addressed all issues as they were raised. Until I submitted the final version to winepulse, I was working on splitting things up too, in case that was the reason the patch was rejected. But the patch dropped off the list in the 'new' state, eg not even looked at. Now comes the part I probably don't remember properly any more, so please take the next paragraph of mostly lies. After being 2 weeks in the 'new' state I asked julliard why the patch was not even looked at. It was because I was unreliable as maintainer, and have done things in the past like the gstreamer stuff where I was too optimistic about being ready, and what keeps me from dropping support for it and working on something else altogether? I can't remember this part exactly, he might have said some more, but this is what the real reason the winepulse rejected really is, that I wouldn't be the one maintaining it, or following up on feedback. (This is the part I probably do remember correctly) He also suggested that I worked in other areas of wine again, so I build up some reputation again. But I didn't have the time, so we ended up at a point where I couldn't get the patch in. I resigned my duties, not in anger at anyone but sadness at the patch acceptance process. I still don't blame anyone about these circumstances but myself. However despite that I didn't want to leave users in the cold, so I've done the next best thing since. Wine as a project can choose to leave a feature out, but I still wanted to support the users. So instead I started integrating the patches in ubuntu-wine, fixing issues as they came along, and encouraging other distributions to take up on the winepulse patches. (BTW thanks everyone who reported issues to me instead of trying to be satisfied with a workaround or inferior sound, you rock!!) I'm now at a point where for the past month + some weeks there has been no sound specific issue has been reported. This is quite scary for me, either that means there isn't any, or people aren't coming to me. I'm hoping the former, since I've had nothing but positive feedback to users. However, I still maintain my original position. I have *NOTHING* against anyone in the wine developer project, and I genuinely want to help people out who are having troubles with wine. This is why I kept working on multimedia.git in the first place. Hopefully I've proven julliard wrong (I never thought I'd say that :P), and I'm willing to resubmit the whole patch series of multimedia.git. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to pulseaudio in Ubuntu. https://bugs.launchpad.net/bugs/371897 Title: Occasional sound drops in Wine via PulseAudio Status in Wine: Confirmed Status in “pulseaudio” package in Ubuntu: Confirmed Status in “wine” package in Ubuntu: Triaged 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 To manage notifications about this bug go to: https://bugs.launchpad.net/wine/+bug/371897/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
