Vitaliy Margolen schreef:
> Isn't this a bit premature? ALSA still does not support proper sound
> capture, working mixer, and not stable enough on some configurations.
Mixer works properly, as you saw for yourself. Only thing that is
different is just that the alsa accelerated capture code is new
Dj Apal [GR] schreef:
>
> OK changed the copyright and added the diff file for the rsrc.rc file
> so as to be included.
>
> Thnx for noticing that!
>
> I think that we are OK now. Sorry for all this mess but it was my
> first time posting a patch!
Just curious, are files supposed to have dos line t
Hi Tomas,
Tomas Carnecky schreef:
> Is alloca() not allowed in wine? (asking because you allocate hw_params
> on the stack, but it's freed if the function exits, so it's only used
> inside this one function).
>
Last time I tried using alloca in alsa volume control it was rejected,
so I'm just w
Roderick Colenbrander schreef:
> On Thursday 16 August 2007 12:06, Maarten Lankhorst wrote:
>
>> Makes it cross-compilable to produce a windows binary.
>>
> I don't think this is the right way. It appears that native dxguid doesn't
> define some
Juan Lang schreef:
> Could some of you check where you have, say, OpenSSL's CA certificates
> installed, and email me what distro you're running, and the path?
>
> E.g., I'm running Goobuntu, and I have them installed in
> /etc/ssl/certs/ca-certificates.crt.
>
> Thanks,
> --Juan
>
Seems same for
Scott Ritchie schreef:
> The Wine package in Ubuntu Gutsy is currently failing to build on the
> AMD 64 arch, and I'm not sure why. I don't have a gutsy 64 system to
> play around with at the moment, but you can see the package error log
> here:
>
> http://launchpadlibrarian.net/8598218/buildlog_u
Luis C. Busquets Pérez schreef:
> File that just forwards one function included for compatibility issues
Hi,
I think you're missing a few files here, are you sure you've added the
files from dlls/dpnlobby?
Cheers,
Maarten
As I don't have that game, can you e-mail me a WINEDEBUG=+wave,+dsound
log? The problem is probably somewhere else then. There should probably
be a small performance hit, but nothing to the extent that currently
happens.
>From 7593fcf19ba306d0024048e7a49e87b7c8d5c318 Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst <[EMAIL PROTECTED]>
Date: Thu, 5 Jul 2007 00:41:59 +0200
Subject: [PATCH] winealsa: Increase performance of wavein getposition
---
dlls/winealsa.drv/wavein.c | 12 +++-
1 files changed, 3 in
2007/7/4, Robert Reif <[EMAIL PROTECTED]>:
This patch:
http://www.winehq.org/pipermail/wine-patches/2007-June/039942.html
causes RightMark3DSound.exe
(http://audio.rightmark.org/products/rm3ds.shtml) to crash.
It appears that the code always expects a property set interface to
succeed and
crashe
I would rather have that it's only reported in case of period size =
1024 (default dmix) and as a WARN that says 'use 512' instead, since
dmix apparantly doesn't always work well with 256 after all on my
other pc.
Maarten
[EMAIL PROTECTED] schreef:
> This page has been dead since October 1.
>
> Since I'm not producing code for the Wine project, this is an area I'd like to
> contribute to. (I'm already taking screenshots of the API status page to see
> what happens from release to release :))
>
> Is there some WineHQ
Chris Rankin schreef:
> Hi,
>
> This patch has killed the sound on World of Warcraft. Instead, I now get
> silence and a stream of
> errors like this:
>
Don't #if 0 out the code there
Change it to something like this:
if (pmix > This->buflen)
WARN("Mixing further ahead then buffer is long\n")
That fix is correct, This->pcm is only ever changed inside the critical
section
Thanks,
Maarten
2007/6/22, Michael Stefaniuc <[EMAIL PROTECTED]>:
> Maarten,
>
> is this the right fix or can the lock be moved below the
> if (!This->pcm)
> check?
>
> bye
> michael
> ---
> dlls/wineals
Alex Villacís Lasso schreef:
> I am experiencing a failing assertion in a dsound test. Could you
> please confirm if it is just me (and then it would be a configuration
> issue), or if anybody else is experiencing failing assertions:
Confirmed, I' ll take a closer look at it.
Maarten
Hello,
After retrying, I tried the same function arguments that msn messenger
7.5 passes to advapi32. It seems that function _is_ allowed to define
the flags CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT at the same time.
I tried the same flags for advapi32 crosstest 'crypt' in linux and windows.
Linu
John Klehm schreef:
> Hey Maarten and all,
>
> Good idea about publishing the changes. I was thinking to use
> Google's project hosting thing for mine I think it supports SVN or
> something though. Guess I can try and figure out a git feed on a
> different server too, we'll see.
Git is the reposi
For all other students joining SummerOfCode, I think it's a good idea if
we have a public place where we can see each other's changes.
I set up my own fork, sound.git at http://repo.or.cz/w/wine.git - if
others want to do the same I encourage them to do so, it's easy when you
figure out how to git
Mounir IDRASSI schreef:
> Hi,
> Your patch is wrong: the flags CRYPT_NEWKEYSET and CRYPT_VERIFYCONTEXT
> can't be mixed and if they are set together like in your patch
> AcquireContext should return NTE_BAD_FLAGS. You can check that using the
> MS implementation under windows. It's also clearly sta
Marcus Meissner schreef:
> It is likely ATI or NVIDIA.
> But yes, a broken graphics driver can cause user apps to deadlock the
> machine.
>
> Ciao, Marcus
Most likely, I get hard locks too when closing a d3d app by using
control c, and my system hangs if I kill a wine process with xkill, both
than
EA Durbin schreef:
> I'm having problems regression testing between 0.9.15 and 0.9.37. On
> 3+ bisects I keep getting the following error and wine won't compile.
Most of the time when this happens you forget to do a make distclean
first. It is recommended to use ccache and do a 'make distclean' ev
back to a win32 implementation.
What are your thoughts on this?
Maarten
fevent patch attached.
>From 5e5cb0a326f51dc2edef245fcaab4a071f9e0c42 Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst <[EMAIL PROTECTED]>
Date: Sat, 12 May 2007 15:19:45 +0200
Subject: [PATCH] wine headers: in
"Emmanuel Maillard" <[EMAIL PROTECTED]> wrote:
> Changelog :
> - inital Mixer support on Mac OS X
> - find all lines and initialize controls
Looking through it you seemed to have used OSS as base, which means some
of the comments on my earlier code also apply to your code:
- 64 bits safety (use DW
Mounir IDRASSI schreef:
> We have found few bugs in the MS Enhanced CSP implementation in wine
> (rsaenh.dll) and you'll find attached a patch that corrects them.
Hello Mounir,
Bug fixes are always welcome in wine.
But fixing bugs is one thing, but it is also very recommended to add
tests to verif
Steven Edwards schreef:
> Hi,
>
> Even though backward compatibility is kept I worry about a couple of
> things. A lot of work was done on WinMM to make it portable to windows
> for testing and I don't like seeing new code to tie it back to unix
> even with the old code left in place. Also shouldn'
Jonathan Schleifer schreef:
> Maarten Lankhorst <[EMAIL PROTECTED]> wrote:
>
>> Wine could build fine without c++, not sure why everything has to
>> link against the c++ library as it will probably only be needed in
>> winegcc. Also these compiling flags seem kind
Jonathan Schleifer schreef:
> Hi!
>
> This patch makes it possible to build an run wine with the Intel
> compiler.
>
> Here are the environment variables I used to build:
>
> export CFLAGS="-O3 -xP -msse3 -parallel"
> export CXX="icc"
> export CXXFLAGS="-O3 -xP -msse3 -parallel"
> export LDFLAGS="-
Peter Beutner schreef:
> ok that makes sense. Definitely something wrong in dsound.
>
> But I still think that ALSA_DestroyRingMessage should signal any message left
> in the queue. Imo it just calls for trouble to expect that messages always
> are added in the right order.
DestroyRingMessage is ca
Peter Beutner schreef:
> AFAIK you get the DRVM_EXIT message only when winmm is unloading.
> Alternatively you could do it in response to the DRV_CLOSE message which winmm
> sends just before it tries to unload the driver.
>
> That said I don't see how your code in ALSA_MixerExit() could deadlock.
Peter Beutner schreef:
> But this only works if DSOUND_Stop and DSOUND_Release are called from
> different threads, right?
It is during shutdown, DSOUND has an internal timer/thread called the
mixer, it calls DSOUND_Stop because we signalled it to stop playbacking,
then the program calls idirectsou
Kai Blin schreef:
> I'm not really surprised. That's the reason why gethostbyname is deprecated,
> if I read MSDN correctly. Anyhow, it looks like Windows doesn't return
> 127.0.0.1 unless it doesn't have any other IP address to return. Programs
> can't count on which NIC's IP that will be, tho
After trying to implement the alsa mixer I came across a problem: If
winmm is unloading, a deadlock could occur if during unloading it's
waiting for another thread.
In winmm itself this isn't much of a problem: there aren't any threads.
However, the drivers used by winmm may have threads, and if
2007/4/14, Martin Owens <[EMAIL PROTECTED]>:
but we have a flash 9 player...
At the time of the survey there wasn't a sign of it. I remember that,
flash player has been only added recently. Flash 7.0 was horrible
Maarten
Christoph Frick schreef:
> why do you compile the drivers in - or why do have the files around for
> them? my audio dialog just shows oss and alsa; the others get dropped at
> compile time. also there might be other platforms that have to use those
> audio drivers - why drop something that works?
I
There are 5 different audio drivers for linux, I think this is a bit
overkill, so I propose to remove the esd and nas drivers, I don't think
anyone uses esd, especially that since for that task alsa can be used
now since dmix addon.
I'm not sure what nas is for, but it seems to be 'network audio s
Dmitry Timoshkov schreef:
> "Maarten Lankhorst" <[EMAIL PROTECTED]> wrote:
>
>> +/**
>>
>> + *mxdMessage (WINEALSA.3)
>> + */
>> +DWORD WINAPI
Philip A. Marshall schreef:
> For what it's worth, I added the Edgy wine repository and used the Edgy
> packages for wine 0.9.34 under Feisty. It seems to work, so I'll
> probably use the Edgy repository until the Feisty repository starts up.
>
I did the same, it doesn't seem to mind, only diff
EA Durbin schreef:
> Why do the patches I send to wine-patches never show up in the list?
> Are they being received?
Try subscribing to the wine-patches mailing list, if you're only
interested in sending patches you can turn off receiving messages from
that list.
Tom Spear schreef:
> I just downloaded and configured wine 0.9.34 and looking thru the
> config.log (didnt do this on prior versions, so I'm pretty sure it's
> not a regression), there is a warning about needing to use
> alsa/asoundlib.h instead of sys/asoundlib.h .. I made bug 7997 about
> it: ht
Kai Blin schreef:
> Hi folks,
>
> Tim asked me about this on IRC today, and I didn't have any good idea about
> it, so I'll just forward it to you people.
>
> Cheers,
> Kai
>
>
>
>
> Onderwerp:
> "Out of Tree" DLLs
> Van:
Kai Blin schreef:
> On Tuesday 13 March 2007 08:29, Dan Kegel wrote:
>
>> I'm looking for active Wine developers to act
>> as mentors for Google Summer of Code 2007.
>> If you're interested, please let me know quickly;
>> the list has to be finalized in the next half-day
>> or so. (Sorry for th
For the summer of code I'm planning to improve the dsound code and alsa
code, to make alsa finally better then OSS, in a way that has a will get
accepted into the wine tree, for that I'm thinking of improving on the
following fronts:
Winealsa:
- Add mixer device and aux controls
- Implement dsound
Adam Petaccia schreef:
> This patch makes the Guild Wars show up in all its glory.
Did I miss something shaped like a patch?
nmm/winealsa/audio.c
+++ b/dlls/winmm/winealsa/audio.c
@@ -6,6 +6,7 @@
* Copyright2002 Eric Pouech
* 2002 Marco Pietrobono
* 2003 Christian Costa : WaveIn support
+ * 2006 Maarten Lankhorst
*
* This library is free software; you can redistribute it
copy the code
1:1 from the LGPL alsa sound library. However I saw no need for it and
to keep the code simple I just used snd_pcm_wait.
See alsa-lib/src/pcm/pcm.c for how snd_pcm_wait is implemented: It
just uses poll()
Maarten Lankhorst a écrit :
> Instead of using asynchronous callbacks that uses s
This changes the winealsa dsound driver to stop using asynchronous
callbacks and use snd_pcm_wait instead, I'm welcoming testing.
For me this fixes the mmap_crst deadlock. I don't know what caused the
deadlock in the first place, but this seems to have fixed it somehow.
My test was basically runn
Sven Paschukat schreef:
Maarten Lankhorst schrieb:
Windows seems to set internet explorer only during a new installation
or upgrade of internet explorer, so I put it in wine.inf, which
seemed appropriate.
Changelog:
Set version strings for Internet Explorer so programs dependent on it
can
2006/6/28, Dmitry Timoshkov <[EMAIL PROTECTED]>:
"Maarten Lankhorst" <[EMAIL PROTECTED]> wrote:
> +static HINSTANCE ghInst = NULL;
> +
> +BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
> +{
> + TRACE("(0x%p, %ld
Fix AlphaBlend() to extract the right part of the source DIB.
(http://www.winehq.com/hypermail/wine-patches/2005/08/0331.html)
After some regression testing, It looks like this patch is the one
that breaks signing into msn messenger. I m not sure why, so Im
interested in finding out why it happens
To suppress warnings from my thiscall wrapped stuff, I came up with this
solution, playing around a little with #define's:
#ifdef __i386__ /* thiscall functions are i386-specific */
#ifdef __GNUC__
/* GCC erroneously warns that the newly wrapped function
* isn't used, lets help it out of it's t
#x27;s I already
have and set attribute 'used' to avoid compiler warnings. But I still
wonder what I have to do to call a 'thiscall' function, since I probably
need it in ITextHost.
Maarten Lankhorst
I have been trying to get some work done on a class returned by
CreateTextServices, but the differences between windows' stdcall and
linux' are giving me a few headaches. right now I've done it pretty much
like this:
/* These macros are taken from wine/dlls/msvcrt/cpp.c */
#ifdef __i386__ /* this
Krzysztof Foltman schreef:
Maarten Lankhorst wrote:
Ah ok, it would have been a nice project for summer of code,
unfortunately i never applied for it, else I'd try to get it working..
Yes, that's a potentially nice "sponsorable" project.
as far as i can tell onl
Krzysztof Foltman wrote:
Maarten Lankhorst wrote:
I'll try playing around a bit with CreateTextServices and see how far I
will come, it seems to be tricky, I can't find any useful information
about it.
My opinion - forget it. It'd require a major rework of the RICHEDIT2
MSN Messenger 6.2 (!!) seems to run fairly well with only builtin dll's,
from what I can tell the only real thing missing is CreateTextServices
in riched20.dll, SSL support and urlmon's obtainuseragent (or
something), webcams will work without any additional native dll now, if
my patch for msvfw32
Hi Alexandre,
I implemented a driver model in qcap now, but avicap32 still uses my old
#ifdef LINUX_VIDEODEV_H, since some people might be interested in
writing capcreatecapturewindow, I think we should move out the drivers
from qcap to our own vfwwine dll/driver, windows uses a similar model
Dimi Paun wrote:
On Fri, 2005-05-20 at 12:26 +0200, Maarten Lankhorst wrote:
What do you suggest then ... fprintf(stderr?
Absolutely not. :) But there are other options available:
TRACE/WARN/FIXME. There's also MESSAGE, but it should be
used *very* little. Also remember that most p
Dimi Paun wrote:
On Fri, 2005-05-20 at 00:42 +0200, Maarten Lankhorst wrote:
m3h, v4l driver for vfwcapture.. please leave the ERR notice on
initialisation intact, thank you :)
I think you've overusing ERR(). ERR() should be called
to signal an internal error such as inconsistent
MediaHost (TM) wrote:
Looks interesting! Any idea, when your patches get committed into the
"official" releases?
Maarten Lankhorst wrote:
Status: Nearly complete, need testers.
http://wiki.winehq.org/MSN_Messenger_webcam_support
You need the native quartz dll, which get installed wit
Status: Nearly complete, need testers.
http://wiki.winehq.org/MSN_Messenger_webcam_support
You need the native quartz dll, which get installed with internet
explorer, as the builtin quartz doesn't work properly when changing
media format on initialisation. IFilterGraph Reconnect isn't
implemente
James Hawkins wrote:
On 5/14/05, Maarten Lankhorst <[EMAIL PROTECTED]> wrote:
We are not windows, using HKLM/SYSTEM/.../msvideo would not be an option imho,
because when should we write it? And what if you just connected your webcam and
modprobe'd the drivers for it, it would make
he rest of the stuff I worked upon until now was well documented, but I
doubt winmm is...
Maarten Lankhorst
this is my qcap dll in its current state, because i dont have much time
in the next couple of weeks I' d thought I'd post it, perhaps someone
can make it work with the new qcap dll implementation, what i have here
is a pretty much complete version of qcap + a near complete version of
V4l implem
Robert Shearman wrote:
Maarten Lankhorst wrote:
I want to copy from a raw bitmap stream which is (capBox->width) x
(capBox->height) (24 bits) to (capBox->outputwidth) x
(capBox->outputheight) (also 24 bits), if you can argue about
HAVE_V4L2 this should be easy :) I *really* need thi
static void Resize(CaptureBox * capBox, LPBYTE output, LPBYTE input)
{
if (!capBox->swresize) {
int depth = capBox->bitDepth / 8;
int inoffset = 0, outoffset = (capBox->height-1) * capBox->width *
depth;
int ow = capBox->width * depth;
while (outoffset >= 0) {
int x;
James Hawkins wrote:
On 5/5/05, Maarten Lankhorst <[EMAIL PROTECTED]> wrote:
HAVE_V4L2 is not declared in wine itself, but by
/usr/include/linux/videodev.h, which includes videodev2.h and defines
HAVE_V4L2 if V4L2 is available, so in my opinion it doesn't need fixing..
Maybe
Francois Gouget wrote:
Maarten, could you fix the following winapi_check warnings:
dlls/avicap32/avicap32_main.c: HAVE_V4L2 is not declared as a conditional
dlls/avicap32/avicap32_main.c: HAVE_V4L2 is not declared as a conditional
The problem is that dlls/avicap32/avicap32_main.c checks for HAVE_V4
Robert Shearman wrote:
Maarten Lankhorst wrote:
This patch fixes AM_MEDIA_TYPE->pbFormat not being handled correctly,
unfortunately, this also means some stuff has to be rewritten to
avoid memleaks, instead of CoTaskMemFree(AM_MEDIA_TYPE),
DeleteMediaType has to be used.. This also fixes
I am stuck on it, it seems that if I enable WINEDEBUG=+quartz it crashes
THEORETICALLY, although wrong, this should be ok, since it doesn't
disrupt anything
BUT I asked others to test my patch, and unfortunately THEY weren't that
lucky, it crashed, wether winedebug was enabled or not...
so what
I'm trying to resize a raw image (only rgb values) and flipping it
vertically
i got 2 pointers, and the size
they are both rgb24
I wanted to do this with stretchdibits, but it requires a device
context, and I am not sure that if i create one with createcompatibledc,
it will be 24 bits.. so my q
just thought I'd drop by and say how things are going..
i submitted a lot of patches already, and trying to get those commited,
although they are not directly required for webcam support, they are
meant to increase general stability, and fix some bugs:
- dlls/avicap32: wrote a basic capgetdriver
Juan Lang wrote:
Hi Maarten,
You need to include "winnls.h" unconditionally, capGetDriverDescriptionW
is always compiled with calls to MultiByteToWideChar.
Oops, didn't see it, my fault -- fixed
+ sprintf(device, "/dev/video%i", devnum);
Why not use snprintf(device, sizeof(device) ...) in
Added critical section around the mediacontrols, also added a release
for the attached filters when the filtergraph gets released, so ref
count leak has decreased.. I also submitted a patch to devenum to fix
another release error, as a matter of fact:
fixme:quartz:ReadThread 0x7d331c20 -> Frame
ink = (239-heightidx)*320*3+width*3;
+int p0ink2 = width*4+heightidx*320*4;
+myData[p0ink + 2] = readbuffer[p0ink2 + 1];
+myData[p0ink + 1] = readbuffer[p0ink2 + 2];
+myData[p0ink + 0] = readbuffer[p0ink2 + 3];
+ }
+ heightidx++;
+ }
+
pbiIn)
{
diff -Nru wine-old/dlls/quartz/capture.c wine-new/dlls/quartz/capture.c
--- wine-old/dlls/quartz/capture.c 1970-01-01 01:00:00.0 +0100
+++ wine-new/dlls/quartz/capture.c 2005-04-17 17:32:58.00000 +0200
@@ -0,0 +1,166 @@
+/* DirectShow capture services (QUARTZ.DLL)
+ *
+ *
Robert Shearman wrote:
Maarten Lankhorst wrote:
I'm having troubles sending a media sample over the graph,
I'm wondering wether that is because of the receiving filter or my
own fault.
the thing I'm trying to send is a uncompressed 24 bit image, the
bitmap info header data of it
I'm having troubles sending a media sample over the graph,
I'm wondering wether that is because of the receiving filter or my own
fault.
the thing I'm trying to send is a uncompressed 24 bit image, the bitmap
info header data of it is pretty much as this:
mediatype: BI_RGB24
Width: 320
Height:
Robert Shearman wrote:
Maarten Lankhorst wrote:
HRESULT Capture_Run(CaptureBox * capBox, FILTER_STATE *state)
{
HRESULT hr;
IMediaSample *pSample = NULL;
LPBYTE pointer;
hr = OutputPin_GetDeliveryBuffer((OutputPin *)capBox->pOut,
&pSample, NULL, NULL, 0);
TRACE("Meat 1: %lx
I'm trying to figure out how to do this, but I can't find anything on
the subject.
From what I can tell, you have to make a media sample, then use
outputpin_sendsample to deliver it,
so, how do I fill up a media sample with a single frame?
For now, just with NULL data would be sufficient..
401 - 479 of 479 matches
Mail list logo
