July 2014 - Wine-Devel - list.winehq.org

Re: shlwapi/tests: Add tests for PathIsRelativeA/W.

by Alexandre Julliard

Zhenbo Li <litimetal(a)gmail.com> writes: > +void test_PathIsRelativeA(void) > +{ > + BOOL ret; > + int i, num; > + static const char *flag[2] = {"FALSE", "TRUE"}; This is not a good idea. There's no guarantee that the return value is always 0 or 1. -- Alexandre Julliard julliard(a)winehq.org

July 1, 2014

Re: [PATCH 3/3] winecoreaudio.drv: Use AUHAL API instead of AudioQueue

by Andrew Eikum

Thanks for reviewing. On Mon, Jun 30, 2014 at 06:45:29PM -0500, Ken Thomases wrote: > I'm concerned about the use of the AudioConverter API within the > capture callback (ca_capture_cb). I have it embedded in my memory > that it's not permitted to call a converter on the device thread. I > can't find a hard and fast declaration of that in the documentation, > although Technical Note TN2091: Device input using the HAL Output > Audio Unit does say this: > > <https://developer.apple.com/library/mac/technotes/tn2091/_index.html> > "If sample rate conversion is needed, it can be accomplished by > buffering the input and converting the data on a separate thread with > another AudioConverter." > > If what you're doing were allowed, it would seem they would have > mentioned that and not suggested the use of "a separate thread". It > also seems that the HAL Output Audio Unit would just do this itself > and not have the restriction on the sample rate in the first place. > Yeah, I read the same thing and decide to just try it out and see what happened. Obviously it works fine in all the cases I've tried, and for a small handful of people who tested it for me. I decided with the wimpy doc language and the fact that it works fine, it wasn't worth the complication of moving the resampling to the application thread. > Besides my specific recollection that sample rate conversion is not > allowed, there's the general requirement to avoid slow operations in > those callbacks. The call to AudioConverterFillComplexBuffer() may be > such a slow operation. So could the calls to malloc() in your > ca_capture_cb() and feed_cb(). > > Could you not move the sample rate conversion to the application > thread, at the point where the application calls in to get the > captured data (or metadata about it)? > You're right, and I suppose it wouldn't be drastically more complicated. It requires some more careful handling of buffer overflow and reporting the buffer fill level. I wish the docs were more clear-cut on this issue. Hiding the resampling from the rest of the code by doing it at data capture time just feels so much cleaner. > In AudioClient_IsFormatSupported(), is it really the case that any > format for which a stream description can be constructed is supported? > Is there a need to try setting the format on an AudioConverter to see > if it will accept it? > Well, we do have tests to show that IsFormatSupported() is accurate, and we pass the tests. I figured it wasn't worth the effort unless we actually find problems. Very few applications (none that I can think of, actually) ask for unusual formats without going through winmm's ACM. I'm always wary about actually opening and setting up devices. It tends to be a slow operation, depending on hardware, and we do lots of IsFormatSupported calls in winmm and dsound. That said, I'll take another look. > There are still two mentions of AudioQueue in lines like: > > WARN("AudioQueue doesn't support per-channel volume control\n"); > Good catch, I'll fix those. Andrew

July 1, 2014

Re: [PATCH 3/5] ddraw/tests: Get rid of struct vertex.

by Henri Verbeet

On 1 July 2014 09:09, Marvin <testbot(a)winehq.org> wrote: > === w8 (32 bit visual) === > visual.c:2633: Test failed: unexpected colortable on offscreen surface > This is most likely an existing failure, although it's surprising the test doesn't crash because of lack of 8-bit display mode support. Was anything changed in the Win 8 testbot configuration recently?

July 1, 2014

Re: [PATCH] riched20: Don't create too many IRichEditOle interface for a RichEdit. (try 4)

by Huw Davies

On 30 Jun 2014, at 17:08, Jactry Zeng wrote: > --- > dlls/riched20/editor.c | 13 +++++++++++-- > dlls/riched20/editstr.h | 1 + > dlls/riched20/tests/richole.c | 19 ++++++++++++++++++- > 3 files changed, 30 insertions(+), 3 deletions(-) Looks good to me. Huw.

July 1, 2014

Re: [PATCH 5/5] ddraw/tests: Get rid of struct nvertex.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7789 Your paranoid android. === w8 (32 bit visual) === visual.c:2631: Test failed: unexpected colortable on offscreen surface

July 1, 2014

Re: [PATCH 4/5] ddraw/tests: Get rid of struct tvertex.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7788 Your paranoid android. === w8 (32 bit visual) === visual.c:2632: Test failed: unexpected colortable on offscreen surface

July 1, 2014

Re: [PATCH 3/5] ddraw/tests: Get rid of struct vertex.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=7787 Your paranoid android. === w8 (32 bit visual) === visual.c:2633: Test failed: unexpected colortable on offscreen surface

July 1, 2014