Am Sonntag 26 November 2006 00:25 schrieb Nick Burns:
dlls/openal32/openal.c: main thunk file dlls/openal32/Makefile.in: simple thunk makefile dlls/openal32/openal32.spec: openal+alut spec file dlls/winmm/wineopenal/audio.c: main winmm driver file dlls/winmm/wineopenal/Makefile.in: simple winmm makefile dlls/winmm/wineopenal/openal.c: simple interface dlls/winmm/wineopenal/openal.h: simple header for simple interface dlls/winmm/wineopenal/wineopenal.drv.spec: winmm spec file
I think you should send the thunk and winmm driver in 2 seperate patches
The patches have been split in 2 one for the thunk and one for the winmm driver.
Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs)
- Nick
From: Stefan Dösinger stefandoesinger@gmx.at To: wine-devel@winehq.org CC: Nick Burns adger44@hotmail.com, wine-patches@winehq.org Subject: Re: OpenAL32.dll thunk and OpenAL winmm driver Date: Sun, 26 Nov 2006 20:39:51 +0100
Am Sonntag 26 November 2006 00:25 schrieb Nick Burns:
dlls/openal32/openal.c: main thunk file dlls/openal32/Makefile.in: simple thunk makefile dlls/openal32/openal32.spec: openal+alut spec file dlls/winmm/wineopenal/audio.c: main winmm driver file dlls/winmm/wineopenal/Makefile.in: simple winmm makefile dlls/winmm/wineopenal/openal.c: simple interface dlls/winmm/wineopenal/openal.h: simple header for simple interface dlls/winmm/wineopenal/wineopenal.drv.spec: winmm spec file
I think you should send the thunk and winmm driver in 2 seperate patches
On 11/30/06, Nick Burns adger44@hotmail.com wrote:
The patches have been split in 2 one for the thunk and one for the winmm driver.
Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs)
I always watch for my patches here: http://source.winehq.org/git/?p=wine.git;a=shortlog - either just watching it or a quick search for my name works great.
--Matt Finnicum
Nick Burns wrote:
The patches have been split in 2 one for the thunk and one for the winmm driver.
Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs)
"Rejected" is a strong word. Perhaps you could think of it as "Alexandre hasn't been convinced that these patches should go in".
Is openal32 a standard part of Windows? If not, then is there a sufficient number of applications using it that we should maintain this code in Wine?
Mike
At 16:08 30.11.2006 +0900, Mike McCormack wrote:
Nick Burns wrote:
The patches have been split in 2 one for the thunk and one for the winmm driver. Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs)
"Rejected" is a strong word. Perhaps you could think of it as "Alexandre hasn't been convinced that these patches should go in".
Is openal32 a standard part of Windows? If not, then is there a sufficient number of applications using it that we should maintain this code in Wine?
Vista drops DirectSound or better said, the EAX effects won't work anymore. That's why Creative Labs switches over to OpenAL. So it might become much more important in the future.
http://www.openal.org/openal_vista.html http://www.heise.de/newsticker/meldung/81212 (german)
bye Fabi
On 11/30/06, Fabian Cenedese Cenedese@indel.ch wrote:
Vista drops DirectSound or better said, the EAX effects won't work anymore. That's why Creative Labs switches over to OpenAL. So it might become much more important in the future.
If Creative switched over to using it then I expect all of the future drivers they post that are WHQL will have this dll. I'd say this makes it worth installing. Someone should check if new vista driver downloads from Creative include this or even if Windows Update for Vista loads it.
Am Donnerstag 30 November 2006 08:44 schrieb Steven Edwards:
On 11/30/06, Fabian Cenedese Cenedese@indel.ch wrote:
Vista drops DirectSound or better said, the EAX effects won't work anymore. That's why Creative Labs switches over to OpenAL. So it might become much more important in the future.
If Creative switched over to using it then I expect all of the future drivers they post that are WHQL will have this dll. I'd say this makes it worth installing. Someone should check if new vista driver downloads from Creative include this or even if Windows Update for Vista loads it.
What makes it worth including it in wine is that a huge number of games use it too. Thunking directly to the Linux / macos openal lib avoids the whole openal->directsound->winmm->driver->linux audio api rollercoaster.
That said, its not a standard part of windows. There may be other simmilar libs(like the Palm Desktop libs I considered writing once). How about a seperate wine-3rdpartylibs package containing such things?
On 11/30/06, Stefan Dösinger stefandoesinger@gmx.at wrote:
What makes it worth including it in wine is that a huge number of games use it too. Thunking directly to the Linux / macos openal lib avoids the whole openal->directsound->winmm->driver->linux audio api rollercoaster.
I agree, if having this lib in the wine tree lets us skip the whole rollercoaster and produces better results for the users then we should include it.
On Mi, 2006-11-29 at 22:00 -0800, Nick Burns wrote:
The patches have been split in 2 one for the thunk and one for the winmm driver. Have these patches been rejected?
I have not very much knowledge about Audio, but still some comments:
When you compare your Patch with the Size of other Patches, you Patches are still very large. A large Patch is much harder (in complexity and needed motivation) to review and take more time.
I Suggest, that you should start with "Makefile.in", the spec-file and only DllMain as implemented function. Afterwards, pick one or a small set of Functions for a Patch. Limiting the supported Formats/Version in a Patch and add additional Formats / Versions in the next Patches should also reduce the Patch-Size. (ALC_1_0, AL_1_0, AL*_1_1, ALUT, WaveOut, WaveIn or "OPENAL_LIMIT_IN_44100" as examples).
Some more hints are here: http://wiki.winehq.org/Developers-Hints
There is also dead code in the Patch ("#if 0")
+static int OpenAL_InitRingMessage(ESD_MSG_RING* mr)
You copied code without adapting it.
Another Issue mitht be, that there are plans to merge all the audio-drivers in a single driver (dlls/wineaudio) to avoid most of the code/bug - duplication:
http://wiki.winehq.org/FlattenDllDirectories
I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the "not very well working" code might be a "no go" for Alexandre.
Detlef Riekenberg wine.dev@web.de writes:
I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the "not very well working" code might be a "no go" for Alexandre.
Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code.
The openal dll can certainly go in, but you'll need to clean up the code first, right now it looks like a pretty bad case of macro abuse.
Ok this is some good feedback... (usually i dont get such a massive response from emails...) -- I was under the impression that RFC was the second to last line of defense (so it appears to be the third)
I do not use IRC (unless you count the irc client in Tribes)
I can demacroize the patch -- it was written that way to make it small and easy to add to (since 99% of the functions are pure passthru -- one extra line to the macro adds it and all that it needs) Personally I think its cleaner -- but it has the problem of being a macro
"There not much worse than a macro -- except dare I mention templates (the crowd runs for cover)"
Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice.
Yes my wineopenal patch is not perfect (based on broken code does not help) -- I know that -- but thats why i want to get it into wine -- so other people who know more about audio can add to it and make it better
If the audio drivers are going to collapse -- I could wait until then and 'try' add my winmm patch in that realm.
- Nick
From: Alexandre Julliard julliard@winehq.org To: Detlef Riekenberg wine.dev@web.de CC: Nick Burns adger44@hotmail.com, wine-devel wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch Date: Thu, 30 Nov 2006 19:58:36 +0100
Detlef Riekenberg wine.dev@web.de writes:
I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the "not very well working" code might be a "no go" for Alexandre.
Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code.
The openal dll can certainly go in, but you'll need to clean up the code first, right now it looks like a pretty bad case of macro abuse.
-- Alexandre Julliard julliard@winehq.org
"Nick Burns" adger44@hotmail.com writes:
Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice.
Why? What does it do that you cannot do with the CoreAudio driver?
Yes my wineopenal patch is not perfect (based on broken code does not help) -- I know that -- but thats why i want to get it into wine -- so other people who know more about audio can add to it and make it better
Judging from past experience, people for whom it doesn't work right will simply go out and implement yet another driver, with yet another set of bugs...
From: Alexandre Julliard julliard@winehq.org To: "Nick Burns" adger44@hotmail.com CC: wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch and OpenALwinmm driver patch Date: Fri, 01 Dec 2006 13:49:52 +0100
"Nick Burns" adger44@hotmail.com writes:
Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice.
Why? What does it do that you cannot do with the CoreAudio driver?
True the coreaudio driver can be made awesome -- but as it stands it has problems with many games on my machine (currently hard for me to test due to fullscreen detection changes in ogl) Problems range from deadlocking -- to crackling sound There are a few games that run flawlessly under coreaudio My openal driver also has crackling sound in some games (but i have not yet seen deadlocking -- its possible it could)
Also the coreaudio driver is not testable and wont help linux ppl -- just Mac ppl
An openal driver would be multi-platform -- testable under windows/mac/linux, would add a 2nd built-in driver to Mac OSX.
Yes my wineopenal patch is not perfect (based on broken code does not help) -- I know that -- but thats why i want to get it into wine -- so other people who know more about audio can add to it and make it better
Judging from past experience, people for whom it doesn't work right will simply go out and implement yet another driver, with yet another set of bugs...
True -- it has its own set of bugs -- but I cannot iron them out myself -- I would need help from people to do so -- thats why I would like to give it as an option to you wine people (who can test it on linux)
(its possible i could try and start a side project in sf.net or something -- no clue what other options there are)
In a perfect world we could make an awesome cross-platform openal driver that does ... everything (winmm/dsound/dsound3d/...) everywhere (Linux/Windows/MacOSX)
---------- So, thats all the good stuff about it... The bad stuff is that its another driver in the tree another option to confuse people another point of failure ... (there is more badness here probably)
-- Alexandre Julliard julliard@winehq.org
- Nick
On 1 déc. 06, at 00:54, Nick Burns wrote:
Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice.
In fact there is at least two working sound driver: you can also use the Jack driver on Mac OS X if you've downloaded [1] at compile time which by the way seems to have a working audio input.
Pierre.
Sorry I should have reiterated more clearly... Yes you can dl jack -- but it has never worked correctly for me...(I could try Jack again -- it has been a while....) esd -- but it too did not work so well (very laggy sound) liboss -- but i dont think that the alpha version compiles under osx... (did not really try to hard there i must admit hehe) alsa -- it could be ported -- but .. I dont wish that on anyone
I am referring to builtin sound drivers for Mac OSX -- We have CoreAudio and OpenAL builtin (no alsa, no oss, no esd, no jack, ...)
And coreaudio cannot be tested by anyone except for Mac people... (There seems to be much fewer mac people here...) An OpenAL driver can be tested by linux people with openal (ok those #s i dont know)
So, the openal driver is one that CAN work and be multi platform Coreaudio can be made to be the most awesome as well -- but that does not help linux
- Nick
From: Pierre d'Herbemont pdherbemont@free.fr To: Nick Burns adger44@hotmail.com CC: wine-devel@winehq.org Subject: Re: Concerning the separate OpenAL32.dll thunk patch andOpenALwinmm driver patch Date: Fri, 1 Dec 2006 17:15:30 +0100
On 1 déc. 06, at 00:54, Nick Burns wrote:
Again -- for the sound drivers -- Mac OSX has ONE sound driver ONE I would like to have a choice.
In fact there is at least two working sound driver: you can also use the Jack driver on Mac OS X if you've downloaded [1] at compile time which by the way seems to have a working audio input.
Pierre.
On Thursday 30 November 2006 10:58, Alexandre Julliard wrote:
Detlef Riekenberg wine.dev@web.de writes:
I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the "not very well working" code might be a "no go" for Alexandre.
Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code.
I'm curious about how Wine will handle Windows DirectSound drivers. Apparently Creative is working on a dsound->openal wrapper driver, and with the openal dll, it could take a huge load off of Wine in the dsound department for most people if it could work.
Alexandre Julliard a écrit :
Detlef Riekenberg wine.dev@web.de writes:
I don't know, if wineaudio.drv this is still the way to go, but we have sound crackeling and Buffer-underun Bugs, and adding another copy of the "not very well working" code might be a "no go" for Alexandre.
Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code.
which code are you referring to ? the dsound driver stuff or the winmm driver stuff ? to my knowledge mostly the first one is to blame A+
Eric Pouech eric.pouech@wanadoo.fr writes:
Alexandre Julliard a écrit :
Exactly, we already have 8 sound drivers, and not a single one actually works properly, so I'm pretty reluctant to add yet another copy of the same broken code.
which code are you referring to ? the dsound driver stuff or the winmm driver stuff ? to my knowledge mostly the first one is to blame
Probably both, I don't know where the specific bugs are, and that's exactly the problem. When sound doesn't work, instead of chasing down the bug and fixing it, people just go out and write a new driver, which of course only makes the problem worse.
Am Donnerstag 30 November 2006 07:00 schrieb Nick Burns:
The patches have been split in 2 one for the thunk and one for the winmm driver.
Have these patches been rejected? (I still dont know how to tell that -- other than checking wine-cvs)
The best thing is to ask AJ directly why he didn't apply the patches. From my personal experiance it is best to ask him on irc
-
Alexandre Julliard -
Chris Robinson -
Detlef Riekenberg -
Eric Pouech -
Fabian Cenedese -
Matt Finnicum -
Mike McCormack -
Nick Burns -
Pierre d'Herbemont -
Stefan Dösinger -
Steven Edwards