June 2012 - Wine-Devel - list.winehq.org

Re: [PATCH] winepulse.drv: Add PulseAudio driver

by Chris Robinson

On Friday, June 15, 2012 3:39:33 PM Andrew Eikum wrote: > One thing to note is that PulseAudio has an absurdly high default > latency (two seconds), and due to its poor API there's no (easy) way > for us to control it. The latency is likely caused by PulseAudio setting a much larger tlength (and minreq) than what you asked for. This happens all the time for me when the server has been running. The trick I've found to dealing with this in OpenAL Soft is to essentially ignore what PulseAudio sets and do your free space calculations so that only the size of the buffer you requested is used. Something like: size_t writable_size(pulse_data *data) { uint buffer_size = our requested buffer size in bytes; uint update_size = our expected period size in bytes; /* This is signed since it could come out negative */ ssize_t len; pa_threaded_mainloop_lock(data->loop); len = pa_stream_writable_size(data->stream) - data->attr.tlength + buffer_size; pa_threaded_mainloop_unlock(data->loop); if(len < 0) return 0; len -= len%update_size; return len; } The update_size is only relevant if mmdevapi updates in period-sized chunks. If it doesn't, you can just remove it and the rounding. The tlength should be kept updated using pa_stream_set_buffer_attr_callback, in case the server tries to increase it more during runtime. When creating the stream, I set minreq to the period size, and tlength to the requested buffer size. I also set the flags PA_STREAM_INTERPOLATE_TIMING, PA_STREAM_AUTO_TIMING_UPDATE, and PA_STREAM_ADJUST_LATENCY. The most important part is to not rely on PA_STREAM_EARLY_REQUESTS or the write callback to tell you when some space is free for writing, since as noted above, PulseAudio can set unreasonably large values. This doesn't completely fix the latency problem, as I'll still get better performance using ALSA's dmix, but it helps immensely.

June 16, 2012

Re: MSVCP60.dll

by Matijn Woudt

