Fate of PulseAudio in WINE
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 First the background. WinePulse has been an attempt to write a winmm backend for pulseaudio for wine. Currently the primary audio system used by wine is through winmm.dll which sends messages to a backend which basically represents the MS waveOut and waveIn APIs. WaveOut works through wavehdrs, a single-linked list structure which contains a data field pointing at a buffer. Applications feed wavehdrs via waveOutWrite and receive a message when they have finished being played. wavehdrs can be formed into loops using flags. This is all simple enough except for how variable it is. Applications usually allocate a set size of wavehdrs and then use them circularly. Applications usually use when a wavehdr is returned for timing purposes rather than waveOutGetPosition. The number of wavehdrs and their sizes is entirely up to the application. There are two common problems with audio drivers implementing this system. The first is drivers which return a wavehdr as soon as it is written to output (waveesd.dr for example) as it will cause timing issues for applications when large batches of wavehdrs are returned at once. The second problem is when a windows application makes a smaller buffer of wavehdrs than the backend provides. In this case wavehdrs are not returned because they have not been played, and no more data can be written to fill the buffer because all the wavehdrs are waiting to be returned from the playback that is stalled. This can happen with alsa on top of plugins. If the buffered wavehdrs and playback buffer are very close in size sometimes the audio stutters by, oscillating to and from underrun and playback. Winepulse attempts to overcome these problems. It returns wavehdrs accurately and avoids stalls by modifying the pulseaudio server buffer size. In tests it works consistently. Most of the people I've had contact with have been positive toward development of such a backend. That said, the response from wine developers has been overwhelmingly negative. I can understand the desire for only clean and maintainable code to be considered for submissions. However, often it appears that the rejection is wholly philosophical rather than logical. Continual reports of problems are always contributed to silly users who are not using ALSA on top of direct hardware. I do not dislike either ALSA nor winealsa.drv, but I do reject this skepticism toward a world of Linux audio beyond SB-16 style direct hardware. The arguments that PulseAudio adds latency or is not suitable for professional audio are not relevant to the issue of whether or not a pulseaudio backend for wine should be added. The _addition_ of said backend _enables_ audio in wine for those who _choose_ to use pulseaudio. I can't imagine stopping pulseaudio just so I can listen to music through foobar2000, as that would stop all my voice chats, notification sounds, and other native audio, etc. For those whom pulseaudio is not appropriate, the other backends would still exist and pulseaudio can either be disabled temporarily via pasuspender, not started or not installed. That said, latency in pulseaudio is managed and through the winepulse patch exposed to the windows application. The daemon is usually run with realtime priority and will use data buffers if the requesting application locks temporarily, allowing less worry with recording. The method of audio playback and capture through waveOut and waveIn are quite broken. Even if winealsa uses the safe ALSA api subset it means that the poor and varied behaviours are translated to poor and varied alsa calls (DSound HEL is an exception here.) The winepulse patch attempts to overcome these issues by buffering sanely while trying to keep applications happy in a _consistant_ way. 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. Frankly, calling the code a search and replace from ALSA to PULSE is 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 backends share a common ancestor. The latest patch does not contain comment out code. There has been no *useful assistance* from wine developers (re No Fucking Way). As for which parts of the code aren't wine-64 ready, could you please expand? A detailed, constructive response with a clear vision for where the future of audio in wine lies would be appreciated. Thanks -- Arthur Taylor a...@ified.ca theycallhim...@gmail.com
Re: Fate of PulseAudio in WINE
On Tue, Jun 16, 2009 at 3:24 PM, Michael Stefaniucmstef...@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 julli...@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 a...@ified.ca theycallhim...@gmail.com
Re: Wine PulseAudio Driver
Where are the patches? Should they have been attached here? Sorry, I guess I should have specified. The patches are in the bugzilla entry http://bugs.winehq.org/show_bug.cgi?id=10495 . The patches are too big for attaching. -- Arthur Taylor [EMAIL PROTECTED]
Re: Wine PulseAudio Driver
Hello. I have updated the testing pulseaudio waveout patch for http://bugs.winehq.org/show_bug.cgi?id=10495 The patch has been split in two. The first adds a stub driver that just creates waveout devices based upon pulseaudio sinks and adds checks for pulseaudio to configure.ac. The second patch adds the actual waveout functionality. The patch now detects pulseaudio version prior to 0.9.11 (aka most ubuntu versions) and can build against them. I hope to receive your feedback on this. Thanks - Art
Re: Wine PulseAudio Driver
Umm, disregard all of this... sorry for spam
To wine developers: would it be useful to review dlls/winmm? Currently
all mm-drivers (aux, mid, mod, wid, wod) functions are called using
MDRV_Message calls. The arguments of a MDRV_Message are the device id
(an array index), the message identifier, dwUser as the driver instance,
and two parameters that depend upon the message. The driver instance
DWORD seems useless to me, and it's value, while consistent, looks
uninitialized (on my system is either 57 if I enable tracing, or random
crazy large for a pointer if not.)
My problem is that WaveIn / WaveOut devices are supposed to be able to
support multiple streams if the hardware allows it, however it is
impossible to support this currently as all MDRV_Message gives us is the
device id the message is for (the only arguments to a WODM_PAUSE is the
device id for instance.) This makes multiple streams impossible and
therefor waveout drivers only support one stream per device. wineesd.drv
gets around this by staticly making 10 waveout and 10 wavein devices,
all effectively the same.
If MDRV_Message were to pass in dwUser the device opening instance
handle which winmm creates and apps use for the wave{out,in}* calls it
would be possible to support multiple streams per device, and devices
could represent hardware 1:1 like they are supposed to. So my questions
are this: would changing the value of dwUser to the device instance
handle be a good idea, and do any current mm-drivers depend upon dwUser
being the seemingly uninitialized driver instance value?
Re: Wine PulseAudio Driver
I have put a newer patch in bugzilla: http://bugs.winehq.org/attachment.cgi?id=16412action=edit Currently I am looking for any feedback at all. Should I send a message to wine-patches as well? 2. We ought to be able to use PulseAudio's ALSA emulation. If that doesn't work, then either our ALSA driver should be fixed, or PulseAudio's ALSA interface should be fixed. IMHO this is a situation were it makes more sense to use pulse's native API over going through ALSA's, as we aren't just trying to join ALSA-pulse, we are trying to join WaveOut-ALSA-pulse (or even dsound on top of waveout.) Currently I can match the alsa driver's perceptive quality (buzz word) on my system using this code, dsound and all. By far beats the current ALSA-pulse or ESD solutions. Thanks - Art
Re: Wine PulseAudio Driver
Hi Art, Currently I am looking for any feedback at all. I believe you've already gotten some: split up your patches so that we can read them a little more easily. If you send a large patch as a new contributor, it's very unlikely to get committed. Humm, I can see splitting the changes to configure.ac and Makefile.in, but as for splitting the rest of it, should I split it per-file? Is there some other criterion I can use to evaluate it? Doesn't steal audio, doesn't stutter as much, ??? I'm looking for instances where the patch falls on its face so I can fix them (where falling on it's face is defined as) - Crashing / stalling an app - Crashing the PA server - Continual stuttering or no audio. I'm also looking for comments on the code. Is it sane, are the variable names okay? Are there functions I should divide / join? Thanks - Art
Re: Wine PulseAudio Driver
On Sat, 2008-09-27 at 11:37 -0700, Juan Lang wrote: Hi Arthur, I have written a waveout/in driver for wine to use pulseaudio which is in bugzilla. I would appreciate feedback on it, as I have received little thus far. Great. In general, emailing the patch here will get more feedback than posting it to bugzilla. Woots! I would appreciate it also if people took care to ensure that their instance of pulseaudio is properly setup before trying. How do we do that, if we're so inclined? Firstly, ensure pulseaudio is running, and works (paplay sound file.) Secondly, ensure the pulseaudio daemon has realtime privileges as it stops playback stutter. Thirdly check to see that your default sample spec and the sample spec of your sinks are sane. Either `paman` or using `pacmd`'s CLI will tell you. Fourthly, pulseaudio prefers dirrect hw access. You can run PA through dmix, but it gets silly. The glitch-free stuff in 0.9.11 for ALSA is pretty sweet. Dynamic hw buffers... Also, in the patch, configure checks for pulseaudio = 0.9.7. I have since noticed that it uses parts of the api from 0.9.11 and compilation will fail against previous versions. Thanks -- Arthur Taylor [EMAIL PROTECTED]
