Fate of PulseAudio in WINE

Arthur Taylor theycallhimart at gmail.com
Tue Jun 16 22:24:01 CDT 2009


On Tue, Jun 16, 2009 at 3:24 PM, Michael Stefaniuc<mstefani at redhat.com> wrote:
> Arthur Taylor wrote:
>>
>> Recent activity in http://bugs.winehq.org/show_bug.cgi?id=10495 has
>> caused some issues. This is also a response to
>> http://www.winehq.org/pipermail/wine-devel/2009-April/074666.html
>
> [...]
>>
>> It is true that currently whitespace is an issue with the patches in
>> the bug report. I will work to resolve this. The file was (supposed to
>> be) indented using 4 spaces as this was the convention in all the
>> other audio backends.
>
> 4 spaces is the preferred indentation in Wine.
>
>> Frankly, calling the code a search and replace from ALSA to PULSE is
>
> I said "Copy of an old version of winealsa.drv hacked up for PulseAudio" and
> that is correct.
>
>> insulting. If this is true then it is therefore true that winealsa was
>> a search and replace from OSS to ALSA. Almost all the wine audio
>
> Yes, winealsa is a copy of wineoss.drv hacked up for ALSA. wineoss.drv using
> the OSS compatibility interface in ALSA was for many years the better driver
> than winealsa.drv using native ALSA.
>
>> backends share a common ancestor. The latest patch does not contain
>
> Which is very very unfortunate. Everybody has copied the same old cruft and
> carried it over.
>
>> comment out code. There has been no *useful assistance* from wine
>> developers (re "No Fucking Way"). As for which parts of the code
>
> Huh? My email you referenced *IS* "useful assistance".
>
>> aren't wine-64 ready, could you please expand?
>
> Back then when I reviewed the code it was based on winealsa.drv that
> predated this patch:
>
> commit ec1b28edb0c259f5a0c639edee4ed42b9cac9d1a
> Author: Alexandre Julliard <julliard at winehq.org>
> Date:   Fri Jan 9 17:46:46 2009 +0100
>
>    include: Fix a number of mmsystem.h structure for Win64.
>
> There are a few other patches that were commited afterward to winealsa.drv.
> Some of them might be relevant to the PA driver too.
> "git log dlls/winealsa.drv/" will show those.
>
> "- The driver provides the old DSound interface from DirectX 5. The
> header include aka dsdriver.h doesn't exist on a modern Windows version."
> That is also 64bit relevant as at the moment some DSound pointers are passed
> over a 32bit integers (DWORD afair). Those cannot be expanded to DWORD_PTR
> as dsdriver.h doesn't exist anymore to validate that the change is "what
> Windows does". So the whole DSound in Wine needs to be moved to the right
> "modern Windows" driver interface ...
>
>> A detailed, constructive response with a clear vision for where the
>> future of audio in wine lies would be appreciated.
>
> I have no clue about audio nor about how sound works on a modern Windows.
> But what I know is that winmm has Win16 ancestry and was hacked up in Wine
> for Win32. I really really doubt that a modern Windows still uses the same
> stuff for the low level audio stuff; the DSound from DirectX 5 is a prime
> example.
>
> The "vision" is easy and clear. Move audio in Wine to use the same
> subsytems/APIs like a modern Windows does.
>
> bye
>        michael
>

I concur. It to me now that the inclusion of a new backend is a
periphery matter. The current system of audio in wine appears to be
due for an change. I am not familiar with the new windows audio api's,
but perhaps if they are the most powerful or consistent it would make
sense to implement the current audio apis (playsound, waveout/in,
dsound) on top of that rather than implement them in parallel, or
worse the new API on top of the old APIs.

I would still continue to work and maintain the pulseaudio winmm
patches externally, but I will not try for inclusion.

To a comment someone made comparing the efforts to the DIB engine, I
am flattered, but I believe that this is not near the same amount of
work.

As a curious aside, would it be possible write an OpenAl dll that
backended to the native OpenAl library similarly to the way OpenGl is
handled? Would this not mean that if the native platform supported
hardware accelerated OpenAl that the benefits would be reaped by
OpenAl using windows programs, and further more if such was possible,
would it not be possible to implement DSound on top of OpenAl in wine
the same way Alchemy can in windows?

Thanks

-- 
Arthur Taylor
art at ified.ca
theycallhimart at gmail.com



More information about the wine-devel mailing list