winmm: Fix notification when recording using MSACM.

Hi, Alexandre Julliard wrote: To achieve this, we eliminate the tail call and turn it into a loop, which allows us to preserve the local state in the variable last. Please do this as a proper loop, not with a goto. In bug #33155 I explained that Wine's PullACMData needs a redesign

[1/3] Make mac driver the default on OS X

I wrote: The [notepad] menu bar sometimes was refreshed badly, causing some texts therein to be displayed twice, shifted by a few pixels, or with varying fonts. That looks much like bug #33154 http://bugs.winehq.org/show_bug.cgi?id=33154 filed about Linux/X11. Nothing specific to winemac -- at

[1/3] Make mac driver the default on OS X

Hi, Charles Davis wrote: While we're on the subject of bugs: another annoying problem is that, when a window is first created, the view appears black I had a very annoying experience: when I started winemac the first time, the whole screen turned black for a fraction of a second. That was very

[1/3] Make mac driver the default on OS X

Hi, I'm not sure it's worth it. In my experience, the virtual desktop has more often been used to work around X window manager limitations. The hope is that we have greater control with the Mac driver. If all else fails, the X11 driver is still available. True. Anyone who'd even bother to

[1/3] Make mac driver the default on OS X

Hi, Ken Thomases wrote: I think that the Mac driver should not be made the default until OpenGL and clipboard support are in. Exactly :-( Following Josh DuBois explanation about HKCU/Software/Wine/Drivers Graphics=mac,x11 I decided to give it a try over the week-end and was very disappointed to

ntdll: make NtDelayExecution a bit more efficient

You may try and find that MSDN or blog page where people explain the subtle differences of Sleep(0) and Sleep(1) on multi-core machines. Regards, Jörg Höhle

[PATCH 2/2] winmm: MCI_BREAK_HWND handling now matches Wine's 1999 MCI_DefYieldProc.

Hi, It doesn't make sense to add workarounds for Wine code, it should be fixed instead. That's why I had separated this debatable part into patch 2/2. But what about patch 1/2 not yet committed? That one contains all stuff that's not debatable and is backed up by tests from w2k-w7. 1/2 is

mmdevapi: Prevent 64 bit overflow within a few days of audio device use. (try 2)

Hi, Michael Stefaniuc wrote: But I see that even the whole functionality can move to a helper. That's not a good idea: While the code currently contains two identical pieces of code, it is actually bogus because the capture part should *not* store current time rather than get *recorded* time.

wanted: testbot w9x machines

Hi, Francois Gouget wrote in another thread: Not so long ago that machine was also running the tests on 5 additional NT4 configurations, Windows 95, Windows 98 and Windows Millenium. It no longer does, not because of lack of 'resources' or 'intention', but because the Wine community is not

mmdevapi: Prevent 64 bit overflow within a few days of audio device use. (try 2)

Michael Stefaniuc wrote: My idea was to have the whole if else in an inline function. That's understandable. However in this particular case, we know that in Wine QueryPerfFrequency now yields 1000, thus Muldiv64 is dead code actually. So I decided to keep the if (freq == 1000) return

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

Hi, Johannes Kroll wrote: I don't understand what you mean by decompose LongMsg into snippets. Is it possible that either A) the app expects the API code to scan the buffer for a trailing 0xf7 end marker and send only the bytes up to that marker; or B) that the mysterious dwBytesRecorded should

newtestbot timings

Hi, I've looked at some of newtestbot timing results. http://newtestbot.winehq.org/JobDetails.pl?Key=256 It's not too bad, but it's not superb either. render.c:633: event after Stop.4 average 40.000ms deviation 0.06 from 100 samples That's exactly the expected 40ms, great! render.c:618: Test

winmm: More compatible waveIn/Out[Un]Prepare WHDR_* flag handling.

Hi, One thing to note is a slight change when Prepare is called twice in a row. When the ACM is used, the former Wine code would prepare the ACM again, leaking the memory of the previous preparation. Now that code is by-passed as the header is prepared exactly once, the first time. What if the

64bit integer overflow in 3 days

Hi, You believe that 64bit integers give you plenty of room and time to avoid trouble like Y2k and Y2033, don't you? The trouble is, these large data types make using other large numbers more attractive than they used to be, e.g. counting time in 100 nanosecond units, representing one second as

mmsystem 16bit questions

Hi, I noticed some dubious differences among winmm16 functions. I believe there should be none, but perhaps I'm missing some 16bit idiosyncrasies? Please compare waveOutPrepareHeader16, Unprepare16 and waveOutWrite16: http://source.winehq.org/source/dlls/mmsystem.dll16/mmsystem.c#L1287 UINT16

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

Hi, Johannes Kroll wrote: 9.532:003a:trace:midi:modLongData dwBufferLength=88 ! f0 42 41 00 01 11 01 7f 4b 40 7a 01 7f 02 7f 7f .BA.K@z. 7f 7f 71 7f 40 01 7f 7f 7f 7f 03 7f 7f 01 01 00 ..q.@... 00 7f 06 02 7f 7f 01 40 00 00 7c 7f 00 7f 7f 7f ...@..|. 7f 7f 7f 7f 7f 7f

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

Johannes Kroll wrote: It is in the log line that you deleted. Oops. No, I don't have wineOSS. Does it require a proper OSSv4? Currently, yes. You'd have to try out wine-1.3.24 or older. I'll try and see how to use virtual MIDI devices to dump data without using a serial port. Anyway, I'll start

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

Hi, Johannes Krol wrote: Joerg, if you want the complete log I can send it to you by PM, it's about 1.7M. I don't need that for now. What I need are the 119 missing bytes between 17.015:003b:trace:midi:modLongData dwBufferLength=125 ! 17.015:003b:trace:midi:modLongData F0 42 40

winealsa: Have the MIDI recorder wait in poll(), not snd_seq_event_input().

Johannes Kroll asked: Did this patch get through? I don't see it on http://source.winehq.org/patches/ ... It did. You looked too late in patches/. Committed patches are deleted sooner than rejected ones that are in turn deleted sooner than new/pending patches. I'm still interested in your

kernel32: Use the monotonic counter in GetTickCount64.

Hi, I believe we should use this opportunity and review the usage of timers in Wine. E.g. I have a patch to have CreateTimerqueue use the monotonic timer too that I'll submit after some more testing. Mmdevapi's audio currently depends on the TimerQueue which IMHO erroneously depends on

Please perform MIDI test with MS OS

Hi, if you can, please download the test executable from https://testbot.winehq.org/JobDetails.pl?Key=24107 and run it on a native MS machine (32 and 64 bit). Please send me the results, no need to post. I particularly welcome test results from old w9k machines! Thank you, Jörg Höhle

winmm/tests: Allow more margin in the test_asyncWAVE() playback check.

Francois, thank you for helping remove timing-caused flakiness from the tests. I believe you forgot to test your patch in Wine(!). The test +ok(400 = p2 p2 = 600, %ums is not in the expected 400-600ms range\n, p2); should fail in every version of Wine. Ironically, the reason is mentioned

RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)