On Fri, Jun 15, 2012 at 11:59 PM, John Emmas <johne53(a)tiscali.co.uk> wrote: > > On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote: > >> Hello John! >> >> On 06/15/2012 06:22 AM, John Emmas wrote: >>> Firstly, I'm not a Linux user. I'm a Windows programmer but I have a >>> passing knowledge of Linux (and several friends who are Linux >>> programmers). I write a Windows application which gets launched as a >>> child process by a popular Linux DAW. My program was first written many >>> years ago when the (then) current version of Wine was about v0.9.58. >>> Over a hundred people are using my program with old versions of Wine and >>> I've had no complaints so far. >>> >>> Recently however, two customers tried to use it with Wine v1.5.35. In >>> both cases the program crashed - apparently because some particular >>> function wasn't found in MSVCP60.dll (at the moment, we don't know which >>> function). Both customers went to a web site called WineTricks from >> That is fairly trivial to figure out. Start your app with Wine on the >> command line and it will crash with an exception: >> Call from <address> to unimplemented function MSVCP60.<function> >> >> Once you have those please open a bug on http://bugs.winehq.org/ for >> them. >> > > Thanks for the suggestion Michael, > > I'm still trying to track this down with my 2 customers but one of them told me something very interesting this afternoon. It seems that the more recent versions of Wine have 2 distinct modes:- a 'native' mode (which he thinks uses genuine Microsoft DLLs) and some other mode which uses what he called 'fake' DLLs. The native mode seems to be working. It's the other mode that crashes. I need to check if that's the same with the second customer but in the meantime, can anyone confirm if these two modes do co-exist these days? It's very different from my older Wine which used only Microsoft DLLs AFAIK. I should have some better info next week. > > John > You can set this for each dll (in winecfg for example), it's not a some kind of mode. Have a look at the wiki for winecfg [1]. - Matijn [1] http://wiki.winehq.org/winecfg

June 15, 2012

Re: MSVCP60.dll

by John Emmas

On 15 Jun 2012, at 10:41, Michael Stefaniuc wrote: > Hello John! > > On 06/15/2012 06:22 AM, John Emmas wrote: >> Firstly, I'm not a Linux user. I'm a Windows programmer but I have a >> passing knowledge of Linux (and several friends who are Linux >> programmers). I write a Windows application which gets launched as a >> child process by a popular Linux DAW. My program was first written many >> years ago when the (then) current version of Wine was about v0.9.58. >> Over a hundred people are using my program with old versions of Wine and >> I've had no complaints so far. >> >> Recently however, two customers tried to use it with Wine v1.5.35. In >> both cases the program crashed - apparently because some particular >> function wasn't found in MSVCP60.dll (at the moment, we don't know which >> function). Both customers went to a web site called WineTricks from > That is fairly trivial to figure out. Start your app with Wine on the > command line and it will crash with an exception: > Call from <address> to unimplemented function MSVCP60.<function> > > Once you have those please open a bug on http://bugs.winehq.org/ for > them. > Thanks for the suggestion Michael, I'm still trying to track this down with my 2 customers but one of them told me something very interesting this afternoon. It seems that the more recent versions of Wine have 2 distinct modes:- a 'native' mode (which he thinks uses genuine Microsoft DLLs) and some other mode which uses what he called 'fake' DLLs. The native mode seems to be working. It's the other mode that crashes. I need to check if that's the same with the second customer but in the meantime, can anyone confirm if these two modes do co-exist these days? It's very different from my older Wine which used only Microsoft DLLs AFAIK. I should have some better info next week. John

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by David Laight

On Fri, Jun 15, 2012 at 07:52:50PM +0200, Hilko Bengen wrote: > +#define htole16(_x) ( (((_x) & 0xff) << 8) | \ > + (((_x) & 0xff00) >> 8) ) > +#define htole32(_x) ( (((_x) & 0xff) << 24) | \ > + (((_x) & 0xff00) << 8) | \ > + (((_x) & 0xff0000) >> 8) | \ > + (((_x) & 0xff000000) >> 24) ) You shouldn't really define macros that expand their arguments multiple times. David -- David Laight: david(a)l8s.co.uk

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Hilko Bengen

* Alexandre Julliard: >> Please have a look at the revised patch I just posted. I have avoided >> possible conflicts by only defining the macros if they are needed. > > A different name is much better. Alright. Any suggestions? -Hilko

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Alexandre Julliard

Hilko Bengen <bengen(a)hilluzination.de> writes: > * Alexandre Julliard: > >>> Is this form okay? >> You should pick different names to avoid possible conflicts. > > Please have a look at the revised patch I just posted. I have avoided > possible conflicts by only defining the macros if they are needed. A different name is much better. -- Alexandre Julliard julliard(a)winehq.org

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Hilko Bengen

* Alexandre Julliard: >> Is this form okay? > You should pick different names to avoid possible conflicts. Please have a look at the revised patch I just posted. I have avoided possible conflicts by only defining the macros if they are needed. -Hilko

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Alexandre Julliard

Hilko Bengen <bengen(a)hilluzination.de> writes: > * Alexandre Julliard: > >> Hilko Bengen <bengen(a)hilluzination.de> writes: >> >>> So, do I need to define my own htobe16 and htobe32 functions or macros >>> based on whether WORDS_BIGENDIAN is defined or not? >> >> Yes. > > I have tested these macros on Linux/PowerPC and they still produce the > same results as on i386. > > Is this form okay? You should pick different names to avoid possible conflicts. -- Alexandre Julliard julliard(a)winehq.org

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by André Hentschel

Am 15.06.2012 19:52, schrieb Hilko Bengen: > * Alexandre Julliard: > >> Hilko Bengen <bengen(a)hilluzination.de> writes: >> >>> So, do I need to define my own htobe16 and htobe32 functions or macros >>> based on whether WORDS_BIGENDIAN is defined or not? >> >> Yes. > > I have tested these macros on Linux/PowerPC and they still produce the > same results as on i386. > > Is this form okay? > > -Hilko > > diff --git a/tools/sfnt2fnt.c b/tools/sfnt2fnt.c > index df9260f..9ce503a 100644 > --- a/tools/sfnt2fnt.c > +++ b/tools/sfnt2fnt.c > @@ -46,7 +46,20 @@ > > #include "pshpack1.h" > > -#include <endian.h> > +#if !defined(htole16) || !defined(htole32) > +#include "basetsd.h" > +#if defined(WORDS_BIGENDIAN) > +#define htole16(_x) ( (((_x) & 0xff) << 8) | \ > + (((_x) & 0xff00) >> 8) ) > +#define htole32(_x) ( (((_x) & 0xff) << 24) | \ > + (((_x) & 0xff00) << 8) | \ > + (((_x) & 0xff0000) >> 8) | \ > + (((_x) & 0xff000000) >> 24) ) > +#else > +#define htole16(_x) (_x) > +#define htole32(_x) (_x) > +#endif > +#endif > > typedef struct > { > > -intendation would make this more readable (even for review) -maybe one block per function -- Best Regards, André Hentschel

June 15, 2012

Re: [PATCH] sfnt2fnt: Fix broken .fon files on !x86 architectures

by Hilko Bengen

* Alexandre Julliard: > Hilko Bengen <bengen(a)hilluzination.de> writes: > >> So, do I need to define my own htobe16 and htobe32 functions or macros >> based on whether WORDS_BIGENDIAN is defined or not? > > Yes. I have tested these macros on Linux/PowerPC and they still produce the same results as on i386. Is this form okay? -Hilko diff --git a/tools/sfnt2fnt.c b/tools/sfnt2fnt.c index df9260f..9ce503a 100644 --- a/tools/sfnt2fnt.c +++ b/tools/sfnt2fnt.c @@ -46,7 +46,20 @@ #include "pshpack1.h" -#include <endian.h> +#if !defined(htole16) || !defined(htole32) +#include "basetsd.h" +#if defined(WORDS_BIGENDIAN) +#define htole16(_x) ( (((_x) & 0xff) << 8) | \ + (((_x) & 0xff00) >> 8) ) +#define htole32(_x) ( (((_x) & 0xff) << 24) | \ + (((_x) & 0xff00) << 8) | \ + (((_x) & 0xff0000) >> 8) | \ + (((_x) & 0xff000000) >> 24) ) +#else +#define htole16(_x) (_x) +#define htole32(_x) (_x) +#endif +#endif typedef struct {

June 15, 2012