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 art(a)ified.ca theycallhimart(a)gmail.com
Hi Arthur, I would recommend you to also read this thread: http://www.winehq.org/pipermail/wine-devel/2009-June/076102.html As mentioned before we would like not to have a pulse audio driver if it isn't needed at all. Some suggestions have been made to use some pulseaudio rules of thumb in our winealsa code to improve the situation. This is likely not doable for some of the stuff like mmap which is needed for direct card access (directsound requires that) but fixes in that area could already improve winealsa <-> pulse interaction a lot. Remaining issues might be solvable in cooperation with the pulse developers. I think a lot of issues can already be fixed without requiring a new driver. Regards, Roderick Colenbrander On Tue, Jun 16, 2009 at 12:33 PM, Arthur Taylor<theycallhimart(a)gmail.com> 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
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 art(a)ified.ca theycallhimart(a)gmail.com
On Tue, Jun 16, 2009 at 2:14 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
I think a lot of issues can already be fixed without requiring a new driver.
One of the problems is, every time one of these issues is brought up, we hear people complaining "But Pulseaudio should be a drop-in replacement! We shouldn't have to change our code". There is a major (and irritating) circle of blaming that comes up every time the subject of PA is brought up. If anything should be fixed first, it's the attitude people have with it. I'm not going to argue with designs; I'm no sound developer. I don't like PA, it's way too unstable still; the only reason I use it is because of a pair of USB headphones which don't work properly under ALSA. If issues can be fixed without requiring a new driver, they definitely should be. What is irritating is the "Just don't use Pulse" attitude some people have. Both most recently Scott Richie and Arthur Taylor, and also other earlier authors, have done really great efforts on what is perceived as a "problem with wine" -- *nevermind* whose fault it actually is -- and none of this should be shrugged off with a "What's the point? This won't ever be accepted". Have some respect. Jerome PS. This is not directed towards anyone in particular. -- J. Leclanche
2009/6/16 Jerome Leclanche <adys.wh(a)gmail.com>:
On Tue, Jun 16, 2009 at 2:14 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
I think a lot of issues can already be fixed without requiring a new driver.
One of the problems is, every time one of these issues is brought up, we hear people complaining "But Pulseaudio should be a drop-in replacement! We shouldn't have to change our code". There is a major (and irritating) circle of blaming that comes up every time the subject of PA is brought up. If anything should be fixed first, it's the attitude people have with it.
I'm not going to argue with designs; I'm no sound developer. I don't like PA, it's way too unstable still; the only reason I use it is because of a pair of USB headphones which don't work properly under ALSA. If issues can be fixed without requiring a new driver, they definitely should be. What is irritating is the "Just don't use Pulse" attitude some people have. Both most recently Scott Richie and Arthur Taylor, and also other earlier authors, have done really great efforts on what is perceived as a "problem with wine" -- *nevermind* whose fault it actually is -- and none of this should be shrugged off with a "What's the point? This won't ever be accepted". Have some respect.
FWIW,there is a simple PulseAudio API that exposes an OSS-like open/read/write/close API to pulseaudio. The previous attempt, IIRC, was based on the more complicated pulseaudio API and based on the winealsa code. It should (in theory) be possible to create a pulseaudio driver using this simpler pulseaudio API and the wineoss driver. - Reece
Am Dienstag, 16. Juni 2009 13:41:26 schrieb Jerome Leclanche:
One of the problems is, every time one of these issues is brought up, we hear people complaining "But Pulseaudio should be a drop-in replacement! We shouldn't have to change our code". There is a major (and irritating) circle of blaming that comes up every time the subject of PA is brought up. If anything should be fixed first, it's the attitude people have with it. <rant> s/PulseAudio/Wine. If Wine had the attitude towards broken Windows apps as the PA devs have towards broken broken Alsa apps we'd probably run 10 Applications with Wine and mostly rant about how broken Windows apps are.
It seems to me that PA people do not enjoy the beauty of writing a compatibility layer that is actually compatible. In Wine terms, if e.g. a D3D app works on 50% of 3D cards out there(ATI+NV) and fails on the cards provided by the biggest GPU vendor(Intel), the game is OK and should work on Wine. If you apply the same compatibility expectations to Wine and PA, if PA wanted to be actually compatible, anything that works on snd_intel8x0 and snd_hda_intel should work in PA. </rant>. Sorry. Just had to let of steam. That said, yes, Wine does do some things wrong. And Wine is an open source app, so you can fix Wine, unless all those broken Windows apps. And we should fix our Alsa code. Now, there is no current maintainer for the Alsa code, since Maarten Lankhorst stopped regular work on Wine. That's why we know what's wrong since a time and nobody fixed it. So I invite everyone who wants PA working to volunteer to take over maintainance of the sound code. Winealsa, dsound and winmm need a maintainer. Before they have one, rants about PulseAudio go to /dev/null because nobody feels responsible to listen to them.
On Tue, Jun 16, 2009 at 4:48 PM, Stefan Dösinger<stefandoesinger(a)gmx.at> wrote:
Am Dienstag, 16. Juni 2009 13:41:26 schrieb Jerome Leclanche:
One of the problems is, every time one of these issues is brought up, we hear people complaining "But Pulseaudio should be a drop-in replacement! We shouldn't have to change our code". There is a major (and irritating) circle of blaming that comes up every time the subject of PA is brought up. If anything should be fixed first, it's the attitude people have with it. <rant> s/PulseAudio/Wine. If Wine had the attitude towards broken Windows apps as the PA devs have towards broken broken Alsa apps we'd probably run 10 Applications with Wine and mostly rant about how broken Windows apps are.
Well, but Wine doesn't fix bugs for Windows programs. If a program doesn't work in Windows, it's not a requirement that it works in Wine. I think that the PulseAudio developer means the same thing for PA. Some apps use ALSA in a way that cannot be expected to work. In other words: it probably fails on some ALSA systems as well. Remco
Am Dienstag, 16. Juni 2009 17:39:47 schrieb Remco:
Well, but Wine doesn't fix bugs for Windows programs. If a program doesn't work in Windows, it's not a requirement that it works in Wine.
I think that the PulseAudio developer means the same thing for PA. Some apps use ALSA in a way that cannot be expected to work. In other words: it probably fails on some ALSA systems as well. The *some* is the key here. If Windows app X is broken, but works on *some* Windows systems, we generally implement the specific behavior of those "some" systems where it works.
The GPU example is just the most prominent example. Intel cards are 50+% of the market share, but there are many games that don't work on them. If this game fails for the same reason on Wine, I consider this a bug in Wine. There are other examples too. Just look for complaints of Wine tests failing on Windows because our tests are too strict.
On Tue, Jun 16, 2009 at 4:14 AM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
Hi Arthur,
I would recommend you to also read this thread: http://www.winehq.org/pipermail/wine-devel/2009-June/076102.html
As mentioned before we would like not to have a pulse audio driver if it isn't needed at all. Some suggestions have been made to use some pulseaudio rules of thumb in our winealsa code to improve the situation. This is likely not doable for some of the stuff like mmap which is needed for direct card access (directsound requires that) but fixes in that area could already improve winealsa <-> pulse interaction a lot. Remaining issues might be solvable in cooperation with the pulse developers.
Hi, Direct card access in my opinion is arguable as to whether it is really needed. I don't think Vista allows you create a hardware buffer anymore. I've written a few wine drivers (gstreamer and pulseaudio native..both gave about the same latency actually) because of the pulseaudio situation and earlier problems with alsa (that maarten largely fixed). I found you could easily emulate hardware buffers yourself and get most of the benefits of rather then using Wines HEL mode. What this really means that wine's HEL could be improved. There seems to be a lot of latency introduced somewhere inside it since i have always seen a reduction in latency by adding support to create a "hardware" buffer and letting the dsound mixer mix into it rather then letting it do what should be the same work and write out the wavehdrs. Hacking in hardware secondary buffers was where you see the biggest improvement which points to the dsound mixer mixing samples from the secondary buffers to primary as the culprit. But, this can be a hard thing to make fast and not cause audio issues, i've tried and had mixed success with similar tasks. What I have done is made a simple stream like interface for both my drivers that allows both to use the same stream api to implement the winmm portion and the also use it to provide my own dsound emulation that works best for the driver. When wine starts to implement XAudio2 (i don't even know if any games require this at this stage) but current i think that would cause another driver like interface which would only make maintaining the drivers very difficult.
I think a lot of issues can already be fixed without requiring a new driver.
I think most probably can be fixed. I think the fallback method might currently have some bugs so when the winealsa driver detects that the pulse emulation can't do what it wants it still does a few things that clash with what pulse provides through alsa. Anyway...just my view on this issue. Cheers, Trevor
2009/6/16 Trevor Davenport <trevor.davenport(a)gmail.com>:
On Tue, Jun 16, 2009 at 4:14 AM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote:
Hi Arthur,
I would recommend you to also read this thread: http://www.winehq.org/pipermail/wine-devel/2009-June/076102.html
As mentioned before we would like not to have a pulse audio driver if it isn't needed at all. Some suggestions have been made to use some pulseaudio rules of thumb in our winealsa code to improve the situation. This is likely not doable for some of the stuff like mmap which is needed for direct card access (directsound requires that) but fixes in that area could already improve winealsa <-> pulse interaction a lot. Remaining issues might be solvable in cooperation with the pulse developers.
Hi,
Direct card access in my opinion is arguable as to whether it is really needed. I don't think Vista allows you create a hardware buffer anymore. I've written a few wine drivers (gstreamer and pulseaudio native..both gave about the same latency actually) because of the pulseaudio situation and earlier problems with alsa (that maarten largely fixed).
I found you could easily emulate hardware buffers yourself and get most of the benefits of rather then using Wines HEL mode. What this really means that wine's HEL could be improved. There seems to be a lot of latency introduced somewhere inside it since i have always seen a reduction in latency by adding support to create a "hardware" buffer and letting the dsound mixer mix into it rather then letting it do what should be the same work and write out the wavehdrs. Hacking in hardware secondary buffers was where you see the biggest improvement which points to the dsound mixer mixing samples from the secondary buffers to primary as the culprit. But, this can be a hard thing to make fast and not cause audio issues, i've tried and had mixed success with similar tasks.
What I have done is made a simple stream like interface for both my drivers that allows both to use the same stream api to implement the winmm portion and the also use it to provide my own dsound emulation that works best for the driver.
When wine starts to implement XAudio2 (i don't even know if any games require this at this stage) but current i think that would cause another driver like interface which would only make maintaining the drivers very difficult.
I think a lot of issues can already be fixed without requiring a new driver.
I think most probably can be fixed. I think the fallback method might currently have some bugs so when the winealsa driver detects that the pulse emulation can't do what it wants it still does a few things that clash with what pulse provides through alsa.
Anyway...just my view on this issue.
Cheers, Trevor
I'm with Trevor on the relative importance of having direct card access. Windows Vista substantially broke DirectSound, as now DirectSound can't access the hardware (so it can't use hardware buffers, hardware mixing, etc.). This means also that any application written to use DirectSound3D and that pretends to directly access the hw gets plain 2D stereo sound (and possibly higher latencies as well). In Vista, MME and DirectSound are emulated on top of the new audio stack. Here you can find something about these changes, if interested: http://forums.creative.com/creativelabs/board/message?board.id=Vista&message... Now, I'm not saying that we have to break DirectSound as Microsoft did, but that emulating hardware access, in some instances (such as the mmap access to the sound buffers), maybe only when PulseAudio is present, could be an acceptable solution. I don't think the increased latencies would be a problem, as, at least from my personal experience, Windows-DirectSound has quite high latencies (even pre-Windows Vista, ex. Windows XP). That said, certainly having someone maintaining "Wine audio department" would be great. Just my two cents... Matteo Bruni
On Tuesday 16 June 2009 3:33:12 am Arthur Taylor wrote:
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.
There is no need to use PulseAudio if the issue you have is your card only having a single hardware voice. ALSA includes (since forever, AFAIK) the dmix plugin which does software mixing into a hardware voice across multiple apps. It even works with mmap and all other ALSA calls. I'm not exactly sure when ALSA made the switch, but the 'default' device will use dmix by default on cards that need it, and use hardware mixing when possible. But even if not, you can make a ~/.asoundrc config to override ALSA's 'default' device to use dmix: pcm.mydmix { type dmix ipc_key 1024 ipc_key_add_uid false # let multiple users share ipc_perm 0660 # IPC permissions (octal, default 0600) slave { pcm "hw:0,0" # whatever hw output device you want rate 48000 channels 6 # use this for 5.1; you can set whatever you want period_size 1024 buffer_size 8192 # could set this lower, but Wine doesn't like it } } ctl.mydmix { type hw card 0 # the same card as the one listed in the pcm slave above } pcm.myasym { type asym playback.pcm "mydmix" capture.pcm "hw:0,0" # same as the pcm slave in mydmix } pcm.!default { type plug slave.pcm "myasym" hint { show on description "ALSA Default" } } Then use 'default' or 'mydmix' in your ALSA apps. Sorry for the tangent, but it bothers me when it's said/implied that PulseAudio is needed to get sound from multiple apps.
A detailed, constructive response with a clear vision for where the future of audio in wine lies would be appreciated.
AFAIK, the issue is maintainability. Wine simply doesn't have a developer that's willing to devote their time to creating and maintaining a PulseAudio driver. There's barely enough for the drivers already there (the ALSA backend was really falling apart before Maarten took it up). Simply creating a driver, then keeping an eye on it for a few weeks or months isn't going to cut it.
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(a)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
On Tue, Jun 16, 2009 at 3:24 PM, Michael Stefaniuc<mstefani(a)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(a)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(a)ified.ca theycallhimart(a)gmail.com
2009/6/17 Arthur Taylor <theycallhimart(a)gmail.com>:
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?
This has been discussed somewhere before, and from memory the answer is no. It's not just a simple matter of translating the calls, but the calling conventions are quite different, and iirc there are memory management issues too.
Am Wednesday 17 June 2009 05:24:01 schrieb Arthur Taylor:
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? There is such a DLL around - search the wine-devel and wine patches archives from it. Alexandre said he'd accept such a openal->openal thunk(but not an openal winmm driver). The problem why it is not included yet is that the latest state of the dll broke some games, the original developer ran out of time to work on it(I think he coded it during holiday from his job), and nobody since has continued working on it.
On Tuesday 16 June 2009 8:44:36 pm Stefan Dösinger wrote:
There is such a DLL around - search the wine-devel and wine patches archives from it. Alexandre said he'd accept such a openal->openal thunk(but not an openal winmm driver). The problem why it is not included yet is that the latest state of the dll broke some games, the original developer ran out of time to work on it(I think he coded it during holiday from his job), and nobody since has continued working on it.
I actually have such a DLL thunk in my local tree, and it works perfectly using the newer openal libs (the OpenAL Soft 1.x libs, not the old OpenAL 0.0.x libs). AFAIK, the main issue is that the al[c]GetProcAddress calls need to be fixed (currently they just call straight through to the native lib), and functions introduced by extensions need to be handled as well. On Linux this doesn't pose a problem, as OpenAL on Windows specifically uses the cdecl calling convention, and compilers on Linux default to cdecl. IIRC however, Alexendre said this won't work on OSX. As well, I also have a DSound->OpenAL wrapper (like Alchemy) that works quite well. Games think they're getting hardware accelerated sound (since OpenAL doesn't really tell you if you've got hardware or not, I just fib..), and I get 5.1 surround sound output. It's not perfect, but the apps I tested all work great. Only thing is, it *needs* the DLL thunk to call to the native lib, otherwise the AL libs will try to use DSound for output, causing a circular dependency. And it currently won't work without an extension provided by OpenAL Soft, though I could work around that if I have to. I'd also be interested in adding EAX support to it if OpenAL supports EFX, but I don't know what apps work with that, and I don't know how EAX in DSound works (or what the various levels of EAX have as a requirement).
On Tue, 16 Jun 2009, Arthur Taylor wrote: [...]
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.
That's interesting. Fixing that in wineesd is pretty simple actually. All you have to do is replace dwWrittenTotal with dwPlayedTotal in wodPlayer_NotifyCompletions(). This actually improves the one 5s wavehdr test in our conformance test: without the patch it completes too early, while with dwPlayedTotal it completes in exactly 5s. But fixing this also breaks our ten 0.5s wavehdrs test. Not that it works 100% either way. I need to double check but it feels like our test feeds 1 wavehdr, waits for it to complete (WaitForSingleObject(hevent)), and only then feeds the next wavehdr. Because wineesd has a pretty high latency this results in something like 0.5s of sound, then 0.5s of silence, then 0.5s of sound, etc (it seems like we're also missing a notification for the last wavehdr but that may be a separate issue). This test is supposed to reflect the behavior of streaming applications but I don't think it's really accurate. However I get the same issue with DirectSound. I suspect it's for the same reason: I seem to recall that DirectSound sends as little in advance as possible to not have to redo too much mixing if the input streams change. But that breaks totally if it sends less than the sound driver's latency. Is there a standard way to deal with these latency issues on Windows? Does anyone have ideas on how to best deal with them? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Linux: It is now safe to turn on your computer.
participants (12)
-
Arthur Taylor -
Ben Klein -
Chris Robinson -
Francois Gouget -
Jerome Leclanche -
Matteo Bruni -
Michael Stefaniuc -
Reece Dunn -
Remco -
Roderick Colenbrander -
Stefan Dösinger -
Trevor Davenport