Re: [PATCH 1/7] dsound: Remove support for IKsPropertySet for now
Maarten Lankhorst wrote:
-- As I said, I'm confident nobody uses it, since wine never implemented it properly anyway ---
I think you will find that you will have to add it back later because both interfaces are commonly used. The private interface is used for enumerating devices and is the only way of getting some information about the actual hardware. The buffer interface is commonly used to determine special hardware effects. Programs do check even if wine doesn't implement them because most windows sound cards don't either. In fact, now that you will be using openal you might have the opportunity to actually add real effects!
Hi Robert, Robert Reif schreef:
Maarten Lankhorst wrote:
-- As I said, I'm confident nobody uses it, since wine never implemented it properly anyway ---
I think you will find that you will have to add it back later because both interfaces are commonly used.
The private interface is used for enumerating devices and is the only way of getting some information about the actual hardware. Yeah, but I haven't found a single program that seems to use it, and since the reworking is already hard enough right now to split up, I felt that leaving it in the patchset would make my work even harder. It will be added back, but I haven't found any program using the IKsPropertySet, either buffer or interface, so I don't really have any non-wine testcases. The buffer interface is commonly used to determine special hardware effects. Programs do check even if wine doesn't implement them because most windows sound cards don't either. In fact, now that you will be using openal you might have the opportunity to actually add real effects! I'm aware, but working on reworking things at the moment, since the whole directsound interface will be replaced, this code would be reimplemented as well.
Does the removal really break anything? I thought that on acceleration < full those interfaces wouldn't be available anyhow, so programs should be able to deal with it. If not, I'm very interested in seeing those programs, since none of the programs I tested really seemed to care, even programs that used dsound3d. If a program breaks on this, I would be really interested, since I thought IKsPropertySet isn't even supposed to be available on a software loc buffer (which is all our directsound supports anyhow). Cheers, Maarten.
I believe the approach you are taking moving openal into direct sound is not a good idea and is going to create a lot of regressions that can not be fixed with your current approach. Windows audio programmers know that they can get access to the same hardware through multiple APIs at the same time. That's because all the APIs eventually go through the same driver to access the hardware. A common scenario for voip type applications using direct sound is to find the corresponding wave device using the private property set and then find the mixer device from the wave device so they can get access to the mixer volume to implement microphone AGC. The right approach for using openal is to develop an openal driver like our current oss and alsa drivers. That way all APIs will have the same consistent view of the hardware. The direct sound driver API already supports multiple hardware buffer access so the software mixer can be bypassed. You need to look at voip and audio conferencing applications. You also need to look at XP era utilities and games that came with boxed Creative sound cards. You could also try XP era openal programs using the supplied openal dll which is just a thin layer over direct sound.
On Thursday 03 December 2009 3:57:49 pm Robert Reif wrote:
I believe the approach you are taking moving openal into direct sound is not a good idea and is going to create a lot of regressions that can not be fixed with your current approach.
Windows audio programmers know that they can get access to the same hardware through multiple APIs at the same time. That's because all the APIs eventually go through the same driver to access the hardware.
FWIW, Creative has a dsound->openal wrapper for Windows called ALchemy that does pretty much what this is doing. It provides a dsound.dll that forwards dsound calls to OpenAL. Unfortunately it only works with Creative's hardware drivers (otherwise they risk getting an openal device that uses dsound..) and it's not open source. It's designed for XP-era and earlier software, to re- enable true dsound acceleration.
The right approach for using openal is to develop an openal driver like our current oss and alsa drivers. That way all APIs will have the same consistent view of the hardware. The direct sound driver API already supports multiple hardware buffer access so the software mixer can be bypassed.
An issue is that the current dsound driver setup just sucks. It's part of the reason why no one has added a Pulse backend, despite people willing to maintain one, AFAIK. I also don't think it handles properly forwarding DSound3D calls, so all that will be lost anyway. Is it a problem if those other APIs (WinMM, WASAPI, etc) use DSound for device enumeration, output, and capture? They would maintain the same device list and homogeneous hardware access that way. Another option is to put the dsound->openal wrapper in a separate driver, and make dsound.dll a thin wrapper to it (eg. DirectSoundCreate calls are forwarded, so there's no wrapper interfaces like with d3d9->wined3d). But then that pretty much leaves us where we would be with dsound as the wrapper, as far as apps and such are concerned. Does it make much difference if the other APIs use a very-dsound-like API from wine_al.drv, or dsound.dll itself?
Hi Robert, Robert Reif schreef:
I believe the approach you are taking moving openal into direct sound is not a good idea and is going to create a lot of regressions that can not be fixed with your current approach.
Windows audio programmers know that they can get access to the same hardware through multiple APIs at the same time. That's because all the APIs eventually go through the same driver to access the hardware.
A common scenario for voip type applications using direct sound is to find the corresponding wave device using the private property set and then find the mixer device from the wave device so they can get access to the mixer volume to implement microphone AGC. If pulseaudio is active, our mixer volume won't be much good anyhow. Happens on most installations already..
Looking at dns9 for example, it doesn't use dsound and combines it with mixing. It uses winmm waveout + mixer, ventrilo is quite a popular voice chat program, it still doesn't use the propset mapping, you have to select the mixer by hand.. I could try others, but not having a mapping, or a mapping thats invalid, is not that big a deal.
The right approach for using openal is to develop an openal driver like our current oss and alsa drivers. That way all APIs will have the same consistent view of the hardware. The direct sound driver API already supports multiple hardware buffer access so the software mixer can be bypassed. No, the right approach would be to finally create a WASAPI implementation, use openal there too, and kill off all our crappy winmm drivers and forward to wasapi instead. The headers to do this are mostly in place, and eventually this too will have to be done. You need to look at voip and audio conferencing applications. You also need to look at XP era utilities and games that came with boxed Creative sound cards. You could also try XP era openal programs using the supplied openal dll which is just a thin layer over direct sound. native openal32 -> dsound -> openal-soft already works properly, even builtin openal32->openal-soft + dsound->openal-soft is handled properly. And those boxed games would in the future even work better, since we could start supporting EAX extensions..
Cheers, Maarten.
The current wine direct sound implementation can do multiple opens of the same device and hardware mixing and hardware 3d acceleration without any modifications if the low level driver supports it. No wine audio driver implements all that because the linux audio APIs don't support it. An openal driver can be developed which can eventaully replace the alsa and oss drivers and supports everything you would expect on a real windows system. A total rewrite of the entire audio system from scratch might be better in the long run but just adding an openal driver doesn't require changing any of the existing wine code, it only adds a new driver. Writing an openal driver is probably a half a man year effort to get working well enough to make it the default driver. Doing a total rewrite of all wine audio APIs to move them from the Windows 95 driver model to the current WDM driver model is probably a 5 man year effort to get working right. Your approach may make some direct sound games work better but it is going to introduce a lot of unfixable regressions. The current wine audio implementation does a pretty good job of implementing the windows 95 audio model. It's not the direct sound or winmm dlls that make audio suck in wine, it's the alsa and oss drivers that suck and that's because the alsa and oss APIs and their low level drivers suck (and pulseaudio would suck even worse). An openal driver would allow wine to support all the features that the current direct sound implementation already supports but can't use because of current alsa and oss driver limitations.
Robert Reif wrote:
The current wine direct sound implementation can do multiple opens of the same device and hardware mixing and hardware 3d acceleration without any modifications if the low level driver supports it. No wine audio driver implements all that because the linux audio APIs don't support it. An openal driver can be developed which can eventaully replace the alsa and oss drivers and supports everything you would expect on a real windows system. A total rewrite of the entire audio system from scratch might be better in the long run but just adding an openal driver doesn't require changing any of the existing wine code, it only adds a new driver. Writing an openal driver is probably a half a man year effort to get working well enough to make it the default driver. Doing a total rewrite of all wine audio APIs to move them from the Windows 95 driver model to the current WDM driver model is probably a 5 man year effort to get working right. Your approach may make some direct sound games work better but it is going to introduce a lot of unfixable regressions.
The current wine audio implementation does a pretty good job of implementing the windows 95 audio model. It's not the direct sound or That stuff is unmaintainable and is unmaintained. And is a big steaming pile of butt ugly code.
winmm dlls that make audio suck in wine, it's the alsa and oss drivers that suck and that's because the alsa and oss APIs and their low level drivers suck (and pulseaudio would suck even worse). An openal driver would allow wine to support all the features that the current direct sound implementation already supports but can't use because of current alsa and oss driver limitations. The ALSA, OSS. PA, ESD, JACK, etc. etc. drivers are part of the "windows 95 audio model" problem. Just adding an OpenAL driver to the mix won't make the problem go away. It would rather add to the smell of the pile.
So one can waste time on trying to patch and cleanup the Win95 driver model and still be on a dead end road. Or fix it for good. bye michael
Hi, Robert Reif schreef:
The current wine direct sound implementation can do multiple opens of the same device and hardware mixing and hardware 3d acceleration without any modifications if the low level driver supports it. No wine audio driver implements all that because the linux audio APIs don't support it. An openal driver can be developed which can eventaully replace the alsa and oss drivers and supports everything you would expect on a real windows system. A total rewrite of the entire audio system from scratch might be better in the long run but just adding an openal driver doesn't require changing any of the existing wine code, it only adds a new driver. Writing an openal driver is probably a half a man year effort to get working well enough to make it the default driver. Doing a total rewrite of all wine audio APIs to move I'm NOT going to touch our winmm drivers any more apart from maintanance. I am willing to make 1 more, 'wine7audio' that forwards to IAudioClient, and does all bizarre things like looping wave packets, etc there, so our audio will be sanitized. After that all our other 3.1 era winmm drivers will die. The windows 7 api is a lot cleaned up in that aspect.
If you look at our driver code, they all do EXACTLY the same crap, except they're in various stages of decay. I don't call that a good thing to base our code on. Especially since they all have the same buggy ring buffer implementation that for some of them might still end up being dead locked since a message is missed.
them from the Windows 95 driver model to the current WDM driver model is probably a 5 man year effort to get working right. Your approach may make some direct sound games work better but it is going to introduce a lot of unfixable regressions. You mean implementing mmdevapi? Could be done in under 3 months, with time spare to do the wine7audio driver.. The current wine audio implementation does a pretty good job of implementing the windows 95 audio model. It's not the direct sound or winmm dlls that make audio suck in wine, it's the alsa and oss drivers that suck and that's because the alsa and oss APIs and their low level drivers suck (and pulseaudio would suck even worse). An openal driver would allow wine to support all the features that the current direct sound implementation already supports but can't use because of current alsa and oss driver limitations. Nobody uses the drivers as they are implemented, since nothing can depend on how windows implements them, it changes every major release. Not a single program can look at the dsound internals, which is why something like alchemy on windows works, which is exactly what we do here.
Cheers, Maarten.
Am 04.12.2009 um 16:00 schrieb Maarten Lankhorst:
I'm NOT going to touch our winmm drivers any more apart from maintanance. I am willing to make 1 more, 'wine7audio' that forwards to IAudioClient, and does all bizarre things like looping wave packets, etc there, so our audio will be sanitized. After that all our other 3.1 era winmm drivers will die. The windows 7 api is a lot cleaned up in that aspect. I like this idea - that would allow us to implement a clean Windows 7 sound driver system without breaking things in between. Dsound and winmm can be gradually moved over to the win7 system, and once that is done the old win3.1 sound system can be removed.
Nobody uses the drivers as they are implemented, since nothing can depend on how windows implements them, it changes every major release. Not a single program can look at the dsound internals, which is why something like alchemy on windows works, which is exactly what we do here. I'm afraid these are famous last words. Apps rely on all sorts of strange things that are different between Windows versions. And if they're different, they implement two different codepaths for Win XP and Win7, etc.
Wrt OpenAL, I am opposed to using it for our sound system. I think its a good idea for the transition to Win7, as a first driver and probably later reference driver. But I think we need an exit strategy to get rid of OpenAL as a hard requirement once the transition is done. The reason is that getting bugs fixed in 3rd party libs is a pain, and making distros update 3rd party libs is even a bigger pain. OpenAL is a multi-vendor standard. If it turns out that we need some extension for a dsound speciality it will take a lot of lobbying work to make Apple support it. The Linux side will be much easier, but it will take years before distros pick up the change and users pick up the new distros. So we won't be able to rely on this for a bunch of years. (E.g: On the GL side look at GL_EXT_direct_state_access, or the additions I made to binutils and gcc for the Steam overlay)
On Friday 04 December 2009 7:50:59 am Stefan Dösinger wrote:
Wrt OpenAL, I am opposed to using it for our sound system. I think its a good idea for the transition to Win7, as a first driver and probably later reference driver. But I think we need an exit strategy to get rid of OpenAL as a hard requirement once the transition is done.
Though you'll still need a way to talk to the hardware. Using ALSA/OSS/etc directly has proven problematic with not only the current design and upkeep, but properly implementing various features. Not that I'm advocating PulseAudio here, but it is closer to how the Windows audio stack is, and it's put in quite a bit of dedicated work to get where it is. Plus when you consider integration, having home-grown layers on top of hardware doesn't work that well. GDI/Direct3D wouldn't be where it is now if it didn't have Xorg/OpenGL to integrate into the user's graphics system. Similarly, making DSound use OpenAL will better integrate sound into the user's system by automatically honoring OpenAL's settings (eg. surround sound, audio quality), and outputting on whatever device/API it's configured to (eg. Pulse, networked), without DSound itself having to care.
Am 04.12.2009 um 18:51 schrieb Chris Robinson:
Though you'll still need a way to talk to the hardware. Using ALSA/OSS/etc directly has proven problematic with not only the current design and upkeep, but properly implementing various features. Not that I'm advocating PulseAudio here, but it is closer to how the Windows audio stack is, and it's put in quite a bit of dedicated work to get where it is. Well, from that point of view OpenAL is just another abstraction layer, if you don't happen to have a creative card with native openal support. While I usually agree with using a system provided abstraction layer for average apps, I think Wine has many low level needs that are tough to satisfy through an abstraction layer. If you hit a driver bug somewhere in an osx driver its easier to work around it with a coreaudio backend than through openal.
Plus when you consider integration, having home-grown layers on top of hardware doesn't work that well. GDI/Direct3D wouldn't be where it is now if it didn't have Xorg/OpenGL to integrate into the user's graphics system. OpenGL are X11 is the lowest hardware vendor independent graphics and 3D interface. If we didn't use them, we'd have to rewrite driver for each GPU and would call our project ReactOS and not Wine. If we don't use OpenAL, we still don't have to implement HW drivers ourselves.
I also don't trust the OSX OpenAL implementation. Using your openal thunk with Trackmania on OSX I get broken sound and random stack corruption. I didn't investigate much yet, and just tested with one game, but it certainly leaves a bad first impression(the Linux SW openal with your thunk works perfectly with this game) If all Linux drivers(including the proprietary ones) offered the Gallium3D interface which is more low level and not something a Linux game would use, I'd still use it for Wine - its much easier to use it for our needs than opengl(easier in the sense that you have better HW control and don't have to lobby for extensions). Plus, we're already using lots and lots of vendor specific GL extensions instead of the ARB standardized stuff which is often only available on the next generation of GPUs for similar reasons.
On Friday 04 December 2009 3:53:46 pm Stefan Dösinger wrote:
Am 04.12.2009 um 18:51 schrieb Chris Robinson:
Though you'll still need a way to talk to the hardware. Using ALSA/OSS/etc directly has proven problematic with not only the current design and upkeep, but properly implementing various features. Not that I'm advocating PulseAudio here, but it is closer to how the Windows audio stack is, and it's put in quite a bit of dedicated work to get where it is.
Well, from that point of view OpenAL is just another abstraction layer, if you don't happen to have a creative card with native openal support.
Except it also has API-provided 3D features that would be a big benefit for implementing DSound3D, and has a defined API that can be re-implemented to best take advantage of the user's system (I still imagine someone making an implementation that off-loads storage and mixing into PulseAudio's server; just imagine that, where each DSound Buffer represents a stream that is mixed remotely and efficiently, and completely inline with the rest of the system). And Wine wouldn't have to lift finger to get it.
While I usually agree with using a system provided abstraction layer for average apps, I think Wine has many low level needs that are tough to satisfy through an abstraction layer. If you hit a driver bug somewhere in an osx driver its easier to work around it with a coreaudio backend than through openal.
That's true. But at times, I still think it's better to use the existing APIs for proper integration, where it counts. It will give Wine a boost for not needing to maintain a separate audio stack, and it also improves OpenAL implementations by testing them and extending them with useful requested features. You hit a bug in OpenAL, then OpenAL can (and should) be fixed. When OpenAL gets fixed, then Wine is implicitly fixed along with other affected apps. But if Wine uses its own stack built on the hardware and a bug crops up, you need to wait until someone can fix Wine. Just look at the situation with PulseAudio to see what I mean (OpenAL has supported Pulse for the last few versions, when we're not trying to break each other; Wine still doesn't properly support it because the driver interface is a mess that noone's willing or able to fix). Ever since the openal dll thunk was first made, and I implemented the original dsound->openal wrapper, I've been able to significantly improve (and am still improving) the Linux version of OpenAL, which has helped DSound-based games. It will also be a big help when work is done to implement EAX, as it will help push its EFX implementation; helps OpenAL, and it gets EAX support for DSound games. Improving OpenAL will help it get support from other software developers, which will provide Wine with new features and better tested code.
I also don't trust the OSX OpenAL implementation. Using your openal thunk with Trackmania on OSX I get broken sound and random stack corruption. I didn't investigate much yet, and just tested with one game, but it certainly leaves a bad first impression(the Linux SW openal with your thunk works perfectly with this game)
Understandable, but at the same time, it gives something to Apple to improve their OpenAL implementation with (especially if you're getting stack corruption, which sounds like a potential security issue).
Am 05.12.2009 um 10:35 schrieb Chris Robinson:
Except it also has API-provided 3D features that would be a big benefit for implementing DSound3D, This is indeed a big plus for OpenAL - if we use our own sound system we'll have to reimplement DSound3D features. It fits the "sit on the shoulders of giants" - use existing infrastructure instead of reinventing the wheel, which is usually considered good software engineering practice.
and has a defined API that can be re-implemented to best take advantage of the user's system The same can be said if we have our own sound system. Its "we have to lift a finger" vs "we have a sound infrastructure that matches windows perfectly"
You hit a bug in OpenAL, then OpenAL can (and should) be fixed. When OpenAL gets fixed, then Wine is implicitly fixed along with other affected apps. But if Wine uses its own stack built on the hardware and a bug crops up, you need to wait until someone can fix Wine. Considering that it takes years to get a third party project fixed and the fix shipped to users I'd rather fix Wine. (Yeah, I know you're maintaining Linux OpenAL, so that would make fixing Linux OAL much easier if needed - but not getting it shipped)
I also don't trust the OSX OpenAL implementation. Understandable, but at the same time, it gives something to Apple to improve their OpenAL implementation with (especially if you're getting stack corruption, which sounds like a potential security issue). They don't seem to care about 50-line opengl apps that cause kernel panics or crash the window server reliably. As bad as it sounds, on the apple side you either have to live with their bugs for a long time or abandon the platform. (As an interesting factoid, the GCC developers don't work around bugs in the host's assembler and linker toolchain. Except on OSX)
Your OpenAL software implementation might help there. If it works on OSX we'd have an alternative we could point users to.
On Sat, Dec 5, 2009 at 12:50 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote:
Am 05.12.2009 um 10:35 schrieb Chris Robinson:
Except it also has API-provided 3D features that would be a big benefit for implementing DSound3D, This is indeed a big plus for OpenAL - if we use our own sound system we'll have to reimplement DSound3D features. It fits the "sit on the shoulders of giants" - use existing infrastructure instead of reinventing the wheel, which is usually considered good software engineering practice.
Personally I think DSound3D shouldn't be a high priority and I'm not sure if it is important for our design (DSound3D is more or less dead anyway for modern games). We need a stable sound system which is ready for the future. I don't think it is wise to stay with the current win95 design and hack more stuff into it. Personally I think the best is to go for the Vista/Win7 design which means implementing mmdevapi/wasapi and layer winmm / dsound on top of that. For dsound3d we could create a IAudioClient3D or so. This is how it should be done in the long term. Right now we are a couple of months away for a Wine 1.2 freeze. If dsound->openal works well enough it might be a good short-term solution but the code should be written in such a way that it would be easy to move it to a wasapi backend (I imagine that we will have an openal reference backend but next to that other backends like CoreAudio). Work can already begin on a wasapi implementation. It might be possible to have a basic wasapi implementation in wine 1.2 (winmm / dsound wouldn't use it). If people want they can use their vista/win7 dsound dlls if they own a windows license. Roderick
Roderick Colenbrander <thunderbird2k(a)gmail.com> writes:
Right now we are a couple of months away for a Wine 1.2 freeze. If dsound->openal works well enough it might be a good short-term solution but the code should be written in such a way that it would be easy to move it to a wasapi backend (I imagine that we will have an openal reference backend but next to that other backends like CoreAudio).
It doesn't make sense to add a short term solution, the current dsound is perfectly adequate for 1.2. If we are going to have the dsound->openal rewrite in 1.2, we need to agree that this is the long term solution. We can't have a dsound rewrite in 1.2 and another one in 1.3. I also don't understand your mention of a CoreAudio backend. To me the reason for going to OpenAL is as an OS abstraction layer, to avoid the need to have different backends. If we are just moving the current driver mess over to the win7 model, with an extra OpenAL driver in the mix, we are only making things worse. -- Alexandre Julliard julliard(a)winehq.org
I don't have issues with what Maarten is trying to accomplish. In fact I'm happy to see someone making a serious effort to fix wine audio. What I do have serious issue with is the way he is attacking the problem. The windows 95 driver model is not a bad model. If you look at the winmm driver API and the winmm API, they are virtually the same. The same is true for the direct sound driver API and the direct sound API. Under ideal circumstances the winmm and direct sound dlls are doing nothing but marshaling between user space and kernel space. An application is virtually interfacing directly with the audio driver. The problem with the windows 95 driver model is that the user experience depends totally on the quality of the sound driver and sound hardware. If the hardware doesn't do something, an application using it also can't do it. Microsoft redesigned their sound system to provide consistent audio capabilities regardless of the hardware capabilities by placing software between the drivers and the APIs to change whatever the APIs requested to something the hardware can handle. Also because all audio drivers were virtually the same, they also refactored the audio system to place common code in intermediate software layers. The problems Microsoft had are the same problems wine currently has: inconsistent audio experience. Wine audio works fine for some people and not at all for others because the hardware and operating system and audio API they are using are different. The approach Maarten is taking by starting with direct sound is backwards and will cause serious regressions. You can't just throw out working code that applications use just because most people won't notice. Maarten has admitted that he will have to develop an openal winmm driver but not right away. What he should do is develop that driver first and get it working well along side the current drivers. This won't immediately help direct sound but direct sound will be able to use it. The next step should be to decide if we want to use openal as the one and only audio API in wine. If so, then we have two approaches to do that. We can add a direct sound API to the openal winmm driver just like we do with existing drivers or put openal code in the direct sound dll. If we are absolutely confident that the openal winmm driver can operate properly with the openal direct sound dll at the same time, then that would be a reasonable approach. The only down side is that audio code is not centralized. If state needs to be shared between the two APIs, then a single driver is the best approach. The big problem with the current direct sound dll is that it must do software mixing and format and sample rate conversions when the low level driver doesn't do what the application requested. In wine, none of the drivers can do what is requested. If the low level driver was guaranteed to do anything the application requested, we could remove that code. Then we are down to just marshaling between the app and the audio driver or API. We need a design approach and a road map and an agreement that the approach is correct. We also need to insure that regressions are not introduced during the process. I would like to see an incremental solution that doesn't introduce regressions. That is developing an openal winmm driver first and then address the best solution for the direct sound issue later. Not the other way around.
2009/12/3 Robert Reif <reif(a)earthlink.net>
Maarten Lankhorst wrote:
-- As I said, I'm confident nobody uses it, since wine never implemented it properly anyway ---
I think you will find that you will have to add it back later because both interfaces are commonly used.
The private interface is used for enumerating devices and is the only way of getting some information about the actual hardware.
The buffer interface is commonly used to determine special hardware effects. Programs do check even if wine doesn't implement them because most windows sound cards don't either. In fact, now that you will be using openal you might have the opportunity to actually add real effects!
Actually, vietcong games uses IKsPropertySet (see bug 9337)
David.
David Adam schreef:
2009/12/3 Robert Reif <reif(a)earthlink.net <mailto:reif(a)earthlink.net>>
Maarten Lankhorst wrote:
-- As I said, I'm confident nobody uses it, since wine never implemented it properly anyway ---
I think you will find that you will have to add it back later because both interfaces are commonly used.
The private interface is used for enumerating devices and is the only way of getting some information about the actual hardware.
The buffer interface is commonly used to determine special hardware effects. Programs do check even if wine doesn't implement them because most windows sound cards don't either. In fact, now that you will be using openal you might have the opportunity to actually add real effects!
Actually, vietcong games uses IKsPropertySet (see bug 9337) That's IKsPropertySet on a buffer, which is used for per-buffer things like EAX and stuff like that. I will move it from propset.c to buffer.c, and implement noop stubs for my dsound openal wrapper too, that would be sufficient until we start working on things like eax effects..
Cheers, Maarten.
participants (8)
-
Alexandre Julliard -
Chris Robinson -
David Adam -
Maarten Lankhorst -
Michael Stefaniuc -
Robert Reif -
Roderick Colenbrander -
Stefan Dösinger