Re: ALSA implementation
On Mon, Sep 18, 2006 at 01:58:59AM +0200, Jan Zerebecki wrote:
> I explained in a different mail to this thread what bugs are in
> winealsa. (Archive link to that mail is:
> http://www.winehq.org/pipermail/wine-devel/2006-September/050826.html )
> It seems I just found out how to fix the other winealsa problem I
> mentioned in that mail, I'm currently testing if it works.
The intention is to get the same buffer size (in bytes) for different
formats, because dsound expects this (according to our dsound tests).
I tried with the attached patch but
snd_pcm_hw_params_set_buffer_size_near sets different than the
requested size and snd_pcm_hw_params_set_buffer_size doesn't work
at all. I don't know if this is because I am not familiar with
the api or because of a bug in it. Can anyone shed some light on
this who is more familiar with the alsa-lib api?
Jan
From: Jan Zerebecki <[EMAIL PROTECTED]>
Changelog:
winmm/winealsa: set buffer size
---
dlls/winmm/winealsa/audio.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/dlls/winmm/winealsa/audio.c b/dlls/winmm/winealsa/audio.c
index 9eec364..d29e596 100644
--- a/dlls/winmm/winealsa/audio.c
+++ b/dlls/winmm/winealsa/audio.c
@@ -2334,10 +2334,8 @@ static DWORD wodOpen(WORD wDevID, LPWAVE
snd_pcm_access_taccess;
snd_pcm_format_tformat = -1;
unsigned intrate;
-unsigned intbuffer_time = 50;
-unsigned intperiod_time = 1;
-snd_pcm_uframes_t buffer_size;
-snd_pcm_uframes_t period_size;
+snd_pcm_uframes_t buffer_size = 48000;
+snd_pcm_uframes_t period_size = 1024;
int flags;
int err=0;
int dir=0;
@@ -2561,15 +2559,16 @@ #define EXIT_ON_ERROR(f,e,txt) do \
wwo->format.Format.nChannels,
getFormat(wwo->format.Format.wFormatTag));
-dir=0;
-EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_time_near(pcm, hw_params,
&buffer_time, &dir), MMSYSERR_INVALPARAM, "unable to set buffer time");
-dir=0;
-EXIT_ON_ERROR( snd_pcm_hw_params_set_period_time_near(pcm, hw_params,
&period_time, &dir), MMSYSERR_INVALPARAM, "unable to set period time");
+buffer_size = buffer_size / ( snd_pcm_format_physical_width(format) *
wwo->format.Format.nChannels );
+snd_pcm_uframes_t buffer_size_old = buffer_size;
+EXIT_ON_ERROR( snd_pcm_hw_params_set_buffer_size_near(pcm, hw_params,
&buffer_size), MMSYSERR_INVALPARAM, "unable to set buffer size");
+dir=0;
+EXIT_ON_ERROR( snd_pcm_hw_params_set_period_size_near(pcm, hw_params,
&period_size, &dir), MMSYSERR_INVALPARAM, "unable to set period time");
+if(buffer_size != buffer_size_old) ERR("buffer_size:%i
buffer_size_old:%i\n", (int)buffer_size, (int)buffer_size_old);
EXIT_ON_ERROR( snd_pcm_hw_params(pcm, hw_params), MMSYSERR_INVALPARAM,
"unable to set hw params for playback");
err = snd_pcm_hw_params_get_period_size(hw_params, &period_size, &dir);
-err = snd_pcm_hw_params_get_buffer_size(hw_params, &buffer_size);
snd_pcm_sw_params_current(pcm, sw_params);
EXIT_ON_ERROR( snd_pcm_sw_params_set_start_threshold(pcm, sw_params,
dwFlags & WAVE_DIRECTSOUND ? INT_MAX : 1 ), MMSYSERR_ERROR, "unable to set
start threshold");
Re: compiling wine for amd64
On Thursday, September 21, 2006 15:30, Gerald Britton wrote:
> Hi -- I'm running ubuntu dapper on amd64. I want to compile wine
> but am hitting problems. I got the dependencies just fine, but the
> compile died. Here's what I get:
>
> $ sudo apt-get -y --build source wine
> Reading package lists... Done
> Building dependency tree... Done
> Skipping the already downloaded file
> 'wine_0.9.21~winehq0~ubuntu~6.06-1.dsc' Skipping the already downloaded
> file
> 'wine_0.9.21~winehq0~ubuntu~6.06.orig.tar.gz'
> Skipping the already downloaded file
> 'wine_0.9.21~winehq0~ubuntu~6.06-1.diff.gz' Need to get 0B of source
> archives.
> Skipping unpack of already unpacked source in
> wine-0.9.21~winehq0~ubuntu~6.06 dpkg-buildpackage: source package is wine
> dpkg-buildpackage: source version is 0.9.21~winehq0~ubuntu~6.06-1
> dpkg-buildpackage: source changed by Scott Ritchie <[EMAIL PROTECTED]>
> dpkg-buildpackage: host architecture amd64
> debian/rules clean
> dh_testdir
> dh_testroot
> rm -f build-stamp
> # Add here commands to clean up after the build process.
> /usr/bin/make distclean
> make[1]: Entering directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06'
> make[1]: *** No rule to make target `distclean'. Stop.
> make[1]: Leaving directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06'
> make: [clean] Error 2 (ignored)
> #-/usr/bin/make -C documentation clean
> cp -f /usr/share/misc/config.sub config.sub
> cp -f /usr/share/misc/config.guess config.guess
> dh_clean
> debian/rules build
> dh_testdir
> # Add here commands to configure the package.
> CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu
> --build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking whether make sets $(MAKE)... yes
> checking for x86_64-linux-gnu-gcc... gcc -m32
> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
> See `config.log' for more details.
> make: *** [config.status] Error 77
> Build command 'cd wine-0.9.21~winehq0~ubuntu~6.06 && dpkg-buildpackage
> -b -uc' failed.
> E: Child process failed
>
>
> I attached the config.log. What must I do to complete the compiles?
You probably don't have any 32 bit emul libraries installed. See
http://wiki.winehq.org/WineOn64bit for more details.
- Neil
Re: ALSA implementation
Molle Bestefich wrote: James Courtier-Dutton wrote: I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate. alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib. What are the constraints? In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon. Seems to me that it would take less development resources to fix an existing resampling implementation with known restraints, than to code a new one. Also it would end up helping more people. If someone from the Wine community wants to fix the existing ALSA resampler, what needs to be done? As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling. What sound API is used on Mac OS X? Does that API require Wine to do resampling, or do things work OOTB there? The possible so called "fix" is still a long way off. It requires a lot of work. As there are only a few alsa developers, that means it will take a long time. We each have rather long TODO lists currently and would welcome any offer to help ALSA development. Resampling is not a simple problem to fix. The technically best solution is for the application to do the resampling before passing it to the sound card, so any effort to do it in the sound drivers is always going to be sub-optimal, with sound quality suffering. The current alsa method achieves resampling with minimal effort, but presents some constraints to the application. These "constraints" are only a problem for closed source applications. In order to reduce the "constraints" so that ALSA works better with wine will result in trade offs. I.e. better compatibility with binary only application, but increased sound latency due to the required extra double buffers. I will document the "constraints" when I get a moment. James
Re: WineD3D: glBlend* fixes
On 9/21/06, Roderick Colenbrander <[EMAIL PROTECTED]> wrote: Hi, This patch changes the detection extension detection for glBlendColor/glBlendEquation. The function glBlendColor is part of OpenGL 1.1 and is supported on all OpenGL implementations. Officially it is part of the GL_ARB_imaging extension but not all vendors fully implement it and that's why only Nvidia and 3dlabs advertise it. This causes glBlendColor not to work on other implementations. So in case of GL 1.1, the detection is dropped. Further glBlendEquation is part of GL_ARB_imaging aswell. For the same reason GL_ARB_imaging can't be used to detect glBlendEquation. This call isn't supported on all OpenGL implementations. Luckily it is part of 'GL_EXT_blend_min_max' so that is used now. Roderick, Mesa calls the extension "GL_EXT_blend_minmax", and so does the spec. I don't know what exactly uses the min_max form. Is this a typo? http://www.opengl.org/registry/specs/EXT/blend_minmax.txt http://www.google.com/search?hl=en&lr=&q=GL_EXT_blend_min_max&btnG=Search Also, the TRACE call in device.c:4513 needs a \n added too ;) Jesse
Re: Governance revisited (Wineconf report)
Andreas Mohr wrote: Why reinvent the wheel? If such people can spend their time chasing down the problem and developing a fix for it, they sure can open a bug in bugzilla, describe theproblem and attach a patch they made. How more simple can it be? No patches lost, no extra places to look for. And all the information describing the problem. Everything in one place. And exactly this information should probably be stated in the wine-patches subscription welcome mail. "If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied." The next question is how long does someone wait till resorting to Bugzilla. Depending on the criteria it could generate a fair bit of noise in the database with a lot of patches that would normally be accepted after a couple of goes. Who is responsible for clearing the bug report after acceptance? Unless you are actually actively pushing the patch for acceptance, the submitter of a patch to Bugzilla would probably be unaware that it had been accepted. Jeff Latimer
Re: Status of dlls that you maintain
Tom Wickline wrote: On 9/21/06, Jeff L <[EMAIL PROTECTED]> wrote: BTW, the WWN #292 looks to be out of date as those functions are now implemented. Hmm, Brian Vincent does the WWN and I just link the WWN articles to the status pages.. Tom Brian, I have successfully run Notes 7 on wine and the problems mentioned in WWN #292 have been fixed. Jeff Latimer
Re: [c2man] remove hardcoded extension (try#2)
On Wednesday 20 September 2006 15:25, Vijay Kiran Kamuju wrote: > Well then will this do good, if the file extension is 'spec', then we > will take the default value as 'dll'. > As the logic i am using to parse the filenames is, I am checking using > the first part of the extension. > Can you tell me a better method other than this? Maybe he meant for you to use the file contentes to determine what it is, not the file name. Say, assume that file names are random gibberish, and work from there. Cheers, Kuba
Re: ALSA implementation
Jan Zerebecki wrote: On Wed, Sep 20, 2006 at 05:55:03PM +0200, Marcus Meissner wrote: On Wed, Sep 20, 2006 at 05:54:06PM +0200, Tomas Carnecky wrote: Jan Zerebecki wrote: As explained in the mail refrenced above the main problem is that in wine the alsa callback signal (that we currently use) won't work properly without special care, but the fd based method (for example with select) should work as expected. Why won't it work without special care? Is it because of the SIGIO signal? Wouldn't the fd-method require a separate thread? It is because how (all) signals work and how wine works. The fd method may not require a separate thread when we can combine the event loop of the currently used sound thread with e.g. the select for the alsa-lib fd(s), thu I didn't look at that and it might not be possible. this looks very possible to me... and likely the cleanest solution in the event loop we only wait on a single item (the fd used for signaling a new event to be handled by the thread), so adding a poll on a second fd seems very feasible (alternative coding with win32 objects is also possible, though a bit more trickier, but this could be dropped IMO, as it's currently broken -> on event is lost if two are pushed before the playback thread gets a chance to get them)
Re: ATI and GL_ARB_Imaging support
This should indeed be changed. I quickly checked a GL extension database and it appears that mainly 3dlabs and Nvidia are advertising the extension. We could just drop the extension check as glBlendColor and friends are part of OpenGL 1.1 or move to GL_EXT_blend_color and friends. I think dropping the check is fine. I need to ask some others, if it is fine I'll post a patch for it. Roderick > Hi all, > > I noticed, that wine checks for GL_ARB_imaging, before performing > operations like glBlendColor, glBlendEquation etc. However it appears > that the ATI drivers do not support this extension, though they do > support the blending operations. > > I posted about this on the Rage3d linux driver boards, and the response > seems to suggest that it would be better to check for the individual > operations rather than the GL_ARB_imaging extension. > > See bottom of http://rage3d.com/board/showthread.php?t=33814685 > > What do you guys think? > > Kap. > > -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
ATI and GL_ARB_Imaging support
Hi all, I noticed, that wine checks for GL_ARB_imaging, before performing operations like glBlendColor, glBlendEquation etc. However it appears that the ATI drivers do not support this extension, though they do support the blending operations. I posted about this on the Rage3d linux driver boards, and the response seems to suggest that it would be better to check for the individual operations rather than the GL_ARB_imaging extension. See bottom of http://rage3d.com/board/showthread.php?t=33814685 What do you guys think? Kap.
compiling wine for amd64
Hi -- I'm running ubuntu dapper on amd64. I want to compile wine
but am hitting problems. I got the dependencies just fine, but the
compile died. Here's what I get:
$ sudo apt-get -y --build source wine
Reading package lists... Done
Building dependency tree... Done
Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06-1.dsc'
Skipping the already downloaded file
'wine_0.9.21~winehq0~ubuntu~6.06.orig.tar.gz'
Skipping the already downloaded file 'wine_0.9.21~winehq0~ubuntu~6.06-1.diff.gz'
Need to get 0B of source archives.
Skipping unpack of already unpacked source in wine-0.9.21~winehq0~ubuntu~6.06
dpkg-buildpackage: source package is wine
dpkg-buildpackage: source version is 0.9.21~winehq0~ubuntu~6.06-1
dpkg-buildpackage: source changed by Scott Ritchie <[EMAIL PROTECTED]>
dpkg-buildpackage: host architecture amd64
debian/rules clean
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
/usr/bin/make distclean
make[1]: Entering directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06'
make[1]: *** No rule to make target `distclean'. Stop.
make[1]: Leaving directory `/home/jerryb/wine-0.9.21~winehq0~ubuntu~6.06'
make: [clean] Error 2 (ignored)
#-/usr/bin/make -C documentation clean
cp -f /usr/share/misc/config.sub config.sub
cp -f /usr/share/misc/config.guess config.guess
dh_clean
debian/rules build
dh_testdir
# Add here commands to configure the package.
CFLAGS="-Wall -g -O2" ./configure --host=x86_64-linux-gnu
--build=x86_64-linux-gnu --prefix=/usr --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking whether make sets $(MAKE)... yes
checking for x86_64-linux-gnu-gcc... gcc -m32
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
make: *** [config.status] Error 77
Build command 'cd wine-0.9.21~winehq0~ubuntu~6.06 && dpkg-buildpackage
-b -uc' failed.
E: Child process failed
I attached the config.log. What must I do to complete the compiles?
config.log
Description: Binary data
Re: msi [6/7]: Translate the INSTALLSTATE_UNKNOWN index into the INSTALLSTATE_ABSENT image index
On 9/20/06, Juan Lang <[EMAIL PROTECTED]> wrote:
Hiya James,
-TRACE("Feature %s -> %d %d %d\n", debugstr_w(feature->Title),
+printf("Feature %s -> %d %d %d\n", debugstr_w(feature->Title),
I don't think you meant that to slip in.
Thanks for catching this Juan. I even said to myself, "Don't forget
to put the TRACE back"!
--
James Hawkins
Re: Text Layout Summit
Daniel Glassey wrote: It would be great if someone from wine and mono could be there. If that wouldn't be possible we would appreciate your input on what you would need. Daniel, your not entirely correct. We have some uniscribe support in wine and it is improving however a clearer architecture would be great. Jeff Latimer
Re: Governance revisited (Wineconf report)
Andreas Mohr wrote: > And exactly this information should probably be stated in the wine-patches > subscription welcome mail. > > "If for some reason the Wine patches you submit fail to get applied, > then we'd appreciate you taking the effort of submitting your current patch > as a new item at bugzilla to help us track your work properly until it's > fully applied." > > Or, for improved visibility, even state this in the footer of every > wine-patches mail > sent (probably bad idea, though). > > Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be > useful (after all it's quite common to have that site name, see e.g. > bugzilla.kernel.org or bugzilla.mozilla.org etc.). > This would be an excellent idea - it would simply highlight the fact that there is an alternative route to providing visibility for patches that are not accepted. I must admit I had always thought of bugzilla as a bug-reporting mechanism and I hadn't thought of using it in this manner: to open a bug specifically in order to present your own fix! John.
Re: gdi32: GetTextExtentPoint and GetTextExtentExPoint behavedifferently if there's a \n in the string.
On Thu, Sep 21, 2006 at 06:09:10PM +0900, Dmitry Timoshkov wrote: > I accidently left 2 tests in my comment, that may have been misleading. > Just to clarify things: an actual test which fails for me is the one in > the todo_wine block. Yup, I guessed that's what you meant. I've just sent a patch which removes that test. Thanks, Huw. -- Huw Davies [EMAIL PROTECTED]
Re: gdi32: GetTextExtentPoint and GetTextExtentExPoint behavedifferently if there's a \n in the string.
"Huw Davies" <[EMAIL PROTECTED]> wrote:
>+todo_wine {
>+/* The \n in the string is apparently handled differently in
>GetTextExtentPoint and GetTextExtentExPoint */
>+ok(sz1.cx != sz2.cx,
>+ "cx from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld)
>are the same\n", sz1.cx, sz2.cx);
>+ }
This test fails for me (i.e. sz1.cx == sz2.cx) under XP (SP2+all the latest
fixes).
Thanks, guess I'll just get rid of that test altogether then.
I accidently left 2 tests in my comment, that may have been misleading.
Just to clarify things: an actual test which fails for me is the one in
the todo_wine block.
--
Dmitry.
Re: gdi32: GetTextExtentPoint and GetTextExtentExPoint behavedifferently if there's a \n in the string.
On Thu, Sep 21, 2006 at 01:34:09PM +0900, Dmitry Timoshkov wrote:
> "Huw Davies" <[EMAIL PROTECTED]> wrote:
>
> >-ok(sz1.cx == sz2.cx && sz1.cy == sz2.cy,
> >- "results from GetTextExtentExPointW and GetTextExtentPointW
> >differ\n");
> >+ok(sz1.cy == sz2.cy,
> >+ "cy from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld)
> >differ\n", sz1.cy, sz2.cy);
> >+todo_wine {
> >+/* The \n in the string is apparently handled differently in
> >GetTextExtentPoint and GetTextExtentExPoint */
> >+ok(sz1.cx != sz2.cx,
> >+ "cx from GetTextExtentExPointW (%ld) and GetTextExtentPointW (%ld)
> >are the same\n", sz1.cx, sz2.cx);
> >+ }
>
> This test fails for me (i.e. sz1.cx == sz2.cx) under XP (SP2+all the latest
> fixes).
Thanks, guess I'll just get rid of that test altogether then.
Huw.
--
Huw Davies
[EMAIL PROTECTED]
Re: Governance revisited (Wineconf report)
Hi, On Wed, Sep 20, 2006 at 08:52:45PM -0600, Vitaliy Margolen wrote: > Dr J A Gow wrote: > > How to capture these 'lost' contributions is a difficult issue. Maybe a > > centralized repository for patches could be maintained separate from the > > main > > Wine tree and with a very loose method of acceptance (maybe just ensure > > that it > > is clearly indicated what the patch is for and what version it can be > > applied > > to). This way it would be very easy for a contributor to place a patch > > somewhere > > where it is easily accessed by the community. A developer with more time > > who is > > interested in it may pick it up and clean it up for inclusion in the tree, > > but > > at least the patch is available for others to use, saving re-invention of > > the wheel. > > > Why reinvent the wheel? If such people can spend their time chasing down the > problem > and developing a fix for it, they sure can open a bug in bugzilla, describe > theproblem > and attach a patch they made. How more simple can it be? > > No patches lost, no extra places to look for. And all the information > describing the > problem. Everything in one place. And exactly this information should probably be stated in the wine-patches subscription welcome mail. "If for some reason the Wine patches you submit fail to get applied, then we'd appreciate you taking the effort of submitting your current patch as a new item at bugzilla to help us track your work properly until it's fully applied." Or, for improved visibility, even state this in the footer of every wine-patches mail sent (probably bad idea, though). Oh, and a DNS alias (or preferrably forwarder) bugzilla.winehq.org might be useful (after all it's quite common to have that site name, see e.g. bugzilla.kernel.org or bugzilla.mozilla.org etc.). Andreas -- GNU/Linux. It's not the software that's free, it's you.
Re: ALSA implementation
James Courtier-Dutton wrote: I have not looked at the wine source code lately, but I would advise you that it would be sensible to talk to the sound card at only the 48000 Hz rate. alsa-lib does do resampling currently, but it has some importance constraints that I think are incompatible with wine. I would therefore recommend that wine does it's own resampling to 48kHz before passing sound to alsa-lib. What are the constraints? In time alsa will remove the resampling constraints present in alsa-lib, but that fix is not expected any time soon. Seems to me that it would take less development resources to fix an existing resampling implementation with known restraints, than to code a new one. Also it would end up helping more people. If someone from the Wine community wants to fix the existing ALSA resampler, what needs to be done? As most windows applications running on wine tend to use the 44.1kHz rate, that will cause problems with the current alsa-lib. So, if wine want windows games to work better with sound when using alsa-lib, I would recommend wine doing the resampling. What sound API is used on Mac OS X? Does that API require Wine to do resampling, or do things work OOTB there?