Hi, please view the winmm:wave test results from Francois Gouget's machines fg-acer64-t32 fg-acer64-wow32 fg-acer64-t64 fg-acer64-wow64 http://test.winehq.org/data/dabde6a04f6d02233bc5074a8eba613b2c4adc68/index_Linux.html#winmm:wave Is their configuration the same except for 32/64bit? We see 3

macdrv: implement getting and setting the screen saver state. if(Style)

Hi, Ken Thomases wrote: +if(success != kIOReturnSuccess) Another style nitpick: please put a space between if and the condition. That applies to the if(count2) above, too. I find this over the top. Where is the rule? Andrew Eikum's mmdevapi code -- which I don't consider

Re: RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)

Alexandre Julliard wrote: At least on my setup, the current code is working just fine, and offering the devices I expect, without any manual configuration. Are you using PulseAudio? I believe that *every* user with PulseAudio is bound to see the flakiness that happened on Francois' machine. So

Re: winmm/tests: Allow more margin in the test_asyncWAVE() playback check.

I suggest adding a todo_wine plus an additional ok(0p2 strcmp(buf,2000)) that Wine won't fail. Ok. I think this can still be narrower, 400-1000ms for instance I meant to have 2 tests ok(0p2 strcmp(buf,2000)) -- not narrowed, just to prevent complete breakage todo_wine ok(100=p2 p2=300) --

