[Bug 10495] Wine should support PulseAudio

[wine-bugs at winehq.org]

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

--- Comment #382 from Maarten Lankhorst <m.b.lankhorst at gmail.com> 2012-10-13 13:29:25 CDT ---
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.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.