wine-devel February 2011

wine-devel@winehq.org

92 participants
246 discussions

CD handling on MacOS - the big picture?
by Joerg-Cyril.Hoehle＠t-systems.com 11 Feb '11

11 Feb '11

Hi, the last years have seen individual patches by K. Thomases and C. Davis to Mac OSX' CD handling, but I don't see the big picture. Mixed CDs occur in some games, but some audio CDs contain "bonus content" as well. On MacOS, mixed CDs are mounted as two volumes - the audio part, - the data/binary section not unlike Gnome which also displays 2 disc icons on the desktop. On Linux, Wine manages to map both to a single CD-ROM drive letter like D:, such that - D:\data\foo.exe works as well as - MCICDA: open D: type cdaudio alias D; play D work (but see bug 20555), which mimics native's behaviour. On MacOS, we're not there yet. I've no idea how that can be made to work. How would Wine on MacOS join the pieces? Regards, Jörg Höhle

2 1

Re: [PATCH 01/13] dsound: New sample rate converter core functions.
by Krzysztof Nikiel 11 Feb '11

11 Feb '11

2011/2/11 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > Krzysztof Nikiel <knik00(a)gmail.com> wrote: > >> > You can't send Makefile changes separately from added/removed >> > files, a patch should not add dead code. >> >> Could you explain "dead code", all 13 parts need to be applied, >> otherwise the code will be broken. > > Wine should compile and be able to pass 'make test' after each separate patch. > You can't add for instance dlls/dsound/resample.c in one patch, and add it to > Makefile or use interfaces provided by it in some later patches. Every patch > should be finished and self-containing. Well, previous version of this patch was rejected as "needs splitting", it's basically too big to be send as a single patch. It can be applied as several smaller chunks or rejected as a whole. I don't think there is any other option.

3 4

Re: [PATCH 01/13] dsound: New sample rate converter core functions. (resend)
by Vitaliy Margolen 11 Feb '11

11 Feb '11

Nice job! If it will make Wine's sound better - it would be awesome. Haven't read the entire patch series. But few nit picks so far. On 02/11/2011 04:34 AM, Krzysztof Nikiel wrote: > +typedef double sample_t; > > +static inline sample_t getsample(LPBYTE buf, INT bps) > +{ > + tmp = ((sample_t) (*((BYTE *) buf)) - 128.0); No need to type cast. "buf" already a pointer to the BYTE. You can use it directly as *buf or buf[0], which is even more readable. > +static inline void putsample(LPBYTE buf, INT bps, sample_t smp) > + CLIPSAMPLE(smp, (double) 0x7fff); Typecasts are bad, especially that the type of "smp" is not "double". Please use "32767.0" instead. > + DOUBLE amp[3]; Mixing types again. If you defined your own type then please use it. Or make everything the same type whichever it is. > [PATCH 02/13] dsound: Resample filter table generator. (resend) Don't think compiler helpers should be going into dll directories. The more correct place is tools. But it's up to AJ. And as others noted, your patch series is not split correctly. Each patch will break Wine tree until the very last one. This is against the patch requirements that code tree should compile after every commit. You can put your compile helper with it's make file first. Then add your resampling code with a make file changes to compile it. But not use it yet (it does break another rule for adding dead code, but that's the only way you can split the entire series). After that make use of your new resampler, removing all conflicting code, so Wine will work. Last commit can be a cleanup for all remaining pieces that are no longer used. Vitaliy.

2 1

Testmail
by Detlef Riekenberg 11 Feb '11

11 Feb '11

Hi Just a test, as my patches do not show up in the mail archive. Detlef ___________________________________________________________ WEB.DE DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt mit gratis Handy-Flat! http://produkte.web.de/go/DSL_Doppel_Flatrate/2

1 0

Re: [PATCH] dsound: More accurate volume calculation.
by Vitaliy Margolen 11 Feb '11

11 Feb '11

On 02/11/2011 02:38 AM, Krzysztof Nikiel wrote: > I have changed this when creating the new resampler patch but it's not > really related to the main patchset. The patch is wrapped. Please send it as attachment. Also please no HTML when sending patches. Vitaliy