RFC: Remove auto-scan of ALSA devices from winealsa.drv (and get repeatable behaviour)

Alexandre Julliard wrote: If PulseAudio can't provide good enumeration, then we can detect that case and handle it differently. We don't ask PA to enumerate, we ask ALSA to enumerate. Remembers me of the difficulties of enumerating /dev in Linux from user space: The problem is similar: open an

Adding DECLSPEC_ALIGN(4) to structs for atomic DWORD access

Hi, there are some places in Wine where I believe atomic access to 32bit entities is expected by the programmer, yet I see little or no measures to ensure this. DWORD-Alignment is essential when several threads can access the same DWORD variable outside of a mutex (or within the implementation

Truncate MIDI SysEx messages after termination byte

Hi, Christian costa wrote: +lpNewData[lpMidiHdr-dwBufferLength + len_add] = 0xF7; Here you're using spaces only, whereas the surrounding code uses TAB8. I tested it with the unit test attached. Instead of some isolated unit test, it would be preferable to add to winmm/tests/midi.c

Truncate MIDI SysEx messages after termination byte

Christian costa wrote: But I don't know whether there's some harmless general SysEx that we can send out. Maybe some MIDI guru could suggest some? What do you by harmless ? For what ? A midi HW device connected to the midi port ? A harmless MIDI message, perhaps there exists a NOP SysEx?

Truncate MIDI SysEx messages after termination byte

Hi, Johannes Kroll wrote: +for(i = 0; i lpMidiOutHdr-dwBufferLength; i++) +if((unsigned char)lpMidiOutHdr-lpData[i] == 0xF7 i lpMidiOutHdr-dwBufferLength-1) What about for(i = 0; i+1 lpMidiOutHdr-dwBufferLength, i++) without the redundant second if() half? I'm always

Truncate MIDI SysEx messages after termination byte

Hi, Christian Costa wrote: I took a look at the alsa code and this code simply does not do what it is supposed to. I also looked at it today and noted those bogus lines you quote. Needs a patch (+ fix memory leak). However, Johannes' change is presumably different, as he wants to scan the buffer

mmdevapi: Avoid lock contention after SetEvent.

Andrew Eikum asked: Is it true that SetEvent() causes a context switch? Looking at +tid log files, I've seen switches happen after SetEvent often enough. That motivated some changes to winmm notification in the last years, i.e. call SetEvent after all local work is finished and objects are in a

dsound: use event based threads, v2

Maarten, +hres = IAudioClient_GetStreamLatency(device-client, period); +device-sleeptime = period_ms * 5 / 2; + ret = WaitForSingleObject(dev-sleepev, dev-sleeptime); Although it's a minor point, as we're solely discussing the case of the timeout when mmdevapi doesn't

dsound: use event based threads, v2

Hi, Maarten Lankhorst answered: [...] I wonder why you insist on using GetStreamLatency as the basis of your timeout computations instead of GetDevicePeriod. Because I'm using it later on in the rework to tell how much to queue. Ah. But why not use the correct tool for the correct job?

mmdevapi: Avoid lock contention after SetEvent.

Hi, what's up with this patch? I wrote: SetEvent is one of those calls with a high probability that the Linux scheduler will switch to another thread, e.g. the one receiving the event. As the critical section is still hold, it'll prevent the receiver from invoking mmdevapi, e.g.

Re: mmdevapi: Prevent race condition upon Start.

Since This-started was not set yet[...] This doesn't make sense, there's a critical section. You are right, this one patch is only needed for my lock-less code, which I'll not submit for now. Good catch. (The minimal dueTime would benefit current code nevertheless, since critical section

winealsa: Separate read and write pointers.

Andrew Eikum wrote: This [lock-less] seems to be the main goal of the patch. It'll not be bad to fix the capture bug independently. and maybe we can get that into Wine after the next release? That requires agreement on the lock-less protocol. Basis: atomic 32bit updates. Do we want

RFC: Remove auto-scan of ALSA devices from winealsa.drv

Hi, Henri Verbeet suggested: But supposedly we'll have a winepulse driver eventually, so winealsa would only need to care about actual ALSA devices. Alas, it's only after you opened the device that you can discover that it's PulseAudio, at which time it is too late. Also, I don't know if PA is

RFC: Remove auto-scan of ALSA devices from winealsa.drv

Hi, Here's my proposal: winealsa shall stop enumerating ALSA devices. By default, it should solely provide access to ALSA's default device adequately named default. The code that currently scans the registry Software\Wine\Drivers\winealsa.drv\devices=... shall remain in place, allowing a

winepulse test data review

Maarten Lankhorst wrote: That was about the relationship between GCP and GetPosition. Now what about GetPosition and wall time (as seen by the HighPerformanceTimer)? The largest delta is 8ms, which suggests that your GetPosition is not particularly regular, but as it stays below one 10ms

winepulse test data review

Hi, Maarten Lankhorst wrote: Actually in winepulse, sleep / 12000 (8 ms I guess?) ms would work, no sleep at all works too, Yes, I wanted to go no further than 8ms below the 10ms period limit. it was just the mixing of various levels of sleep that was failing. Not sure why though, might be

[PATCH] dsound: Use event based threads

Hi, Maarten Lankhorst wrote: Alsa's native period is ~ 22ms (1024 samples / 44100 or 48000) with dmix despite claiming it to be otherwise.. What I don't understand is why you talk about ALSA at this level. DSound talks to mmdevapi and that's DSound's underlying API, not ALSA. So if Wine's

[PATCH] dsound: Use event based threads

Hi, Maarten Lankhorst queried: Bump, anything wrong with this patch? Here's my 0.0$ ... (standard DSound disclaimer here...) Using mmdevapi's events in DSound is basically TRT. Then, the DSound mixer will be synchronized with mmdevapi writes. + /* ALSA is retarded, add a timeout..

winepulse test data review

Hi, Maarten Lankhorst kindly posted mmdevapi test results for render and capture gathered using his winepulse driver: http://www.winehq.org/pipermail/wine-devel/2012-October/097602.html render.c:1199: padding 1250 position 51/21250 slept 470ms iteration 0 I've run your data through some

[PATCH 1/2] winmm/tests: Add more mmioSeek tests. (try 2)

Hi again, More comments about your tests #2: +DeleteFileA(test_file); +[...] +has_test_file = create_test_file(test_file); Why do you recreate an identical file between test group 2 and 3? +has_test_file = create_test_file(test_file); +ok(has_test_file, failed to create test

[PATCH 1/3] winmm: Prefer using MMSYSERR_* over AUDCLNT_E_* from mmdevapi. (resend)

Hi, what's up with this patch series? Regards, Jörg Höhle

[PATCH 1/2] winmm/tests: Add more mmioSeek tests.

Sagawa San, it's nice to see somebody contribute to winmm! +return; +} That return is line noise. +hmmio = mmioOpen(NULL, mmio, MMIO_READ); +if (hmmio == NULL) { +win_skip(mmioOpen error %u\n, mmio.wErrorRet); +return; +} AFAIK mmioOpen has

WANTED: compiler barrier for use within Wine

Hi, I'm missing a portable compiler barrier for use within Wine. MSVC has _ReadBarrier, _ReadWriteBarrier etc. http://msdn.microsoft.com/en-us/library/f20w0x5e(v=vs.80).aspx GCC has __asm__ __volatile__(:::memory); However compilers other than GCC may be used to compile Wine, e.g. I believe

WANTED: compiler barrier for use within Wine

Alexandre Julliard wrote: A critical section doesn't involve the wine server. I simply saw that path: RtlEnterCriticalSection - RtlpWaitForCriticalSection - - wait_semaphore - fast_wait | NTDLL_wait_for_multiple_objects - SERVER_START_REQ but I don't like to argue about your server with you.

xapofx1_3.dll?

Hi, why does Wine include a stub xapofx1_1.dll but no xapofx1_3.dll? Installing Wallace Gromit 102 The Last Resort / Urlaub unter Tage adds xapofx1_3.dll XAudio2_4.dll and X3DAudio1_6.dll to system32 (though IIRC I asked the installer not to care about DirectX). This app loads none of these

ntdll: Do not execute callbacks past DeleteTimer(INVALID_HANDLE_VALUE)

Hi, Your paranoid android wrote: [what am I? A human answering a bot!?!] === WVISTAADM (32 bit sync) === sync.c:946: Test failed: DeleteTimerQueueTimer That's a flaky test already known from:

vcomp: single-threaded implementation of _vcomp_fork (try 6)

Hi, Alexandre Julliard wrote: +void WINAPIV _vcomp_fork(BOOL ifval, int nargs, void *wrapper, ...) +__ms_va_list valist; it's ugly to use varargs only as a hack to get a pointer to the first argument. Would taking the address of wrapper (as in asm(...,r=wrapper) or any C code like void*

[PATCH 5/6] dsound: rework ugly mixer logic

Hi, Maarten Lankhorst wrote: only oss4 and (maybe, just guessing?) coreaudio don't support float MacOS' CoreAudio supports floats. Actually, given that it's an entire audio pipeline like quartz, I bet it even prefers floats. I also refer you to GetStreamLatency where I was getting the period

[PATCH 5/6] dsound: rework ugly mixer logic

Hi, Maarten Lankhorst wrote: For example Skyrim with a 36 ms stream latency will just buffer in more data to compensate instead. But it can't do it if you report that it's fine to feed data every 5 ms. Please elaborate. Every now and then I wish you used more words to explain your

[PATCH 10/25] mciseq: Limit concurrency when starting to play.

Hi, Alexandre Julliard wrote: If another thread can change dwStatus you need a critical section or an interlocked function. So if AJ is still not satisfied with try 2, I'll change all reads of wmm-dwStatus within the player into InterlockedExchange. Yet I think that would be a superfluous

[PATCH 10/25] mciseq: Limit concurrency when starting to play.

David Laight wrote: InterlockedExchange(status, wmm-dwStatus); That use of InterlockedExchange() is OTT. Thank you for the clarification. I've come across http://gcc.gnu.org/wiki/Atomic/GCCMM http://gcc.gnu.org/wiki/Atomic/GCCMM/PracticalUsage and found the official expression for what I've

[PATCH 17/25] winmm/tests: Add initial set of MCI MIDI tests (incl. DeleteFile)

Hi, Von: Marvin [test...@testbot.winehq.org] Gesendet: Mittwoch, 10. Oktober 2012 15:34 While running your changed tests on Windows, I think I found new failures. Patch failed to apply As Marvin woke up 5 days after patch submission, it did not realize that patches 1-6 had been applied since.

[PATCH 10/25] mciseq: Limit concurrency when starting to play.

Hi, David Laight wrote: Better to code as: status = wmm-dwStatus; if (...) Incidentally, that's what I did tonight in patch 20/25 try 2. but even then I think the compiler is allowed to perform extra reads. It might, for example, do so if the condition was complicayted and there

[PATCH 10/25] mciseq: Limit concurrency when starting to play.

Alexandre Julliard wrote: This makes no sense, you can't make assumptions about the generated code from the shape of the if statements. Don't || and impose an evaluation order? Also there's no such thing as conceptually volatile, unless you add explicit memory barriers. Forget about

Re: [PATCH 10/25] mciseq: Limit concurrency when starting to play.

Hi, +switch (wmm-dwStatus) { +case MCI_MODE_PLAY: +case MCI_MODE_PAUSE: + wmm-dwStatus = MCI_MODE_STOP; +} This is weird. You're missing a break, You're right, at least a /* fall through */ or break is custom. and it seems like an if statement would be more appropriate

Re: [PATCH 10/25] mciseq: Limit concurrency when starting to play.

Alexandre wrote: if (wmm-dwStatus == MCI_MODE_PAUSE) continue; if (wmm-dwStatus != MCI_MODE_PLAY) break; but that's not the same. A concurrent thread might change dwStatus to PAUSE right between the 2 lines. If the code depends on that sort of thing then it's broken. If another

Help getting amd64 assembly patch into wine?

Dan, I found your message very unclear. The patch adds support for OpenMP programs like this: And then you start talking about vcomp_fork without telling us where it comes from and what it should do. So I'll guess from the names. - vcomp_for_static/sections_init sound like startup code

is CreateThread(CREATE_SUSPENDED) fully functional?

Hi, Recently I thought I found a use-case for CreateThread(CREATE_SUSPENDED). The idiom is to get the thread handle before the thread starts a life on its own. I looked at the kernel tests, http://source.winehq.org/source/dlls/kernel32/tests/thread.c#L460 However, both invocations with

dsound: Don't bother shrinking the secondary buffer list.

Michael, +#include assert.h your patch is already committed, yet I believe that the least that dsound needs is new asserts. Asserts in dsound have been a PITA in Wine for the last decade. It's ok for the kernel to crash in an assert. IMHO it is not ok for an optional thing like sound. The

Overriding the check for ownership of a prefix

Scott, I don't think you need to override this check, esp. given that there's a good reason for it being there: Note that there is a problem with this setup if the app modifies the registry and we then need to update the prefix-default registry I've excellent experience with symbolic links. In

[PATCH] winepulse.drv: Add PulseAudio driver

Hi, If you don't paste all the mmdevapi tests with the fix in my git tree, it's a regression. I don't want to see held_Frames because it's a shadow buffer. If winmm and dsound don't work without it, they're wrong, fix those. I won't comment on the two individual pulseaudio drivers.

Disablin xinput2 for now?

Hi, There seem to be regressions in xinput2 support I too have experienced various mouse trouble since approx. 1.3.18 on MacOS, using XQuartz 2.5.x or 2.6.1 -- which is much more recent than any of my Ubuntu systems (Lucid). As I've currently little time for regressions, I haven't yet turned that

limits on the number of events, windows and threads?

Hi, I vaguely remember reading about a quite low limit on the number of event objects that a thread can hold because each one is said to take up one bit in some 32 or 64 bit mask. That was then invoked as a reason to allocate e.g. event or window objects for as short a time span as possible. Is

dead-lock free design

Hi, there are two guidelines that I identified while trying to prevent dead-locks with critical sections and access to uninitialiased memory in Wine. My latest patch shows both applications. http://www.winehq.org/pipermail/wine-patches/2011-June/103247.html 1. In callbacks, detect when it

deadlock in mmdevapi AudioClient_Stop (winealsa.drv/mmdevdrv.c)

Hi, please try and convince me that a deadlock cannot happen. http://source.winehq.org/source//dlls/winealsa.drv/mmdevdrv.c AudioClient_Start calls CreateTimerQueueTimer which creates a new thread periodically invoking the timer callback. The callback invokes alsa_push_buffer_data() which

mmdevapi event driven (aka. pull) mode

Hi, What behavior do you think Wine is going to do wrong Matthew van Eerde's web log has a sample silence playing application using EVENTCALLBACK mode. http://blogs.msdn.com/b/matthew_van_eerde/archive/2008/12/10/sample-playing-silence-via-wasapi-event-driven-pull-mode.aspx Running it in Wine

DVD/CD-ROM recognized as network drive/floppy disk on MacOS

Hi, perhaps I should turn this into a bug report, but I'm hoping for a quick fix. Using wine-1.3.21 on Mac OS X 10.5.8, I observed that winecfg reported a data DVD as network drive and a data CD-ROM as floppy disk. An audio CD was correctly reported. This is probably caused by the recent

mmdevapi/tests: Fix wrong buffer unit and memory leaks.

Hi, * nBlockAlign is wrong since data is counted in frames, not bytes. I forgot to comment that I introduced the 10x multiplicator to convince myself that GetData accepts buffer sizes larger than the default 10ms chunk returned by GetDevicePeriod. That is reasonable, but not guaranteed when I

winealsa.drv:mmdevapi input validation

Andrew Eikum wrote: Frankly, I see little reason to spend time implementing special handling of exclusive mode unless we find an app that does something that requires it. Actually, I don't know whether any of the apps I own can use mmdevapi. I've been looking at it because I believe you are

mmdevapi buffering

Hi, Andrew Eikum wrote: Then, GetCurrentPadding() returns write - read and GetBufferSize() returns the queue size limit. As far as I can tell, this is entirely consistent with how Windows behaves. I added some lines to mmdevapi/tests/render.c to find out more about mmdevapi with the help of

winealsa.drv:mmdevapi input validation

Hi, because of bug #27087, I had a look at the emerging mmdevapi code. Actually, it's the first time I read its documentation on MSDN. Here are a few comments of mine while reading the code. The handling of duration (- buffer size) in winealsa.drv/mmdevdrv.c:AudioClient_Initialize does not

mmdevapi buffering

Hi, I have one big concern about MSDN's Rendering a stream (shared mode) example w.r.t wrap-around of buffer pointers and how Wine implements it. The example is at http://msdn.microsoft.com/en-us/library/dd316756(v=vs.85).aspx Suppose the write pointer is near the end of the buffer and the app

mmsystem16.h incorrect? SEGPTR vs. LPSTR

Executive summary: I believe LPSTR is all wrong in mmsystem16.h's MCI defs. Hi, I've some doubts about the correctness of some definitions in mmsystem16.h, esp. the use of SEGPTR vs. LPSTR types. Please compare typedef struct { DWORD dwCallback; LPSTR lpstrReturn; ... }

mmsystem16.h incorrect? SEGPTR vs. LPSTR

Alexandre, Damjan, Eric, I understand your answers mean that a patch is needed to MCI_*_PARMS16 in mmsystem16.h to turn all occurrences of LPSTR into SEGPTR. E.g. MCI_LOAD_PARMS16, MCI_DGV_INFO_PARMS16, MCI_DGV_OPEN_PARMS16 ... I suppose DWORD dwCallback; is ok to copy 1:1 (what the code

no line numbers in backtraces on Mac OS X?

Hi, Is it normal that there are no source line numbers in backtraces on Mac OS? Despite many patches to winedbg etc., the backtraces I get are no better that those from 1.1.24 times. 18 0x41f5b2a1 _OpenDriverA+0x51() in winmm (0x0032ce78) 19 0x4041467f _initAudioDlg+0x75f() in winecfg

performance regression or not?

Hi, please consider the following WINEDEBUG=+fps numbers. 1.1.24 24-19 fps, depending on orientation 1.3.16 14-7 fps 1.3.18-291-g9da9240 14-6 fps 1.3.18-342-gab199f5 13-5 fps 1.3.19-46-g3025f7f 8 fps 1.3.20 7-4 fps The low fps results in jerky character

dsound: return success in IDirectSoundBufferImpl_AcquireResources

Austin English wrote: - FIXME((%p,%08u,%u,%p): stub\n,This,dwFlags,dwEffectsCount,pdwResultCodes); + FIXME((%p,%08u,%u,%p): stub, faking success!\n,This,dwFlags,dwEffectsCount,pdwResultCodes); This is superfluous :-) stub is generally synonym with faking success. One lesson about

winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.

Hi, well, I know little about MIDI and have no MIDI HW, yet what I read about the F1 code is that it is indeed a quarter time tick and takes 2 bytes, so the 2nd part of Stéphane Bacri's patch from last month looks good to me. The first half + toSend = ((ev-data.control.value

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

Hi, Damjan Jovanovic wrote: What determines what subtype of MCI_STATUS_PARMS is passed to mciSendCommand() for an MCI_STATUS message? I consider the string interface the defining property of MCI devices. This sets it apart from e.g. COM interfaces. Further I believe the string and command

winscard/tests: Add test base functions of winscard.dll

Sergey, + * Unit test suite for AVI Functions + * Copyright 2008 Detlef Riekenberg +#include wingdi.h +#include vfw.h Please try and hide better the copypaste origin of the code :-) rezult result +ok(winscard_rezult != SCARD_F_INTERNAL_ERROR I recommend tests to be stricter, e.g. ok(result

[1/2] mmsystem.dll16: fix MCI_STATUS mapping for digitalvideo

Damjan, @@ -407,6 +441,20 @@ static MMSYSTEM_MapType MCI_UnMapMsg16To32W(WORD wMsg, DWORD dwFlags, DWORD_PTR +mdsp16-dwCallback = mdsp32w-dwCallback; +mdsp16-dwItem = mdsp32w-dwItem; +mdsp16-dwTrack = mdsp32w-dwTrack; This is superfluous. dwReturn is the

msvcrt: Add tests to show that utime() can take a NULL-pointer for the utimbuf structure field

Louis, Anything i could do to improve to get it in? Perhaps http://source.winehq.org/patches/ shows that you should get rid of the one apply failure. Basically, your patch does the right thing, as MSDN says If times is a NULL pointer, the modification time is set to the current local time. --

Fix WineHQ bug #19762

Kai Wasserbäch wrote: as bug #19762 is open for some time now, fully bisected, the solution applied for several versions in my Debian packages ([0]) without reports about breakage, I hearby propose the reversion of commit 67631163. http://bugs.winehq.org/show_bug.cgi?id=19762#c21 That commit is

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.

Damjan, can you recommend any downloadable 16bit app that stresses the MCI? It's good that you noticed that RECT16 and RECT do not have the same size (whack!). Yet I'm surprised that you left MCI_WINDOW untouched. I believe that the apps that use MCI_WHERE/PUT etc. (i.e. MCIAVI) are likely to

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.

Hi, Damjan Jovanovic wrote: In the meanwhile I've found another problem: mciavi32 always deadlocks when MCI_WAIT is not set:[...] ShowWindow() Looks like bug #21060 and the others http://bugs.winehq.org/show_bug.cgi?id=21060#c2 - bug #12908, bug #15669, bug #18363 involving ShowWindow; - bug

Question on Conformance Test

Hi, James McKenzie wrote: I realize that WindowsNT 4.0 is our base configuration IMHO that doesn't matter. Winecfg's default changed from w95 to w2k to xp while I was looking. What would be the BEST method of annotating this: ok ( GetLastError() == WINXP_ERROR || GetLastError() ==

winealsa.drv: Add mmdevapi driver.

Andrew Eikum wrote: Does CoTaskMemFree match HeapAlloc? would anyone more familiar with CoTaskMem* want to comment? [cbSize slot present?] Hm, to my surprise it seems MS no longer does this check as of Win7. Well, it's consistent with the documentation. So it's only the winmm API that has to

winealsa.drv: Add mmdevapi driver.

Andrew, +fmt-Format.nSamplesPerSec = 41100; +fmt-nSamplesPerSec != 41100 44100. IIRC, there was an error exactly like this somewhere in the old drivers. But why does your IsFormatSupported only accept 48kHz, 44.1, 22.050, etc.? Do the native drivers behave like this? Is

ntdll: Remove more path trailing chars.

Hi, Juan Lang wrote: Vincent Pelletier wrote: Those tests are boolean, so I doubt an ok(pass || fail /* NT4 */) makes any sense. I saw that it is discouraged (forbidden ?) to depend on OS version in tests, so I will avoid that path unless asked to follow it. You'd want to use ok(pass ||

Must multimedia players check the message queue and invoke DispatchMessage?

Hi, Juan Lang wrote: What do you mean exactly by message pumping? It's a broad topic, but yes, basically you want to call DispatchMessage on some messages periodically. See e.g. MsgWaitForMultipleHandles. Thanks for the link to http://blogs.msdn.com/b/oldnewthing/ in another thread. That day's

[PATCH 2/6] winmm: DriverCallback ignores a 0 CALLBACK_WINDOW.

Hi, any feedback on winmm:DriverCallback patches 2-6? - Although I superseded patch 1/6, the others are unchanged, hence I did not resend them. - I thought about merging patches 2+3+5 into one or two. After all, they all change the one tiny DriverCallback function. E.g. patch 2 fixes the

semi-obsolete audio drivers

Hi, you may have noticed that I've always sent patches for the 3 audio drivers that I consider current and mostly up to date: + winealsa + wineoss + winecoreaudio and never for one of the other ones which I consider obsolete. - winejack - wineesd - winenas Sometimes I've been wondering

w9x/ME users, please test (mciGet/SetYieldProc)

Hi, Testbot job #10124 contains a test that works perfectly on machines since w2k, but much to my surprise, mciGetYieldProc returns NULL,0 on testbot's win9x machines. If you have a w9x or a WinME machine, I'd appreciate if you could run the test too. Download invoke winmm_test.exe midi

Re: [PATCH2/2] winmm: PlaySound concurrency cleanup.

Eric, sharing a global variable between threads without proper sync protection or atomic operation is the wrong thing to do Which one? bPlaySoundStop is set and reset within the scope of WINMM_cs. Actually, there's one error: I should have put it at the exact same location of the

  1   2   3   >