2 1

Re: msxml3: Ignore IActiveScript interface for IXMLHTTPRequest
by Nikolay Sivov 11 Feb '11

11 Feb '11

On 2/11/2011 10:51, Alistair Leslie-Hughes wrote: > Hi, > > > Changelog: > msxml3: Ignore IActiveScript interface for IXMLHTTPRequest What's a purpose of this? > > > Best Regards > Alistair Leslie-Hughes

3 6

Re: [PATCH 01/13] dsound: New sample rate converter core functions. (resend)
by Owen Rudge 11 Feb '11

11 Feb '11

> It looks like it may be too big to be accepted. Anyway, I will try to > resend it with 4 space indent for new files. > Hopefully these patches won't get wrapped this time. Your patches still appear to be being wrapped by your mail client. Try sending them as an attachment instead of inline (i.e., use the --attach parameter to git format-patch). -- Owen Rudge http://www.owenrudge.net/

1 0

Re: [PATCH 01/13] dsound: New sample rate converter core functions.
by Dmitry Timoshkov 11 Feb '11

11 Feb '11

Krzysztof Nikiel <knik00(a)gmail.com> wrote: > High quality sample rate converter. > New code seems simplier and faster despite the big sound quality > improvement. > > This patchset only makes sense when applying all 13 parts. It looks like at least some patches got wrapped by your mailer. You can't send Makefile changes separately from added/removed files, a patch should not add dead code. Could you use 4 space indetation for the new code please? -- Dmitry.

1 0

winspool.drv : Implement AbortPrinter() function
by Loïc Maury 11 Feb '11

11 Feb '11

1 0

Re: avifil32: Skip tests when we couldn't create or open the AVI file
by GOUJON Alexandre 11 Feb '11

11 Feb '11

On 01/30/2011 07:29 PM, Alexandre Goujon wrote: > --- > dlls/avifil32/tests/api.c | 12 ++++++++++++ > 1 files changed, 12 insertions(+), 0 deletions(-) > > diff --git a/dlls/avifil32/tests/api.c b/dlls/avifil32/tests/api.c > index 14ad4b4..c1ba878 100644 > --- a/dlls/avifil32/tests/api.c > +++ b/dlls/avifil32/tests/api.c > @@ -338,6 +338,12 @@ static void create_avi_file(const COMMON_AVI_HEADERS *cah, char *filename) > > ok(hFile != INVALID_HANDLE_VALUE, "Couldn't create file\n"); > > + if(hFile == INVALID_HANDLE_VALUE) > + { > + win_skip("Could not create the AVI file\n"); > + return; > + } > + > WriteFile(hFile,&cah->fh, sizeof(deffh),&written, NULL); > WriteFile(hFile,&cah->mah, sizeof(MainAVIHeader),&written, NULL); > WriteFile(hFile, streamlist, sizeof(streamlist),&written, NULL); > @@ -380,6 +386,12 @@ static void test_default_data(void) > ok(res != REGDB_E_CLASSNOTREG, "Unable to open file: error5=%u\n", REGDB_E_CLASSNOTREG); > ok(res == 0, "Unable to open file: error=%u\n", res); > > + if(res != 0) > + { > + win_skip("Could not open the file.\n"); > + return; > + } > + > res = AVIFileGetStream(pFile,&pStream0, 0, 0); > ok(res == 0, "Unable to open video stream: error=%u\n", res); I know I sent this patch about two weeks ago but I thought it was pending because of the 1.3.13 release. So, does anyone has an idea how to make this patch applied in the current tree ? The context is that we don't fail when we couldn't create or open the AVI file. (I think the title of the patch is explicit) Thus, we call "WriteFile(hFile" in the first part of the test even if hFile == INVALID_HANDLE_VALUE. In the second part, we call "AVIFileGetStream(pFile" even if "AVIFileOpen(&pFile" failed. I can also resend this appending [resent]. Just let me know what to do. Thanks !

3 3

← Newer
1
...
14
15
16
17
18
19
20
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel February 2011