Re: Does auto-apt work to get wine dependencies in source code?
Op 25-08-13 14:09, Susan Cragin schreef: > Hello, > Was thinking of running some tests but the list of dependencies on the > website seems outdated, apt-get build-dep does not work. Is that with the ubuntu-wine ppa enabled?
re: [PATCH (try 2)] dsound: Copy SetFormat format more directly if we're not in PRIMARYWRITE mode
NAK. + HeapFree(GetProcessHeap(), 0, device->primary_pwfx); + device->primary_pwfx = DSOUND_CopyFormat(passed_fmt); Copy to a tmp buffer first and return E_OUTOFMEMORY instead of reassigning primary_pwfx to NULL? ~Maarten
[PATCH for valgrind] coregrind: implement GS override for arch_prctl on linux
Allows wine64 to run in valgrind! Apply with -Np0. :D
Yes I know that %gs is still zero on linux amd64. Details details..
Signed-off-by: Maarten Lankhorst
---
Index: coregrind/m_translate.c
===
--- coregrind/m_translate.c (revision 13279)
+++ coregrind/m_translate.c (working copy)
@@ -1486,7 +1486,7 @@
# if defined(VGP_amd64_linux)
vex_abiinfo.guest_amd64_assume_fs_is_zero = True;
# endif
-# if defined(VGP_amd64_darwin)
+# if defined(VGP_amd64_darwin) || defined(VGP_amd64_linux)
vex_abiinfo.guest_amd64_assume_gs_is_0x60 = True;
# endif
# if defined(VGP_ppc32_linux)
Index: coregrind/m_syswrap/syswrap-amd64-linux.c
===
--- coregrind/m_syswrap/syswrap-amd64-linux.c (revision 13279)
+++ coregrind/m_syswrap/syswrap-amd64-linux.c (working copy)
@@ -564,6 +564,16 @@
*(unsigned long *)ARG2 = tst->arch.vex.guest_FS_ZERO;
POST_MEM_WRITE(ARG2, sizeof(unsigned long));
}
+ else if (ARG1 == VKI_ARCH_SET_GS) {
+ tst = VG_(get_ThreadState)(tid);
+ tst->arch.vex.guest_GS_0x60 = ARG2;
+ }
+ else if (ARG1 == VKI_ARCH_GET_GS) {
+ PRE_MEM_WRITE("arch_prctl(addr)", ARG2, sizeof(unsigned long));
+ tst = VG_(get_ThreadState)(tid);
+ *(unsigned long *)ARG2 = tst->arch.vex.guest_GS_0x60;
+ POST_MEM_WRITE(ARG2, sizeof(unsigned long));
+ }
else {
VG_(core_panic)("Unsupported arch_prtctl option");
}
winetestbot back online, for now
Hey, It looks like the vmware licensing issues are resolved, so all testbot vm's are online again. I hope the replacement testbot is coming along nicely, because winetestbot is still scheduled to go permanently offline in may. ~Maarten
Re: [PATCH] dsound: rework ugly mixer logic
Op 31-12-12 20:01, Andrew Eikum schreef:
> On Mon, Dec 31, 2012 at 07:03:31PM +0100, Maarten Lankhorst wrote:
>> Op 31-12-12 17:59, Andrew Eikum schreef:
>>> On Sat, Dec 29, 2012 at 01:24:03AM +0100, Maarten Lankhorst wrote:
>>>> + if(!maxq){
>>>> + /* nothing to do! */
>>>> + LeaveCriticalSection(&device->mixlock);
>>>> + return;
>>>>}
>>> This was removed in 8ba4090fc304993. It breaks starting the device in
>>> some situations (write primary mode iirc).
>> Writeprimary dsound tests still worked for me, I don't particulary care
>> though, if you want I'll zap it.
>> After rework fail it should no longer matter..
>>
> Zaxxon (see Bug 30836) shows the problem on some, but not all,
> systems. Anyway, PerformMix() does more than just mix and write data,
> so returning early only because we have no frames to write is not
> always correct.
>
>>>> + if (native) {
>>>> + void *buffer = NULL;
>>>> +
>>>> + hr = IAudioRenderClient_GetBuffer(device->render, maxq
>>>> / block, (void*)&buffer);
>>>> + if(FAILED(hr)){
>>>> + WARN("GetBuffer failed: %08x\n", hr);
>>>> + LeaveCriticalSection(&device->mixlock);
>>>> + return;
>>>> + }
>>> I think this (mixing directly to RenderClient and skipping WaveQueue)
>>> could be split into a separate patch.
>> Hate to sound like a broken record here, but the whole mixer logic breaks if
>> you touch that code. :/
>>
> Really? It looks like an optimization to me: mix directly into the
> RenderClient buffer instead of to the intermediary buffer if the
> target format is float. What breaks if we use the intermediary buffer
> in every case?
>
I suppose the if native branch could be taken out, but that's not nearly as
interesting as the other
changes I was making in that function, and not nearly as likely to mess up
anything.
~Maarten
Re: [PATCH] dsound: rework ugly mixer logic
Op 31-12-12 17:59, Andrew Eikum schreef:
> On Sat, Dec 29, 2012 at 01:24:03AM +0100, Maarten Lankhorst wrote:
>> +if(!maxq){
>> +/* nothing to do! */
>> +LeaveCriticalSection(&device->mixlock);
>> +return;
>> }
> This was removed in 8ba4090fc304993. It breaks starting the device in
> some situations (write primary mode iirc).
Writeprimary dsound tests still worked for me, I don't particulary care
though, if you want I'll zap it.
After rework fail it should no longer matter..
>> +if (native) {
>> +void *buffer = NULL;
>> +
>> +hr = IAudioRenderClient_GetBuffer(device->render, maxq
>> / block, (void*)&buffer);
>> +if(FAILED(hr)){
>> +WARN("GetBuffer failed: %08x\n", hr);
>> +LeaveCriticalSection(&device->mixlock);
>> +return;
>> +}
> I think this (mixing directly to RenderClient and skipping WaveQueue)
> could be split into a separate patch.
Hate to sound like a broken record here, but the whole mixer logic breaks if
you touch that code. :/
>> hres = IAudioClient_Initialize(device->client,
>> AUDCLNT_SHAREMODE_SHARED, AUDCLNT_STREAMFLAGS_NOPERSIST |
>> -AUDCLNT_STREAMFLAGS_EVENTCALLBACK, prebuf_rt, 0, device->pwfx,
>> NULL);
>> +AUDCLNT_STREAMFLAGS_EVENTCALLBACK, 80, 0, device->pwfx,
>> NULL);
> ...
>> +frames = (UINT64)device->pwfx->nSamplesPerSec * 80 / 1000;
> Could you #define the 80?
This is a very temporary solution as that call should not fail, and the branch
will be killed off in the rework fail patch,
where it'll be treated like any other error.
As such the only place to get that variable would be IAudioClient::Initialize,
which I think would be overkill to #define somewhere,
the rest will just use buffer length as returned by the driver, instead of
making a temporary guess.
> Anyway, I gave it a test on ALSA+Pulse and didn't find any issues.
> I'll test the other backends when you resubmit.
>
> Andrew
>
Re: dsound: use event based threads, v2
Op 21-12-12 18:44, joerg-cyril.hoe...@t-systems.com schreef: > 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? > GetPeriod for period, and StreamLatency for buffer and queue sizes? Because the timeout is not meant to be something that normally should ever be hit normally, it's just an upper bound on how long we would be prepared to wait in case something does mess up. > >> In my rework, I try to write at most 3 * GetStreamLatency, so even if for >> some >> reason no event is ever delivered, you would never get an underrun. > I'm sorry to disagree, but I've conducted numerous tests last night. > The results are very disappointing, but I'll only find time in January > to write more about it. > > Basically, no trick in DSound or Winmm whatsoever can prevent an underrun. > The typical Linux machine can and will not schedule arbitrary threads that > are ready to run, and I observed arbitrary pauses of 12-120ms. :-( > > How much was wake up delayed? For lovers of histograms: sort -n delays | uniq > -c > period 20ms10ms > 57 0 828 0 > 41 1 202 1 >2767 2 2771 2 > 541 3 185 3 > 258 4 1956 4 > 6 5 16 5 > 22 6 13 6 > 5 71 7 > 1 8 10 8 > 2 92 9 > 11 10 3 10 > 4 11 > 1 12 9 12 > 1 13 1 13 > 2 14 > 1 16 > 1 18 > 1 34 > 1 88 > 1 119 >3716 samples 6005 > > - Even if mmdevapi SetEvent's your thread, there's no guarantee that > it gets scheduled without or with little delay. > - Above data is for one thread. As multiple threads are > involved in producing audio, delays accumulate. > - Even if the DSound thread always gets to run and Release's data, there's no > guarantee that the winealsa.drv thread does and sends data to ALSA. > - Worse, even if the winealsa thread gets to run, there's no guarantee *AT > ALL* > (and I've seen it happen) that it won't lose CPU for over 20ms even if > calling > nothing but snd_pcm_* (and TRACE) in the callback. > > As a consequence, the current winealsa.drv can, by design (ALSA buffer holding > no more than 3 periods), not prevent underruns, no matter how much you kick > it. It's holding 8 periods, it just refills a maximum of 3 periods at a time. With a timeout upper bound of 2.5 periods, it would keep up on average even if nothing is moving forward.. > You advertised RT priorities. With them, the picture would look different of > course. > A faster machine helps too... I never looked at winealsa, I'm scared by the memory allocations in dsound inside the mixer thread, instead of just allocating some upper bound, so I never wanted to see closely at how the rest of the stack behaves.. Not sure what winealsa thread is actually doing, but it should really just do as little as possible, and if it keeps any locks, all other paths that could end up taking the same locks should be audited in a similar way with suspicion. Even if it's not actually elevated to rt , it should act as though it is, since any improvements also benefit upper bound without -rt.. > In January, I'll write more, e.g. about concrete changes in code. > > BTW, yesterday I replaced the timer queues in winealsa with an own thread. > Timing is much better, but that doesn't prevent delays. More changes > are needed to improve the situation. > It would also be interesting if you have any suggestions on how to improve winepulse, and if there are still outstanding differences wrt to native mmdevapi. With that latency fix I may look into enabling exclusive mode again, as it was probably hit extra hard by that pulseaudio bug. ~Maarten
Re: dsound: use event based threads, v2
Op 21-12-12 11:59, joerg-cyril.hoe...@t-systems.com schreef: > 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 call SetEvent, I wonder why you insist > on using GetStreamLatency as the basis of your timeout computations > instead of GetDevicePeriod. > > You know that wineXYZ.drv use the device period as the basis for their > SetEvent, thus IMHO the timeout too should be based on it, instead > of a GetStreamLatency we know next to nothing about. > > If you visit testbot jobs 23521 and 23514, you'll see that I've > measured the event rates. Sadly, all testbot VMs report a > GetStreamLatency of 10.ms too close to the DefaultPeriod of > 10.ms to tell for sure which is used as the average period. > Because I'm using it later on in the rework to tell how much to queue. In my rework, I try to write at most 3 * GetStreamLatency, so even if for some reason no event is ever delivered, you would never get an underrun. This is why I choose streamlatency instead of getdeviceperiod. Also since it may be a different value, who says it's only going to be bigger than the default period? It could theoretically be smaller, still.. ~Maarten
Re: winepulse test data review
Op 04-12-12 14:28, joerg-cyril.hoe...@t-systems.com schreef: > 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 something about the scheduling throwing it off. > There's a perfectly simple explanation of this that applies to both winepulse > and winecoreaudio. > It goes as follows. > > IOW, there's a bug in winecoreaudio. It may explain why the test stutters on > my MacOS 10.5.8 machine, > regardless of how accurate or "improved" GetPosition is. > > winecoreaudio's IAC_ReleaseBuffer sends packets off as soon as it receives > data, unlike winealsa/wineoss. > > Consider the sleep sequence 0 5 8 0 5 ms... > > + The transition 8 -> 0ms sleep is fine, as data is sent 2ms after the prior > packet > > - The transition 0 -> 5 is most problematic, as it means that 2 ReleaseBuffer > will be 15ms apart, even though only 10ms of data was sent. > > I believe winepulse is affected by this too, like winecoreaudio. > > The stable sequences "always 0" or "always 8ms sleep" are paced regularly, so > underruns > are avoided as long as the OS schedules the threads soon enough. > > > Winealsa and wineOSS are not affected, as they write data on the 10ms period > boundaries, > -- like native presumably does. > > > winecoreaudio solution paths: > - write packets on period tick, not at release time > - or add silence lead-in > - or delay first packet until period tick only (if small) > - or ... > > I think it should be possible to produce reliable continuous sound in > winepulse and winecoreaudio > yet maintain their current "send packet" codebase instead of transitioning to > a separate buffer > that winealsa and wineoss use. > Actually, Arun Raghavan found this thread and pointed me towards updating pulseaudio, it seems it was a bug in pulseaudio fixed in 3.0: Op 20-12-12 12:43, Arun Raghavan schreef: > Hi Maarten, > While following some random thread, I cam across this: > > http://www.winehq.org/pipermail/wine-devel/2012-December/098008.html > > I see you mention: > > """ > I may also be hitting some pulseaudio bug though, if I play some music on the > background when one > of those tests start the sound during the test works ok, even if I pause it > after that. > """ > > We recently fixed a bug where pausing and resuming a stream could end up > adding a hidden latency to the stream, and this would not happen if > another stream was playing. The fix is in 3.0, so if this is what you > were referring to, might be worth trying with newer PA. This does make my life a lot easier though, as finding a way to only queue on multiple of periods was giving me a headache, results from 10 seconds now: render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9983ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9990ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -682 frames at 44100 worth 9995ms in 9986ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -724 frames at 44100 worth 9994ms in 9987ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -881 frames at 44100 worth 9990ms in 9984ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -767 frames at 44100 worth 9993ms in 9989ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -441 frames at 44100 worth 1ms in 9991ms render.c:2238: Should play 1000ms continuous tone with fragment size 441. render.c:2290: Released 441441=1001x441 -882 frames at 44100 worth 9990ms in 9988ms render: 41019 tests executed (0 marked as todo, 0 failures), 0 skipped. I would be interested in the exact commit though, so I can get it backported to precise/quantal, from ubuntuforums' winepulse thread it seems I'm not the only one that might have been hitting this problem. ~Maarten
Re: [PATCH] dsound: Use event based threads
Op 04-12-12 17:26, joerg-cyril.hoe...@t-systems.com schreef: > 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 mmdevapi claims a 10ms period, it ought to behave like a > native shared mode driver with a 10ms period. > > IOW, I expect 10ms decreases of padding from winealsa when it claims a 10ms > period, > even if dmix/ALSA uses 21.333ms, PA-ALSA uses 50ms or Jack-ALSA uses 150ms. > > That means winealsa needs more polish... > > I talked about this decoupling between the app <-> mmdevapi <-> ALSA/OSS/XY > some time ago in wine-devel. I still believe this is less prone to app bugs > than to have > mmdevapi publish the period of 20, 50 or 150ms of its back-end, because no > native app > was ever tested with such periods. MS apps are not prepared for them. [Citation needed] Now if you were talking about the IAudioClock, and preferably have some good tests that fail with current winepulse, I would believe you. > If you think that's not a good path to go, please raise your voice. VERY LOUDLY! > (Some may argue that winecoreaudio has been using 20ms since day 1, not 10ms. > Maybe that's close enough. > OTOH, I've mentioned today that my Mac machine stutters at the render test, > so wineCoreAudio is not yet in its best shape). I haven't looked at winecoreaudio at all. > >> GetStreamLatency is also used for calculating the period size, see > http://msdn.microsoft.com/en-us/library/windows/desktop/dd370874%28v=vs.85%29.aspx > "clients can use this latency value to compute the minimum amount of data > that they can write during any single processing pass." > That one paragraph is indeed interesting. I have no explanation of it yet. > What's true is that 10ms won't get you far when the back-end's period is 20, > 50 or 150ms. > However, I was talking about a continuous supply of 10ms chunks. > > (We are already past the ancient bug that "ALSA/dmix won't start if not fed at > least one ALSA period full of samples" - imagine the period were 150ms.) Or it sometimes refuses to flush the last remainder for writing.. if it's less than 1 period. > >> I don't think it's used as such in this commit yet, but in the mixer >> rework it's used it to calculate fragment length. > I'm not familiar with DSound. For sure, GetStreamLatency > should be involved in buffer size calculations, e.g. as a lower limit. Indeed! :D >>> have dsound call into the system openal to perform multichannel mixing and >>> 3D processing. (...) >> ... Must print this out on poster format, and frame this above my bed.. > This must sound like going a full circle to you. Wasn't some earlier version > of DSound and/or mmdevapi > based on OpenAL until some devs concluded that it was not a viable path? > > >> Except WAIT_OBJECT_0 is defined as 0. > I don't want to remember that. > You're now never going to forget that WaitForSingleObject and WaitForMultipleObjects with any=true returns the index of the first waited on event. ;-) ~Maarten
Re: [PATCH] dsound: Use event based threads
Op 03-12-12 17:59, Andrew Eikum schreef: > (...) I think the best solution is to have dsound call into the system > openal to perform multichannel mixing and 3D processing. (...) > > Andrew ... Must print this out on poster format, and frame this above my bed.. ~Maarten
Re: [PATCH] dsound: Use event based threads
Op 03-12-12 14:59, joerg-cyril.hoe...@t-systems.com schreef: > 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.. */ >> +ret = WaitForSingleObject(dev->sleepev, dev->sleeptime); > How does that comment help the reader of the code? > >> +if (period_ms <= 15) >> +device->sleeptime = period_ms * 5 / 2; >> +else >> +device->sleeptime = period_ms * 3 / 2; > I expect such threshold functions to be continuous or at least monotonic. > A sawtooth is certainly unexpected. What is its purpose? > > What I would understand is a comment in the code saying that as of 2012, > all 3 wine*.drv mmdevapi drivers have a bug that they stop sending events > after IAudioClient_Stop. Therefore add a short timeout to the wait. Yeah, but in a followup commit I'm going to stop sending IAudioClient_Stop entirely. :-) > If that's the reason for the timeout, then period_ms * 1.5 is > perfectly fine. There's no reason for a particular threshold. Note > that neither 1.5 nor 2.5 give you regular spacing around the time of > transition from playing to stopped. I just didn't want to make the timeout too short in case no processing is done yet. Alsa's native period is ~ 22ms (1024 samples / 44100 or 48000) with dmix despite claiming it to be otherwise.. I thought about doing something more complicated to make it smoother, but I'm really just increases it >2 buffers to compensate for jitter on lower latencies, so if it the timeout would be beyond 20 ms I don't care any more.. > > +IAudioClient_GetStreamLatency(device->client, &period); > +period_ms = (period + ) / 1; > If IAC_Stop is the reason for the sleep time out, then it's obvious > that GetStreamLatency has no business here, rather than the device period. > > > I could understand a use of GetStreamLatency when it comes to computing > a reasonable size of the primary buffer. Got it right.. and this is a perfect valid use of IAudioClient GetStreamLatency here, the device could also be dead (AUDCLNT_E_DEVICE_INVALIDATED), in which case events are probably not fired any more. GetStreamLatency is also used for calculating the period size, see http://msdn.microsoft.com/en-us/library/windows/desktop/dd370874%28v=vs.85%29.aspx I don't think it's used as such in this commit yet, but in the mixer rework it's used it to calculate fragment length. > > + ret = WaitForSingleObject(dev->sleepev, dev->sleeptime); > + ... if (ret) > WaitFor* return values are defined in terms of WAIT_OBJECT_0, WAIT_TIMEOUT > and WAIT_FAILED etc., not zero or non-zero. Except WAIT_OBJECT_0 is defined as 0. > >> + device->sleepev = CreateEventW(0, 0, 0, 0); >> + device->thread = CreateThread(0, 0, DSOUND_mixthread, device, 0, 0); > I haven't checked the overall style of DSound, but I prefer FALSE and > TRUE be used for things advertised as BOOL. > (I tend to write NULL for null pointer initialisation. > Note that I easily read "if (foo) ..." for boolean and pointer types; > I don't expect "if (foo == TRUE) or (foo != NULL) ...") > > > BTW, I still believe that mixing and resampling would find their best place > in mmdevapi, not DSound. Well some way for dsound and winmm to use them both, so winmm can do resampling internally.
Re: winepulse test data review
Op 03-12-12 15:42, joerg-cyril.hoe...@t-systems.com schreef: > 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 MS-Excel analysis of mine. > Here are my observations. > > >> Exclusive mode tests aren't done, I disabled exclusive mode >> because I felt tests were insufficient. > It's funny that you say this, because your winepulse driver behaves > much like an exclusive mode driver, not a shared mode one ;-) > > More specifically, > > a) winepulse and exclusive mode do not decrease padding in multiples >of the period size. It typically will keep it in multiples if pulseaudio is run in timer driven mode (glitchfree audio), however if you create a buffer that's 2x period size or less it seems to be more aggressive with updates. > b) winepulse and exclusive mode appear to equate > GetPosition with released frames minus GetCurrentPadding > exactly like ALSA hw:0 and dmix do: > delay + avail_update = buffer_size (~= 8192 frames) > > IOW, the driver pretends that the speaker position is exactly the > frame that just fell off the circular buffer. This may be ok for ALSA > hw:0 and MS-Windows exclusive mode drivers, but that's wrong for > anything with a filter chain in the back. > > Hence I assume that winepulse's GetPosition is lying. > The question is: does it matter? Well from how I understand with winepulse pulseaudio will only add 1 more period on top of that. I do or did have code for IAudioClock::GetPosition, winepulse v18 commit removed it entirely. I could reinstate it, but I didn't find the mmdevapi tests strict enough to justify it. > If using PA API calls of some sort, you manage to keep the PA-internal > latency well below what's the human brain can perceive, I'd say that's > ok. Likewise, hw:0 ignores Digital->Analog and wire->LC->speaker times. > > Our gripe with PA is precisely that using the regular ALSA->PA path > via the ALSA plugin, nobody found a means to keep PA's latency small. > > (I'll repeat myself saying that what actually matters is the sum of all > latencies and buffers: mmdevapi buffer, PA transformation chain, DAC etc.) > > The caveat is that with increasing latency, the behaviour of GCP and > GetPosition will differ more and more from native's mixer, until > it becomes too much for application X to bear, causing a bug report. > > > 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 period, it's > presumably good enough. By contrast, native's largest delta is < 1ms. Delta shouldn't be so high, are you using the timestamps from IAudioClock2::GetPosition ? Those are lies, I could probably fix that by recording them in pulse_wr_callback. But you could try testing with my tree, I enable rtkit in there which should decrease jitter regardless. >> Sometimes up to 2 tests fail due to position updates not being regular, > Indeed, the data reveals it. I guess the reported GetPosition is more > related to > packet size job completion than actual sample accurate stream position. >> I suspect this is because it's nearly done playing though, but it can get >> worse >> when you use usb headphones, not much I can do about that though, except if I >> started lying, > What do you mean with "started lying"? I inferred above that it's already > lying. Not directly passing the value in GetCurrentPadding through as was reported by pulseaudio, but hide the irregular pointner advancements. I prefer to just report the values from pulseaudio directly. >> but it's so far been much simpler when I don't.. > The data points look very reasonable -- if audible latency is really > low, which the tests cannot reveal. > > > BTW, I'd really like to see native test results with a USB headphone. > IF somebody has such data, pleas show them to me. Unless I'm mistaken, because I use early requests, pulseaudio will only have 1 more period internally than the buffer length of my sound buffer, so if the buffer is 30 ms, period is 10 ms, and I only fill it with 10 ms data, max latency would be 20 ms at that point. If you say jitter is 8 ms (which I find very high), you wouldn't notice that extra 10 ms.. > > I'm not saying that it's bad that
Re: [PATCH] dsound: Use event based threads
Op 21-11-12 19:16, Maarten Lankhorst schreef: > Signed-off-by: Maarten Lankhorst > Bump, anything wrong with this patch?
Re: [PATCH 3/6] dsound: create a primary_pwfx separately from pwfx
Hey, Op 19-10-12 15:29, Andrew Eikum schreef: > Patches 1 and 2 in this series look fine. > > I have a series of patches similar to this one in my dsound > multichannel branch. This patch seems to do too much at once. > > When I did this cleanup, I split it up into four patches: > 1) Allocate the device format in the Device struct > 2) Load the default format from the IAC, not hard-coded in dsound > 3) Put SetFormat() calls into their own WFX that we don't really care > about > 4) Always use WAVE_FORMAT_EXTENSIBLE for the device format Tried to revisit it and split it up, but there's no sense in keeping it separate. It's in fact quite impossible to do so because of how dsound works. What I'm doing is the smallest possible thing that makes sense. I want to have writeprimary mode separately, so the commit does pretty much that. When toggling writeprimary mode you reopen the device, those parts are in dsound.c, and you need to change the wave format. Those parts in primary.c do that. It may look like a patch, but all the parts are needed. Splitting this up will just break it, or end up with something that doesn't make sense, some of the changes look big but it's not that big a change. 1. DSOUND_ReopenDevice format changes: - 3 cases, in !writeprimary mode it tries to allocate GetMixFormat as float, and clips channels to 2. If writeprimary, it will try to allocate a waveformatextensible for PCM and IEEE float if possible, and use that. If not possible, it just copies format unmodified. Then calls isformatsupported to get the proper format, and initializes with that. 2. primarybuffer_SetFormat changes: - some removal of code, if !writeprimary, format is not modified, but copied from the internal format instead. if writeprimary, device is reopened like before. Some format recalculations have been moved to PrimaryOpen. 3. SetCooperativeLevel changes: - Just reopen device when toggling writeprimary, straightforward. I would love to split this patch up further, but I ended up with patches that didn't make sense from that. ~Maarten
Re: DSound/winepulse review
Added wine-devel to cc Op 26-10-12 13:12, joerg-cyril.hoe...@t-systems.com schreef: > Maarten, > > I'll try and come up with a review of your winepulse patches yet I'm not > familiar with the PA API. > > Regarding your dsound ones, I'm sorry I've not enough experience > with the DSound API to be really useful. I was happy that Alexey Loukianov > and A.Eikum > worked on DSound. > > One issue that struck me is the 5ms period downgrade in winepulse. > I advise you keep that as a separate patch. Halving the externally visible > SetEVentHandle rate > is certainly not something that should be in the one big core patch > introducing winepulse. Yeah this was explicitly to make skyrim work better, I return the updated latency in GetStreamLatency, and with the fixes wine dsound uses that value for calculating mixing fraglen. > Even if it causes no test failure, that trick would certainly be visible in > the log lines. Native shows: > render.c:2084: Should play 1000ms continuous tone with fragment size 480. > render.c:2136: Released 48000=100x480 -960 frames at 48000 worth 980ms in > 1008ms Yeah I seem to fire more events, so less data gets played. This requires some rethinking though, winepulse doesn't attempt to hide latency at all, and so far the mmdevapi tests have failed on my usb headphones because it didn't always have a smooth buffer increment. The tests don't fail, but because of the extra firing processing sometimes gets skipped.. Woops, some more digging revealed I also seemed to have done a SetEvent in pulse_started_callback, which is entirely bogus, presumably a leftover from before I hooked up the latency callback for when in underrun mode. With that SetEvent part of the latency hack disabled and the bogus SetEvent removed, I get: render.c:2127: Released 44541=101x441 -441 frames at 44100 worth 1000ms in 1003ms Can't get better than that. :-) I disabled the exclusive mode on winepulse because I felt that mode was sufficiently different in behavior, and I don't think the mmdevapi tests cover it properly. I'll do some more digging if the SetEvent is still needed for the hack, or if the period lowering is enough. I would suspect lowering the period is sufficient now. Quick testing of skyrim seems to indicate I can leave the SetEvent part out, so I pass all tests properly again. :-) > BTW, I'd still be pleased if you could upload somewhere to bugzilla results > from > runtest -v -i mmdevapi/render and capture > from your winepulse driver. I think I asked you that favour already but found > nothing. My tree removes todo_wine from the tests, but anyway: capture.c:501: Returned periods: 10. ms 0.4988 ms capture.c:513: pwfx: 0xdccb0 capture.c:514: Tag: fffe capture.c:515: bits: 32 capture.c:516: chan: 2 capture.c:517: rate: 44100 capture.c:518: align: 8 capture.c:519: extra: 22 capture.c:524: Res: 32 capture.c:525: Mask: 3 capture.c:526: Alg: FLOAT capture.c:585: Returned latency: 10. ms capture.c:185: Wait'ed position 0 pad 0 flags 0, amount of frames locked: 441 capture.c:247: Sleep.1 position 441 pad 15435 flags 0, amount of frames locked: 441 capture.c:291: GetBufferSize 22050 period size 441 capture.c:301: Overrun position 1323 pad 22050 flags 1, amount of frames locked: 441 capture.c:328: Cont'ed position 1764 pad 21609 flags 0, amount of frames locked: 441 capture.c:352: Restart position 2205 pad 21168 flags 0, amount of frames locked: 441 capture.c:383: Reset position -1 pad 0 flags abadcafe, amount of frames locked: 0 capture.c:409: Running position 23373 pad 7938 flags 0, amount of frames locked: 441 capture: 255 tests executed (0 marked as todo, 0 failures), 0 skipped. render.c:185: Returned periods: 10. ms 2. ms render.c:197: pwfx: 0xdccb0 render.c:198: Tag: fffe render.c:199: bits: 32 render.c:200: chan: 6 render.c:201: rate: 48000 render.c:202: align: 24 render.c:203: extra: 22 render.c:208: Res: 32 render.c:209: Mask: 3f render.c:210: Alg: FLOAT render.c:268: Initialize(duration=0) GetBufferSize is 192 render.c:333: Returned latency: 10. ms render.c:411: IsSupported(shared , 8000x 8x1) render.c:411: IsSupported(shared , 8000x 8x2) render.c:411: IsSupported(shared , 8000x16x1) render.c:411: IsSupported(shared , 8000x16x2) render.c:411: IsSupported(shared , 11025x 8x1) render.c:411: IsSupported(shared , 11025x 8x2) render.c:411: IsSupported(shared , 11025x16x1) render.c:411: IsSupported(shared , 11025x16x2) render.c:411: IsSupported(shared , 12000x 8x1) render.c:411: IsSupported(shared , 12000x 8x2) render.c:411: IsSupported(shared , 12000x16x1) render.c:411: IsSupported(shared , 12000x16x2) render.c:411: IsSupported(shared , 16000x 8x1) render.c:411: IsSupported(shared , 16000x 8x2) render.c:411: IsSupported(shared , 16000x16x1) render.c:411: IsSupported(shared , 16000x16x2) render.c:411: IsSupported(shared , 22050x 8x1) render.c:411: IsSupported(shared , 22050x 8x2) render.c:411: IsSupported(shared , 22050x16x1) render.c:411: IsSupport
Re: [PATCH 5/6] dsound: rework ugly mixer logic
Op 24-10-12 12:52, joerg-cyril.hoe...@t-systems.com schreef:
> 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 observations.
>
> Where do the 5ms come from? What's the relationship with the 36ms latency?
Well skyrim is pretty aggressive with its low latency. It seems to want to
buffer 20 ms only when default period is 10 ms, but when I did a bunch of
tests with tons of underruns my minimum and default period ended up at 36 ms,
skyrim still ran correctly, and looking at 'pacmd list-sink-inputs' it just
increased buffer length in that case.
> You patch DSound so I assume that Skyrim uses DSound, not mmdevapi
> directly. Shouldn't DSound export capabilities that make sense given
> its abstraction? IIRC, there's some former mailto wine-devel or bug
> report where I talked about the alternating period-sized buffer
> abstraction that is underlying DSound's API and how all positions
> being reported modulo buffer size are problematic if someone misses
> the period intervals.
Nah, originally when I started hacking on dsound I assumed skyrim was using
dsound, but it's only used for the intro. I'm running the Skyrim steam
version with windows set to win7.
I'm not sure yet how dsound should be fixed on bigger periods, I believe using
IAudioClock for reporting position *might* be the correct answer, but it's not
properly test yet on behavior, so I chose for the simple solution of directly
reporting next mix position as play pos, which is the same as current code.
> Of course, that abstraction cannot explain a 36ms latency with two
> alternating period-sized "direct hardware" buffers of 5ms.
Indeed, skyrim was creating the 20 ms buffer directly, and allocating a bigger
buffer didn't help. So instead when an application requests 2 default periods
I try to set latency to half requested period (5 ms instead of 10ms) and I'm
more
aggressive about firing events when data can be written. Pulseaudio seems to
behave differently at lower latencies though, pointer updates are no longer
done at a fixed size, presumably because it puts pulseaudio in a real danger
of underruns so it mixes as much as it can each pass.
> Wine's DSound must maintain a set of mutually consistent variables
> { play position, write position, buffer size, period size }
> that in addition need to make sense w.r.t. audio output.
> I'm not convinced that it does. There should be tests to verify that.
run the dsound tests with WINETEST_INTERACTIVE=1.
> In particular, wine's DSound must not let play position leave the virtual
> DSound
> buffer, even if mmdevapi reports that it's 2 seconds behind with PulseAudio.
> (IMHO, should that happen, then DSound must cap the reported position).
At the point dsound queues the data to mmdevapi it can no longer do anything
about it, so instead of trying something more complicated the best way to deal
with it is to accept that fact and keep queued latency as fixed as possible,
and ideally small.
I create a 80 ms buffer, please read msdn's documentation of
iaudioclient::initialize,
the requirements for shared mode is that it will create a buffer that's at
least that
large to prevent underruns, so if a 2 second buffer is created as a result, then
somehow the audio system believes we should buffer 2 seconds. Not much we can
do about
that, and according to docs looks like we should keep the buffer as filled as
possible
in that case. However I believe that this is unlikely happen, and more likely
we end
up with only having to buffer a fixed 80 ms.
80 ms is generous btw, if you're feeling lucky you can set dsound latency much
lower,
40 ms buffering would probably be the lowest safe value, but if you're feeling
adventerous initialize buffer length to 100 ns and get the driver to come up
with
the minimal period and buffer length it supports. But things do seem to break
down when you go that low. Pulseaudio got angry at me for those underruns
and increased minimum latency to 8 ms after I did some testing at sub 1 ms
buffers.
:-(
> (BTW, I'd find it easier for Wine if DSound's primary were equal to mmdevapi's
> buffer, except that with winecoreaudio, there's no such mmdevapi buffer...)
I've been doing some cleanups and there's really no need to do this. I handled
the
primary buffer mixing as a special case of secondary buffer and it works just
fine. The
idea behind my patches has been to simply remove primary buffer altogether, as
far as
possible. device->buffer is equal to primary buffer size in
Re: [PATCH 5/6] dsound: rework ugly mixer logic
Op 19-10-12 15:54, Andrew Eikum schreef:
> Mostly good cleanup in this one. Some thoughts below...
>
> On Tue, Oct 16, 2012 at 02:06:29PM +0200, Maarten Lankhorst wrote:
>> diff --git a/dlls/dsound/dsound_private.h b/dlls/dsound/dsound_private.h
>> index feef787..7817b88 100644
>> --- a/dlls/dsound/dsound_private.h
>> +++ b/dlls/dsound/dsound_private.h
>> @@ -73,10 +73,8 @@ struct DirectSoundDevice
>> -DWORD writelead, buflen, state, playpos, mixpos;
>> +DWORD writelead, buflen, aclen, fraglen, state,
>> playpos, pad;
> If you're introducing new variables, surely you can come up with
> something more descriptive than "aclen." Something like
> "ac_buffer_frames," maybe? I'm a big fan of units on my variable
> names so mistakes like "pos_bytes = ac_frames;" are obvious.
>
> Similar for "pad," maybe something like "in_mmdev_bytes" (Is that
> actually used any more after your patches? You could re-use it if
> not.)
However what I do makes sense here, since all of the units in dsound right
now are bytes, unless that gets changed. So I stick to them.
I'm all for changing it to frames, but it was out of the scope for this patch.
If you want to do it like that it's better to go all the way and introduce
helpers
for all of wine's drivers and dsound/winmm to use instead. This would improve
readability a lot more instead of reinventing the wheel everywhere..
And.. get out of my bikeshed!
>> @@ -209,7 +207,6 @@ HRESULT DSOUND_PrimaryCreate(DirectSoundDevice *device)
>> DECLSPEC_HIDDEN;
>> HRESULT DSOUND_PrimaryDestroy(DirectSoundDevice *device) DECLSPEC_HIDDEN;
>> HRESULT DSOUND_PrimaryPlay(DirectSoundDevice *device) DECLSPEC_HIDDEN;
>> HRESULT DSOUND_PrimaryStop(DirectSoundDevice *device) DECLSPEC_HIDDEN;
>> -HRESULT DSOUND_PrimaryGetPosition(DirectSoundDevice *device, LPDWORD
>> playpos, LPDWORD writepos) DECLSPEC_HIDDEN;
> Good riddance.
>
>> @@ -682,147 +623,100 @@ static void DSOUND_PerformMix(DirectSoundDevice
>> *device)
>> LeaveCriticalSection(&device->mixlock);
>> return;
>> }
>> -
>> -to_mix_frags = device->prebuf - (pad * device->pwfx->nBlockAlign +
>> device->fraglen - 1) / device->fraglen;
>> -
>> -to_mix_bytes = to_mix_frags * device->fraglen;
>> -
>> -if(device->in_mmdev_bytes > 0){
>> -DWORD delta_bytes = min(to_mix_bytes, device->in_mmdev_bytes);
>> -device->in_mmdev_bytes -= delta_bytes;
>> -device->playing_offs_bytes += delta_bytes;
>> -device->playing_offs_bytes %= device->buflen;
>> +block = device->pwfx->nBlockAlign;
> Bleh. Do we really need to alias that?
It's my bikeshed to paint! :P
Followup patch I didn't send in yet on removed this entirely and just
consolidated both cases.
>
>> +if (maxq > device->fraglen * 3)
>> +maxq = device->fraglen * 3;
>> +
> This seems to be replacing ds_snd_queue_max, right? Why remove the
> configurability? Why 3 instead of the old default of 10? This should
> be a separate patch at least.
No this does not replace ds_snd_queue_max, I always fill up the buffer to full,
but I'm supposed to get a event every period, so instead of always filling the
buffer to full I spread it out over multiple periods so hopefully applications
have some time to catch up. This gets rid of clipping at the start.
See also below why..
>> +writepos = (device->playpos + pad) % device->buflen;
>>
>> if (device->priolevel != DSSCL_WRITEPRIMARY) {
>> -BOOL recover = FALSE, all_stopped = FALSE;
>> -DWORD playpos, writepos, writelead, maxq, prebuff_max,
>> prebuff_left, size1, size2;
>> -LPVOID buf1, buf2;
>> +BOOL all_stopped = FALSE;
>> int nfiller;
>> +BOOL native = device->normfunction == normfunctions[4];
>> +DWORD bpp = device->pwfx->wBitsPerSample>>3;
> Again, do we need to alias that?
A followup patch removes it entirely and just mixes directly to the buffer for
the native
case (most common, only oss4 and (maybe, just guessing?) coreaudio don't support
float, so I didn't want to touch that case even more.
>> -static DWORD DSOUND_fraglen(DirectSoundDevice *device)
>> -{
>> -REFERENCE_TIME period;
>> -HRESULT hr;
>> -DWORD ret;
>> -
>> -hr = IAudioClient_GetDevicePeriod(device->client, &period, NULL);
>> -if(FAILED(hr)){
>> -
Re: [PATCH 5/6] dsound: rework ugly mixer logic
Op 22-10-12 17:42, Andrew Eikum schreef: > On Sat, Oct 20, 2012 at 12:03:55AM +0200, Maarten Lankhorst wrote: >> Op 19-10-12 15:54, Andrew Eikum schreef: >>> Mostly good cleanup in this one. Some thoughts below... >>> >>> On Tue, Oct 16, 2012 at 02:06:29PM +0200, Maarten Lankhorst wrote: >>>> diff --git a/dlls/dsound/dsound_private.h b/dlls/dsound/dsound_private.h >>>> index feef787..7817b88 100644 >>>> --- a/dlls/dsound/dsound_private.h >>>> +++ b/dlls/dsound/dsound_private.h >>>> @@ -73,10 +73,8 @@ struct DirectSoundDevice >>>> -DWORD writelead, buflen, state, playpos, mixpos; >>>> +DWORD writelead, buflen, aclen, fraglen, state, >>>> playpos, pad; >>> If you're introducing new variables, surely you can come up with >>> something more descriptive than "aclen." Something like >>> "ac_buffer_frames," maybe? I'm a big fan of units on my variable >>> names so mistakes like "pos_bytes = ac_frames;" are obvious. >>> >>> Similar for "pad," maybe something like "in_mmdev_bytes" (Is that >>> actually used any more after your patches? You could re-use it if >>> not.) >> However what I do makes sense here, since all of the units in dsound right >> now are bytes, unless that gets changed. So I stick to them. >> I'm all for changing it to frames, but it was out of the scope for this >> patch. >> > Fair enough, I hadn't thought of that. I still think "aclen" is a > crummy name :P > >> And.. get out of my bikeshed! >> > Well, it does lead to errors (bbbf72ddcb1202) and I don't see any harm > in being explicit. It'll future-proof it, in case future variables > have some other unit. > > In any case, not a patch-killer, of course. > >>>> + block = device->pwfx->nBlockAlign; >>> Bleh. Do we really need to alias that? >> It's my bikeshed to paint! :P >> > My objection is it makes the code harder to read, which is something > we really don't need in dsound. For an even worse example, see the > w/wi/wfe/wfe2/wfe3 web in your 3rd patch. Yeah got tired of that too and fixed it in the atomic reopendevice rework, it uses better descriptions instead, and returns a newly allocated WAVEFORMATEX which is more clear for use. In this patch wfe2 is the format returned from IsFormatSupported, wfe3 is the temporary float format I use for testing. In the atomic reopendevice I thought about killing an extra copy from that step, but it's not worth it. If the allocation fails it's handled correctly, and the reallocation of device->buffer would very likely fail, too. >> Followup patch I didn't send in yet on removed this entirely and just >> consolidated both cases. >> >>>> + if (maxq > device->fraglen * 3) >>>> + maxq = device->fraglen * 3; >>>> + >>> This seems to be replacing ds_snd_queue_max, right? Why remove the >>> configurability? Why 3 instead of the old default of 10? This should >>> be a separate patch at least. >> No this does not replace ds_snd_queue_max, I always fill up the buffer to >> full, >> but I'm supposed to get a event every period, so instead of always filling >> the >> buffer to full I spread it out over multiple periods so hopefully >> applications >> have some time to catch up. This gets rid of clipping at the start. >> > Okay, thanks for explaining. I was going to give the behavior changes > a closer look after we figure out patch 3 and I get a chance to run my > tests. > That's actually the easiest patch, I pretend primary format is 22050 / 8 / 2 like windows, until setformat is called and then it copies the actual wfx from the current audioclient if priority != writeprimary, else it attempts to set it through creating a new iaudioclient with the specified format. Switching to and from primary priolevel will also re-create the audioclient, and if not writeprimary the preferred format will be float since it saves us a step in the mixer. ~Maarten
Re: [PATCH 3/6] dsound: create a primary_pwfx separately from pwfx
Hey, Op 19-10-12 15:29, Andrew Eikum schreef: > Patches 1 and 2 in this series look fine. > > I have a series of patches similar to this one in my dsound > multichannel branch. This patch seems to do too much at once. > > When I did this cleanup, I split it up into four patches: > 1) Allocate the device format in the Device struct > 2) Load the default format from the IAC, not hard-coded in dsound > 3) Put SetFormat() calls into their own WFX that we don't really care > about > 4) Always use WAVE_FORMAT_EXTENSIBLE for the device format 3 of 6 does essentially the step you call #4 and #2, other steps is just fixes I already have in my tree. Tested quite extensively too The other steps I have already done in a followup series, except #1, it's unneeded. It also breaks device->pwfx = NULL in the initial case, which is nice to see if something depends on the new format before changing over is complete. This would otherwise be very hardto detect. I'm surprised you call #2 a separate step since from what I gathered about mmdevapi is that until win7 sp1 it only supported 1 rate, and we don't implement the rate changing extension yet, so the whole popular format testing was pointless to begin with. Is there anything *technically* wrong with the patch series though? ~Maarten
Re: [PATCH 4/6] dsound: Use event based threads
Op 19-10-12 15:40, Andrew Eikum schreef:
> I like it. Before I can give a sign-off, I need to run it through my
> usual battery of tests on all the platforms. I'll do that after patch
> 3 gets figured out.
>
> Some thoughts below...
>
> On Tue, Oct 16, 2012 at 02:06:28PM +0200, Maarten Lankhorst wrote:
>> +/* ALSA is retarded, add a timeout.. */
>> +ret = WaitForSingleObject(dev->sleepev, dev->sleeptime);
> No arguments here :) but I'm curious what you mean. Presumably
> winealsa isn't sending events when it ought to? I know Jorg has
> discovered that failure, I wonder if it's worth testing and fixing
> across all the drivers.
Well I was abusing the fact that native drivers continue firing after being
stopped, I have
a followup patch which leaves IAudioClient always running unless you enter
primary mode
instead.
>> diff --git a/dlls/dsound/primary.c b/dlls/dsound/primary.c
>> index 94bdf9c..9d9fa27 100644
>> --- a/dlls/dsound/primary.c
>> +++ b/dlls/dsound/primary.c
>> @@ -170,6 +172,7 @@ HRESULT DSOUND_ReopenDevice(DirectSoundDevice *device,
>> BOOL forcewave)
>> device->pwfx->wFormatTag = WAVE_FORMAT_PCM;
>> device->pwfx->cbSize = 0;
>> }
>> +IAudioClient_SetEventHandle(device->client, device->sleepev);
>>
>> hres = IAudioClient_GetService(device->client, &IID_IAudioRenderClient,
>> (void**)&device->render);
>> @@ -203,6 +206,19 @@ HRESULT DSOUND_ReopenDevice(DirectSoundDevice *device,
>> BOOL forcewave)
>> WARN("GetService failed: %08x\n", hres);
>> return hres;
>> }
>> +/* Now kick off the timer so the event fires periodically */
>> +IAudioClient_Start(device->client);
>> +
>> +IAudioClient_GetStreamLatency(device->client, &period);
> I'm a big fan of error checking (or at least reporting), so these
> unchecked calls make me nervous. They'll probably never fail, but if
> they do, I think they should fail loudly.
>
Erm, dsound at this point will be worse off if you perform error reporting here
than fail silently.
It leaves a bigger mess since ReopenDevice is not atomic right now..
I do have a followup patch for this too though but I was going to see if this
would go through
first before checking if it is worth spending more time fixing things up.
~Maarten
Re: [PATCH] winmm: Load winealsa if winepulse is found
Op 17-10-12 20:59, Austin English schreef:
> On Tue, Oct 16, 2012 at 5:10 AM, Maarten Lankhorst
> wrote:
>> From: Maarten Lankhorst
>>
>> Fixes midi on winepulse
>> ---
>> dlls/winmm/lolvldrv.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/dlls/winmm/lolvldrv.c b/dlls/winmm/lolvldrv.c
>> index f387323..3b1be27 100644
>> --- a/dlls/winmm/lolvldrv.c
>> +++ b/dlls/winmm/lolvldrv.c
>> @@ -543,7 +543,10 @@ static void MMDRV_Init(void)
>> drvA = HeapAlloc(GetProcessHeap(), 0, size);
>> WideCharToMultiByte(CP_ACP, 0, pv.u.pwszVal, -1, drvA, size, NULL,
>> NULL);
>>
>> -MMDRV_Install(drvA, drvA, FALSE);
>> +if (!strcasecmp(drvA, "winepulse.drv"))
>> +MMDRV_Install("winealsa.drv", "winealsa.drv", 0);
>> +else
>> +MMDRV_Install(drvA, drvA, FALSE);
>>
>> HeapFree(GetProcessHeap(), 0, drvA);
>> PropVariantClear(&pv);
>> --
>> 1.7.11.3
> Shouldn't this be part of the winepulse patch itself? It will never
> get used in Wine, as is...
Eventually it will, regardless of what driver will be used for it. I intend not
to make that code go unused for too long. See it as a promise.
~Maarten
Re: [PATCH] winepulse.drv: Add PulseAudio driver
Hey Joerg, 2012/6/26 : > 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. Unfortunately, none > of the two authors bothered to point me to a verbose log of the mmdevapi > tests for my scrutiny. > > The tests should pass like they do on native. > > Regarding latency, I'm not aware of a flaw in Wine's winmm. > HOWEVER, Wine's DSound needs a patch. Here the reason. > > To recap, latency is somehow related to the "distance" between what > one hears and the PCM frames sent to the device. GetPosition is the > only API call in that area in both winmm and mmdevapi. > > Buffer size is a completely different thing. I find it useful to have > in mind a cascade of audio filters performing some buffering each. > Then it's obvious that an app only sees the frontmost buffer size and > knows nothing about the others. High latencies imply that there > must be some large buffer space(s), somewhere. > > Period is an artificial entity related to how often the frontmost > buffer is drained to feed the next buffer in the chain, in case that > happens regularly. This is not guaranteed nor necessarily documented. > > You get the idea: regardless of arbitrary (front) buffer sizes and > periods not worth this name, try and send a stable flow of data to > play music without glitches and let explosions be heard ASAP. > > So far the situation, now the issue. It appears easier to write code > that provides (frontmost) buffer space behaviour similar to native than > one that provides similar latency. > > Alas, behaviour observable on MS-Windows differs from what we get with > PulseAudio and some ALSA devices. > > Tests seem to indicate a latency of around 30-70ms from mmdevapi with > MS-Windows. That good enough for games. OTOH if ALSA or PA gives us > 2 seconds on Linux, that's a big cause of trouble. The authors of MS > apps could never test them in an environment with such high latency. > What happens with software not tested? It happens not to work. > > Two solutions: > - Reduce actual latency or > - lie about latency. > > Lying about latency causes apps to loose the ability to sync audio and > video. However, given a choice between loss of lip sync and possible > crashes or other weird behaviour because an app is executed in a > environment that its developers never experienced, I consider the loss > of lip sync to be less worrying. > > We designed the winealsa driver to accomodate an arbitrary latency and > accept a large variation of periods. (Some bug report from Jack users > seem to imply that it should accept even larger periods, e.g. 150ms, > yet still pretend to use 10ms on the mmdevapi side). > > We choose to have the winealsa driver not lie about latency. That > should be left to high level APIs. > > DirectSound is built around the "Direct" HW (lack of) abstraction: a > circular buffer of samples is played by a DAC. The converted signal > is immediately sent to the speaker. Hence: > > 1. GetPosition information in the DSound abstraction translates to >a "playpos" -- well known. > > 2. No provision is made for additional buffering. The playpos must >lie within the circular buffer. The reported free (writable) space >shall never cross the playpos -- with subtle consequences. > > Wine's DSound needs a patch to ensure this second property. Given a > 80ms primary buffer, Wine's DSound must not pretend its playpos is 2 > seconds late! > > I think Wine should try and reduce latency but lie if that does not suffice. > > What's needed? > 1. Have DSound always use a buffer large enough for typical situations >(I believe 100-200ms). > > 2. Clamp the reported position such that it won't leave the (virtual) >primary buffer. As a result, DSound must pretend to play even when >Wine is solely pumping the huge 2s of cascading SW audio buffers. > > 3. Work on reducing the latency of the cascading audio filters. >That device-level work is independent on the DSound one. > > Native's 30-70ms has the benefit that it nicely fits within typical > DSound primary buffer sizes. PulseAudio's 2s does not (yet). > I believe a total 80ms latency would be acceptable with games. > > > Further areas of investigation and effort: > > - Maybe clamp latency in the mmdevapi drivers after all? After all, >huge latencies are known to cause dead-locks in apps and we don't >know what all apps or libraries built atop mmdevapi or winmm expect. >(If yes, to what value? 150% buffer size?) > > - Try and find MS setups with huge latencies. >USB headphones are said to be candidates, but I've yet to see an >excellent and trustworthy report about what happens in that case. > > - Work on reducing the cascades of audio buffers > > - Work on further decoupling m
Re: [PATCH] winepulse.drv: Add PulseAudio driver
What happened to the stamped capture buffers? Why is held_frames added? This doesn't look like an attempt to get my driver in, it looks like a rewrite by someone who doesn't understand why I made the design decisions I made for correctness. 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. The logic I kept for timestamping audio buffers was removed which just makes timestamping less accurate on capture buffers. Was this driver even tested on low latency? There was a reason I kept track of all packets in a linked list, no need to do held_frames logic. I genuinely do want a good driver to go in, but this just isn't it. There is also no reason to have an INCREASED period size for exclusive compared to shared. I'm currently not handling exclusive because there are no good tests for it. and "hooray_cb" ? If this is going to be accepted (likely, sadly) I want to have this added to the commit: Rejected-by: Maarten Lankhorst ~Maarten PS: Still sad that you chose to reject my original driver not based on any merits.
Fwd: Student Proposals Now Being Accepted for Google Summer of Code
I'm still missing some people who haven't signed up as mentor yet. To all students, I hope you discussed your ideas on the mailing list and/or irc, good luck submitting your proposal! :D Originele bericht Onderwerp: Student Proposals Now Being Accepted for Google Summer of Code Datum: Mon, 26 Mar 2012 15:27:05 -0700 Van:Carol Smith Antwoord-naar: google-summer-of-code-announce+own...@googlegroups.com Aan:Google Summer of Code Announce Hi there, We are pleased to announce that we are now accepting applications from students to participate in Google Summer of Code 2012. Please check out the FAQs [1], timeline [2], and student manual [3] if you are unfamiliar with the process. The deadline to apply is April 6, 2012 at 19:00 UTC [4]. Late proposals will not be accepted for any reason. [1] - http://www.google-melange.com/gsoc/document/show/gsoc_program/google/gsoc2012/faqs [2] - http://www.google-melange.com/gsoc/events/google/gsoc2012 [3] - http://www.booki.cc/gsocstudentguide/ [4] - http://goo.gl/xiKC2
Re: Updating GSoC proposal
Hey Jacek, Op 20-03-12 10:43, Jacek Caban schreef: > Hi all, > > GSoC is starting this year and, if we want to have good applications, we > need to update our proposals. Usually the most attention is directed > into adding new ones, while we keep obviously bad (or just bad IMO) > proposals on the page. I'm planning to remove following project proposals: > > Security - implement sandboxing > Theming - Implement Wine theming support > NTDLL - support performance registry keys > Winelib Aware Scons (or cmake) > Cleanup Winemenubuilder to support generating Application Bundles on Mac > OS X > Wine-based application virtualization > Agreed, would like to add cmd parser to that list too. ~Maarten
Fwd: [Wine (a project of Software Freedom Conservancy)] Your organization application has been accepted.
huzzah! Originele bericht Onderwerp: [Wine (a project of Software Freedom Conservancy)] Your organization application has been accepted. Datum: Fri, 16 Mar 2012 17:44:28 + Van:no-re...@google-melange.appspotmail.com Aan:m.b.lankho...@gmail.com Your Organization Application for "Wine (a project of Software Freedom Conservancy)" in Google Summer of Code 2012 has been accepted. Please click "http://www.google-melange.com/gsoc/profile/organization/google/gsoc2012?org_id=wine to fill in the necessary information and create your Organization. Best regards, Google Open Source Programs
Re: use assert etc. in Wine dlls? What is better?
Hey,
Op 13-03-12 15:05, joerg-cyril.hoe...@t-systems.com schreef:
> Hi,
>
> Maarten's wine-pulse contains several instances of assert()
> I've been thinking about adding a bit of protection against
> inconcsistencies within mmdevapi code too.
>
> There are two variants that could be applicable depending on the situation:
> /* this should not happen, but if we detect it early, we can work-around the
> situation */
> if (a > limit) { ERR("%d > %d\n", a, limit); a = limit; }
> or
> assert(a <= limit, "whatever %d", a);
>
> I'm not too fond of assert. An assert in DSound was one of my first bug
> fixes in Wine, years ago. It was not obvious why the app should not
> continue running -- perhaps without sound.
> OTOH, if an assert is violated, as a programmer, I'd like to hear about it.
>
> I found little on that topic in Wine. In 2002, Alexandre Julliard wrote:
> http://www.winehq.org/pipermail/wine-devel/2002-October/009766.html
The asserts I use are for internal consistency errors and shouldn't ever
trigger. If they do trigger something has seriously gone wrong. For
example This->pad <= This->bufsize_bytes should always hold true,
and for render in the write callback, This->pad <= oldpad should hold
true, since pulseaudio can only decrease padding. I don't even know
how to recover from this, since applications will bug if padding
somehow increases since it's behavior that should never occur.
None of the asserts should ever be triggered by misbehaving
applications, unless there's a bug in pulseaudio.
~Maarten
Re: What happens upon mmdevapi capture overrun on native?
Hey Joerg,
Op 12-03-12 11:01, joerg-cyril.hoe...@t-systems.com schreef:
> Hi,
>
>>> A. mmdevapi fills the whole buffer once.
>>> B. mmdevapi continuously overwrites the circular buffer.
>>> I think A makes sense but really I don't know.
>> I suspect B
> I realized that I don't need a microphone if I can trust
> IAC_CaptureClient's pu64QPCPosition output parameter: "the value of
> the performance counter at the time that the audio endpoint device
> recorded the device position of the first audio frame in the data
> packet."
>
> Modifying the capture tests to trace that value shows that mmdevapi
> mostly implements behaviour A with a few quirks. Please visit bug
> #30147 for details.
>
Thanks for figuring it out. winepulse v10 carries the fixed behavior,
diff with v9 attached below for completeness.
commit 9173c8dd53438eeb395ff7ac66498bdbb383474f
Author: Maarten Lankhorst
Date: Tue Mar 13 11:04:04 2012 +0100
winepulse: v10
diff --git a/dlls/winepulse.drv/mmdevdrv.c b/dlls/winepulse.drv/mmdevdrv.c
index af8a826..50dcd4a 100644
--- a/dlls/winepulse.drv/mmdevdrv.c
+++ b/dlls/winepulse.drv/mmdevdrv.c
@@ -1,4 +1,5 @@
/*
+ * Copyright 2011-2012 Maarten Lankhorst
* Copyright 2010-2011 Maarten Lankhorst for CodeWeavers
* Copyright 2011 Andrew Eikum for CodeWeavers
*
@@ -574,9 +575,11 @@ static void pulse_rd_loop(ACImpl *This, size_t bytes)
UINT32 src_len, copy, rem = This->capture_period;
if (!(p = (ACPacket*)list_head(&This->packet_free_head))) {
p = (ACPacket*)list_head(&This->packet_filled_head);
-
-next = (ACPacket*)p->entry.next;
-next->discont = 1;
+if (!p->discont) {
+next = (ACPacket*)p->entry.next;
+next->discont = 1;
+} else
+p = (ACPacket*)list_tail(&This->packet_filled_head);
assert(This->pad == This->bufsize_bytes);
} else {
assert(This->pad < This->bufsize_bytes);
Re: What happens upon mmdevapi capture overrun on native?
Hey Joerg, Op 09-03-12 17:46, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote in winepulse: Add pulseaudio driver, v9: >> - Reworked capture logic to always capture, since that seems to be the case >> on windows, >> when stopped we simply drop whole packets, but keep firing the event. > Does anybody know what precisely happens upon overrun during capture? > > A. mmdevapi fills the whole buffer once. It keeps firing events and >sets the DISCONTINUITY flag upon the next CaptureClient_GetBuffer. >This is like mciwave's "record from 0 to 5000" command. >The client can read the oldest recorded samples. > > B. mmdevapi continuously overwrites the circular buffer. It keeps >firing events and sets the DISCONTINUITY flag too. The client gets >to see the newest recorded samples. It's like your TV recorder's time >shift function that can only travel back by as much as the buffer holds. > > C. Other, e.g. mixing newest with older packets (current winealsa). > > In other words, what data does the dlls/mmdevapi/capture test see in: > http://source.winehq.org/source/dlls/mmdevapi/tests/capture.c?v=wine-1.4-rc6#L305 > > I think A makes sense but really I don't know. The tests show a > position jump by one period worth of frames when reading the next > packet after an overrun. That's not what I'd expect from behaviour A. > But from behaviour B I'd expect a much larger position jump, as large > as elapsed time. > I suspect B, the position jump makes sense in that case, because if you compare it with rendering on underrun clock doesn't get increased, so it makes sense on capture clock doesn't increase as well, and the discontinuity simply signals that an underrun has occurred that's at least a period long. The exact clock time passed will not matter. mmdevapi doesn't measure that in shared mode. It's also the only way the discontinuity flag would make sense and for the tests to pass, otherwise you would have set it on the first newly captured buffer after you finished reading out all old data. ~Maarten
Re: Users with native w2k/wxp/Vista/w7, please test (CreateTimerQueue)
Hey Joerg, Op 06-03-12 11:21, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > If you can run MS-Windows without virtual machine, please visit testbot > https://testbot.winehq.org/JobDetails.pl?Key=17175 > download the 32 or 64bit executable and execute it. > > I can't really trust vm machines for timing, but so far it appears that: > > - Vista/w2k8SE/w7 perform rate correction so as to maintain an average number > of callbacks > sync.c:583: TimerQueue period 10ms with 0 stress, flags 0 > sync.c:558: thread 1340 hpctime 30 delta 15 > sync.c:558: thread 1340 hpctime 46 delta 16 > sync.c:558: thread 1340 hpctime 46 delta 0 > sync.c:601: 80 callbacks within 796/800ms, avg 9.950/10 > > They'll refire with up to 0 wait upon noticing that it's very late! > > sync.c:583: TimerQueue period 10ms with 7 stress, flags 10 > sync.c:558: thread 1340 hpctime 46 delta 15 > sync.c:570: thread 1340 busy 7ms > sync.c:558: thread 1340 hpctime 53 delta 7 > sync.c:570: thread 1340 busy 7ms > sync.c:558: thread 1340 hpctime 62 delta 9 > sync.c:570: thread 1340 busy 7ms > sync.c:558: thread 1340 hpctime 77 delta 15 > sync.c:570: thread 1340 busy 7ms > sync.c:558: thread 1340 hpctime 84 delta 7 > sync.c:570: thread 1340 busy 7ms > sync.c:601: 59 callbacks within 607/600ms, avg 10.288/10 > > It maintains its average even the callback is busy for 7ms within each 10ms > interval. > > sync.c:583: TimerQueue period 10ms with 12 stress, flags 20 > sync.c:558: thread 828 hpctime 31 delta 12 > sync.c:570: thread 828 busy 12ms > sync.c:558: thread 828 hpctime 43 delta 12 > sync.c:570: thread 828 busy 12ms > sync.c:601: 42 callbacks within 507/400ms, avg 12.071/10 > > This one surprises me. No multiple threads are used. Wine uses several > threads here. When every callback is busy for 12ms, MS does not reach > an average 10ms per invocation, whereas Wine does, thanks to several > threads that execute the callbacks concurrently. > > I want to figure out why several threads were not used. > > sync.c:601: 40 callbacks within 4624/4680ms, avg 115.600/117 > Ok. Note that the average is usually slightly lower than expected, simply > because the first callback is asked to fire at time period/2. > > - w2k/xp do not maintain an average (at least on testbot) > sync.c:583: TimerQueue period 10ms with 0 stress, flags 0 > sync.c:558: thread 836 hpctime 30 delta 15 > sync.c:558: thread 836 hpctime 46 delta 16 > sync.c:601: 51 callbacks within 796/800ms, avg 15.608/10 > > So at least in testbot, the minimum rate is the well-known 15.625ms interval. > Note that the 15.625ms is visible in the w7 testbot results too. > > sync.c:583: TimerQueue period 117ms with 0 stress, flags 20 > sync.c:558: thread 840 hpctime 311 delta 125 > sync.c:558: thread 840 hpctime 436 delta 125 > sync.c:601: 37 callbacks within 4561/4680ms, avg 123.270/117 > > Unlike w7, it never corrects to a smaller interval like 109ms to reach > the requested average of 117ms. > > This is good news for audio in Wine, because we can make > CreateTimerQueue mimic Vista/w2k8/w7 behaviour to give us a stable rate (on > average). > > The logs are quite long, you can send me them per e-mail. > > Thank you, > Jörg Höhle > Have you tried changing the resolution with timeBeginPeriod? Supposedly affects those too.. ~Maarten
Re: introduction
Hey Tarun, Op 04-03-12 07:05, tarun bansal schreef: > > Hello everyone!! > I am a newbie in the world of open source development. But i am very eager to > participate in the GSOC2012. I have a good command over c,c++. Can someone > guide me on how to proceed further and start fixing the bugs... You might want to start reading up on http://wiki.winehq.org/Developers , it will have information that may be a good starting point for you to learn more. ~Maarten
Re: GSOC 2012
Hey Yogesh, Op 02-03-12 04:37, Yogesh Agrawal schreef: > Respected Sir, > > I am very much interested in doing project in this organisation. > I am interested in doing project which involves 3D Game development, Graphics > rendering. > I developed one 3D game using Microsoft Windows XNA and Visual Studio > framework. > I have also done course in Computer Graphics. > Please provide me with the details, how i should proceed further to be able > to get a project in this organisation. > The best way to get started would be to read our summer of code wiki, then find some specific area you want to improve wine on. http://appdb.winehq.org has a list of applications, you might want to look for your favorite application there and see if there's anything you can do to improve its support in wine. Cheers, Maarten
Re: [PATCH] winepulse: Add pulse driver, v8
Hey Joerg, Op 01-03-12 14:39, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote: >>>> - Align buffer size to a multiple of period size >>> How can you pass the tests with that? It's wrong with both capture >>> (annoyingly IMHO) and playback. >> I only really need it for capture, rendering needs it too since the tests >> show that this is the case, >> and seems to be against the tests too that everything is a multiple of >> period. > What is the case? Where did you see that? > > Native mmdevapi does not align GetBufferSize on period boundaries,neither > render > nor capture. The current tests may not reveal it, because 500ms is a multiple > of 10ms, > but I've enough additional tests in my git and log data from testbot to be > sure about that. > > I consider it unsafe to diverge from native when rendering. Ah ok. I was under the impression it was supposed to, but I guess not then. >> but there's nothing in the code that depends on it. > Good. > >> For capture it's different, you need to keep track of packets somehow. >> [...] Having one packet that's not a period is a pain, > I felt the same pain with winecoreaudio. I think I'm going to agree (with > myself) to disagree > (with mmdevapi), as standards would say, and align capture GetBufferSize on > period boundaries. > This will considerably simplify the code. I've not changed winecoreaudio > capture yet. > > So I find it ok if winepulse does the same: > - capture buffer as multiple of periods if it simplifies packet handling, > - render buffer exactly like native, not a multiple of period (cf. MulDiv in > the tests). > > And I'll change the capture tests to ensure it asks for buffer sizes as > multiples of period, > so the divergence won't show up :-) > > BTW, please use the MulDiv computations so as to minimize differences among > the 3-4 drivers. > Or exhibit tests that prove them wrong. It is allowed to allocate a buffer with a larger than requested time, see: http://msdn.microsoft.com/en-us/library/windows/desktop/dd370875%28v=vs.85%29.aspx The comment in hnsBufferDuration indicates it may allocate a larger buffer. Also, exclusive mode rendering seems to fail the period check on my laptop. >> I'd have to recheck on my windows pc > I forgot: Don't be wary of returning GetMixFormat with 6 channels if PA's > device is 5:1. Native > does that too (we had a few logs on test.winehq with that result) > (it may be too early if dsound chokes on that, but that would be a bug in > dsound). I return the result of the pulseaudio configuration, which may indeed be 5.1. :) I should probably do another getmixformat for capturing, because while it can be 5.1 if you're using the monitor stream as source, it's not necessarily the case. For example 5.1 output to speakers with a usb headset at 32kHz rate for capturing. >> Is it really IsFormatSupported's job to deal with a WAVEFORMATEX struct >> with only cbSize and wFormatTag and it will get out something sane all the >> time, no matter how stupid the input? > I've never seen IsFormatSupported return something else than GetMixFormat and > that is EXTENSIBLE. > For months I thought it would always return S_FALSE and GetMixFormat, no > matter how stupid the input, but: > a) I've no tested this with ADPCM or other such stuff; > b) I've not tested channel variations with >2 channels, lacking a 5:1 or such > card; > c) recent test.winehq has one Vista machine return E_UNSUPP_FORMAT > when the rate was != GetMixFormat. I have a patch in my queue to have the > render test accept that variation. That was my belief when testing too, unfortunately for dsound and winmm we will have to accept rate != GetMixFormat.rate, so that is a test I won't be able to pass with winepulse on wine. Fortunately the windows programs will not break on this, since they get the rate from GetMixFormat or IsFormatSupported. > What I believe is: > 1. During mmdevapi init, MS queries a GetMixFormat from each working device > and caches that. > 2. Later, IsFormatSupported returning GetMixFormat is a cheap operation: > clone_format(cached_mix_format). > None of our drivers work this way. Doing it would need some thinking about > dynamic reconfiguration and plug-in devices. I'm actually doing similar things. However on moving stream from old sink to new sink I'll keep returning the metrics of the initial sink. Hopefully it's not that big a problem, since pulseaudio will remember the device used for each stream. The next time the program executes it will get the updated GetMixFormat for the new sink. Winepulse does similar things for mix format actually, although maybe I should just cache the WaveFormatExtensible for capture and render instead of deriving it at runtime. ~Maarten
Re: [PATCH] winepulse: Add pulse driver, v8
Op 29-02-12 17:29, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > Chris is right about the format. The shared mode mixer ought to return > FLOAT(32), > and it always appears to return the extensible format as a consequence. > For weird reasons, wineoss may return integer formats, but that's certainly > going to cause some unexpecting app to crash. I think it's because wineoss may not always have float support because mixing float in the kernel would require special attention. >> +assert(oldpad >= This->pad); > Wasn't there a discussion some time ago that asserts are bad? > Better back out, return INVALIDATED or some such, but don't crash the app > just because there's a problem with sound. (I agree that winmm&mmdevapi > ought to contain self/consistency tests). This is an internal consistency problem, somehow we have more sound queued than we know about. I think crashing is the best thing it's a genuine bug that should never be possible, if I don't crash it will manifest itself differently, presumably in a subtle impossible to find way.. Outside of that callback, the assertion This->pad == This->bufsize_bytes - pa_stream_writable_size should hold. > It would be nice if you could attach some > WINETEST_DEBUG=2 render.log 2>&1 to bugzilla somewhere. > There is stuff that do not cause a failure yet diverges from native. > > +static void pulse_wr_callback(pa_stream *s, size_t bytes, void *userdata) > +if (This->event) > +SetEvent(This->event); > This should be the last thing in the callback. It may well cause your thread > to be kicked out by the scheduler. Oops, thanks for catching, it's why the other setevents are the last indeed. > +if (filled_one && This->event) > +SetEvent(This->event); > Don't the capture tests prove that events get in even when the buffer is > full? (please cross-check) You should get an event then, I steal the earliest full buffer. :) I don't think the full case is completely correctly handled yet. Unlike pulseaudio won't send multiples of fragsize, unlike for rendering, but since pa_stream_peek is guaranteed to return the same data until I drop it with pa_stream_drop, I suppose I could add a workaround that will only fill a multiple of periods. >> - Align buffer size to a multiple of period size > How can you pass the tests with that? It's wrong with both capture > (annoyingly IMHO) and playback. > > I don't have more time now (and know nothing about the pa_* API). > Is pa_mainloop_run the thread that dispatches the pulse_xyz_callbacks? > > I wouldn't mind a winepulse driver in 1.4.0 > I only really need it for capture, rendering needs it too since the tests show that this is the case, but there's nothing in the code that depends on it. For capture it's different, you need to keep track of packets somehow. This is why I keep the meta information in little packets until the application has come around to read them. Having one packet that's not a period is a pain, and seems to be against the tests too that everything is a multiple of period. ~Maarten
Re: AW: Major mmdevapi and winmm audio bugs
Hey Joerg, Having actually finished the pulseaudio implementation and trying to fix some fallout. Op 29-02-12 16:28, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote: >> For capture I plan to just add 2 queues, one for readable packets, and one >> for packets that can be filled for reading. > Winecoreaudio uses exactly this. Working now, with timestamps so all tests pass. IAudioClock::GetPosition I have to figure out still, I was allowing it to update based on stream time passed, but dsound fails with that, so I have to determine windows' behavior some more. >> ... for the pulse driver, I'm using the auto timing >> update feature and the callback for when rendering is not running. >> When the buffer is not underflowed, I'm using the write callback to >> signal more data is available. > I'm not familiar with PA's API, so I'm not following you. I'm not even > sure we talk about the same thing. Because pulseaudio receives all data on mainloop you can specify callbacks that will be run when those events are received too. I'm using the latency callback when first starting to signal the event when no data is playing. When data is buffered I use the pulse_rd_callback which fires every period because of pa_stream_early_requests. pulse_wr_callback is fired when there's at least a period buffered. >> I believe the event should be triggered when there is actual data >> available, at least that's how I understood the event is supposed >> to work. > I distinguish 2 events: > a) ALSA/PA backend ready for more data > b) mmdevapi SetEventHandle to the app > > Note that b) only exists when using EVENTCALLBACK. > > We have tests about b) that show that mmdevapi delivers events > to the app even when stopped (Wine fails those with todo_wine). I > don't know at what rate. Presumably at the same rate, but since in those cases you have no data I doubt it matters if you fire less often. > Regarding a), nothing prevents you from using the back-end's > favourite notification mechanism to wake up - or use a timer. Which my winepulse does. :) > I agree with you that ideally, somehow, b) and a) should be in sync, > otherwise we'll have clock skew and the XAudio scenario will exhibit > occasional underruns. > > But there are big HOWEVER: > - ALSA/PA may not grant us the period we'd like (10ms). 21.333ms is common > with ALSA/dmix. > I don't know how important the 10ms are. > You're familiar with DSound, so perhaps you have an opinion why DSound > has been using 10ms intervals in Wine regardless of the back-end's period. > I believe that Wine ought to use the same rate as native or some app will > exhibit a bug. If dmix doesn't support 10ms, set default period to 1024 samples and use that, no point in trying to do something it's not. Don't forget to update GetStreamLatency in that case, though. > - We do not need 10ms events when not using EVENTCALLBACK, so why not > write all available data (e.g. 333ms from winmm:PlaySound) and sleep > that much? Laptop owners will thank us. It's possible for winmm and dsound, but the drivers will have to keep the default period in any case, for when other mmdevapi programs rely on it. > - How to continue signaling type a events after IAudioClient_Stop? > By continuing to write silence to the back-end?!? Could work, I'm abusing the auto timing update from pulseaudio, which fires periodically as well, even when playing nothing. > - Last but not least, I don't know whether ALSA's signaling and mmdevapi's > SetEvent needs can be made compatible even when the periods would agree. > mmdevapi's SetEvent means "don't worry, you have one period time to write > data" > or even "you may write data, but I already have buffered some". > ALSA/PA's signal means(?) "hurry up, you're on the verge of underrun". > Please correct me. As far as my understanding of mmdevapi is, it fires every period. If you have some data gogogogo, but write at least GetStreamLatency worth of samples, or you'll have an underrun. That also means mmdevapi rendering will have to be periodic or bad things occur. > - The test_worst_case aka. XAudio scenario has tough requirements: > - Signal events not often enough and you'll enter an underrun. > - Signal events too early and it'll write no data. The event was wasted and >the next one may come too late to avoid an underrun. > > In summary, if the back-end guarantees 10ms wake-ups, you should be able to > nicely sync a) and b) (probably by writing silence when stopped...) > If not, then some mechanism must be there to decouple the two.
Re: [PATCH] winepulse: Add pulse driver, v8
Hey Chris,
Op 29-02-12 06:58, Chris Robinson schreef:
> On Tuesday, February 28, 2012 5:32:13 PM Maarten Lankhorst wrote:
>> + * This is basically the same as the pa_threaded_mainloop implementation,
>> + * but that cannot be used because it uses pthread_create directly
>> + *
>> + * pa_threaded_mainloop_(un)lock -> pthread_mutex_(un)lock
>> + * pa_threaded_mainloop_signal -> pthread_cond_signal
>> + * pa_threaded_mainloop_wait -> pthread_cond_wait
> I'm curious why you're using pthreads. Doesn't WinAPI have anything
> comparable
> to pthread_cond_wait?
I'm literally following the pulseaudio mainloop here. If you look at
their definitions they will map to those. Pulseaudio library
on win32 was having their own weird version of pthread_cond_*
which would go through wineserver multiple times for each
signalling. The extra context switches would have been a sure
way to kill any hope of efficiency and decreased the chances of
the scheduler doing things right. :)
pulseaudio/src/pulsecore/mutex-win32.c for reference
>> +static void pulse_probe_settings(void) {
> ...
>> +ret = pa_stream_connect_playback(stream, NULL, &attr,
>> +PA_STREAM_START_CORKED|PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_S
>> TREAM_FIX_CHANNELS|PA_STREAM_EARLY_REQUESTS, NULL, NULL);
> Is it necessary to fix the format? MSDN says that the audio service always
> works with floating-point, and GetMixFormat always specified floating-point
> in
> my dealings with it. I don't think it should blindly return whatever
> PulseAudio does, unless it can be shown that Windows doesn't always give
> floating-point.
I'd have to recheck on my windows pc, to see if that's the case.
However if it is I don't see a problem with always specifying float
and removing the fix flag for it.
>> +static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt)
>> +{
>> +WAVEFORMATEX *ret;
>> +size_t size;
>> +
>> +if (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE)
>> +size = sizeof(WAVEFORMATEXTENSIBLE);
>> +else
>> +size = sizeof(WAVEFORMATEX);
>> +
>> +ret = HeapAlloc(GetProcessHeap(), 0, size);
> This should probably use CoTaskMemAlloc, as it's used for IsFormatSupported.
> I'm also curious if IsFormatSupported should always return a
> WAVE_FORMAT_EXTENSIBLE object.
Aye indeed, seems to be an old copy/paste bug too. Was fixed on 27 Apr 2011 in
winealsa.
>> +static enum pa_channel_position pulse_map[] = {
> This should probably be const.
Yes. :)
>> +if (fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT)
>> +This->ss.format = PA_SAMPLE_FLOAT32LE;
> ...
>> +if (IsEqualGUID(&wfe->SubFormat, &KSDATAFORMAT_SUBTYPE_IEEE_FLOAT))
>> +This->ss.format = PA_SAMPLE_FLOAT32LE;
> You likely should check that the format specifies 32 bits, and not 64 or
> something different like that.
Yes indeed, I've moved those checks to a separate function now,
Initialize was getting too long. I should probably use it for
IsFormatSupported, but likely PulseAudio supports any sane
format you throw at it, although I haven't tested the limits...
Is it really IsFormatSupported's job to deal with a WAVEFORMATEX struct
with only cbSize and wFormatTag and it will get out something sane all the
time, no matter how stupid the input?
This isn't an all-inclusive lookover, just some things that caught my eye.
Also, does this driver fail to load if it can't connect to a pulse server?
Yeah, mmdevapi checks priority, I set it to 0 if driver is unavailable, 3 if it
is.
See AUDDRV_GetPriority
Thanks for reviewing,
~Maarten
Re: [PATCH] winepulse: Add pulse driver, v8
Hey Dmitry, Op 28-02-12 18:42, Dmitry Timoshkov schreef: > Maarten Lankhorst wrote: > >> >From 8aa5903b1ee75a6c538d7e1d99560bcb39a47ed2 Mon Sep 17 00:00:00 2001 >> From: Maarten Lankhorst >> Date: Thu, 28 Apr 2011 09:45:18 +0200 >> Subject: [PATCH 10/10] winepulse: Add pulse driver, v8 > You forgot to fix the date, 1 Apr would be more appropriate I'd guess. > I'm surprised it used that date, but I'm no less serious about my intentions to get it included into wine. If you have any technical concerns I would be glad to hear them. ~Maarten
Re: Major mmdevapi and winmm audio bugs
Hey Joerg, Op 27-02-12 19:22, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > Maarten Lankhorst wrote (partly in a former thread): > >>> R. thread priority -- no "Pro Audio" / Real-Time priority >> Not going to happen, ever. AJ nuked all my attempts at it, >> [...] >> Or just fix things properly and use rtkit for time critical threads > and now: >> I would say using rtkit for setting threads to realtime would be an aid for >> this. > I can understand AJ's reluctance to RT code in Wine. I wouldn't feel > comfortable either. I believe few people realize that RT is a gifted > gift. Bear in mind that RT processes work at a priority above any > root or user process. Do something wrong there, consume 100% CPU and > you can press the single core machine's power down button. I would > not accept RT code in a system without a very careful code review and > think twice about the consequences, and require a design that keeps > the RT part of the app as small as possible, better separated. > > OTOH, RT is the means to provide reliable ticks, and that's why PA as > a sound server wants that. Now one can argue that Wine's mmdevapi > plays sound server for all w32 apps, so it has the same needs. Agreed, I've tried to keep it as small as possible for the thread itself, the mainloop thread calls very few functions, I need to add a bit more, but the only source of problems could come from the pulseaudio lib itself. At this point my winepulse driver is very reliable for rendering, and capture should be the same once I add the queue stuff, it would also be the only driver to actually pass the tests. For capture I plan to just add 2 queues, one for readable packets, and one for packets that can be filled for reading. With that approach I should be able to pass all tests in the most efficient way while keeping the metadata mmdevapi adds for capture. >> I'm just using a simple mainloop thread > That's my plan for past 1.4 too. Get rid of CreateTimerQueue as > callback source in mmdevapi, use a thread for the feeder and poll() to > wait 10ms, like all devices used to do. > I believe that's too big a change for code freeze. > > W.r.t. to 1.4.0, I believe the following path should be taken: > - Write CreateTimerQueue tests to verify whether native behaves like: > a) sleep(Xms) /* what Wine does now */ or > b) sleep(Xms - elapsed) /* what winmm:timeSetEvent does */ > - If b), fix CreateTimerQueue. > - If a), CreateTimerQueue is unusable for the purposes of Wine's mmdevapi > and something else must be sought... Even if so, it is unneeded for the pulse driver, I'm using the auto timing update feature and the callback for when rendering is not running. When the buffer is not underflowed, I'm using the write callback to signal more data is available. Timerqueue would be a lie, the driver should schedule when data can actually be written and not based purely on ticks. Pulseaudio allows this and I'm using this feature in my driver. It passes all the render tests now except the volume related ones (they're a reminder, and a nop on other drivers anyhow), and I'm working to complete capture in a similar fashion as well. I believe the event should be triggered when there is actual data available, at least that's how I understood the event is supposed to work. Doing it based on a timer that isn't tied to the state in any way feels wrong. Having 2 threads for pulse feels wrong too, especially since it can be done with just using the one pulse provides, because you can set callbacks for when more data can be read or written. ~Maarten
Re: Major mmdevapi and winmm audio bugs
Hey Joerg, Op 24-02-12 13:28, joerg-cyril.hoe...@t-systems.com schreef: > Hi, > > instead of Wine Weekly News (WWN, any taker?) you get monthly audio news. > > The surprising thing is: it looks like most audio bugs remaining in bugzilla > are from the pre-mmdevapi era and have not been updated since mid-2011. > > - Using devices other than "default" (dmix or pulse): > #29294 no sound with ALSA loopback -- are they duplicates of each other > #28781 loopback to Jack -- or is one about DSound only? > > We have are several issues about crackling sound: > > - One definitely is caused by CreateTimerQueue which is not regular > enough or does not deliver 10ms, but 12ms callbacks. This is in > #28723 which includes a work-around in comment #130 > That may affect the Solaris machine on test.winehq.org too. > > - One is caused by a mmdevapi design error: the audio buffer we use is > simply too small, and Linux can't bear a regular 10ms rate. > Things got worse since the introduction of the Completely Fair Scheduler. > It can't even guarantee a regular 50ms one. There's a need for a much > larger buffer. That's why wine < 1.3.25 is giving steadier sound. > #29531 may be caused by this. Really? I would say using rtkit for setting threads to realtime would be an aid for this.. > - Mac OS X 10.5.8 crackles constantly with dlls/mmdevapi/tests/render > I'd like somebody with 10.6 or .7 to perform the interactive test. > rm -f render.ok; WINETEST_INTERACTIVE=1 make render.ok > > - Lastly, there's PulseAudio > #28856 among others > I don't understand why I couldn't find bugs in PA's bugzilla, so I wrote > some: >- https://bugs.freedesktop.org/show_bug.cgi?id=46296 > About the need to restart the PA server from time to time >- https://bugs.freedesktop.org/show_bug.cgi?id=46297 > PA's huge buffering causes issues with winmm >- https://bugs.freedesktop.org/show_bug.cgi?id=46412 > How to obtain PA's typical 44100 rate? > Feel free to contribute if you know apps outside Wine with similar issues. > Surprisingly, users have reported improvements in the latest > wine-1.4rcX even when nothing changed, but also mentioned updates on > the PA and alsa_plugins side. Perhaps that improved the situation. > > I was pleased to see Wine's testsuite help find bugs in Pulse: > http://lists.freedesktop.org/archives/pulseaudio-discuss/2012-February/012825.html bug 46412 is worded wrong, pulseaudio can get native format just fine with PA_STREAM_FIX_RATE|PA_STREAM_FIX_FORMAT|PA_STREAM_FIX_CHANNELS, but maybe the pulse plugin doesn't respect it. fwiw, IAudioClient::GetMixFormat works just fine with my winepulse driver, dsound doesn't seem to respect the rate, however. If you feel like toying around, my git tree is at: http://repo.or.cz/w/wine/multimedia.git and contains a simple winepulse driver that sadly doesn't pass all tests yet, but I've not been motivated to fix the remaining ones since nobody seems to care about the driver and it will never get merged. Most test failures are related to IAudioClock including silence time. Hacked away a bit more and I think I can fix it without being required to have a shadow buffer, using the write callback to signal when writing is done and keeping more track. The current "le sigh" commit solves it in a wrong way, but it's just a first stab at solving it. I don't trust lockless, and I'm just using a simple mainloop thread based that matches the one pulseaudio uses everywhere, but manually created with CreateThread so normal wine calls would still work from it without weird bugs popping up. > There are issues not always associated with a bug entry: > - #29472 comment #12 DSound GetDevicePosition is not how it should be > - Check OSS4 with and without vmix #28056 #28790 > - winmm handling huge latency (such as PA's) & when to send notifications > - Issues with microphone capture? > - DSound mixing and buffer sizes & padding vs. GetPosition > - Deal with intermittent errors from ALSA etc. in mmdevapi, winmm and dsound > - Device enumeration and PA preventing access to the underlying device > Is this known to cause no sound in an app (or only in our wave tests?) > - various missing trailing sound with DSound #21209 > - #29369 strange issue involving PA and perhaps messaging > - misc. losing sound: #28319 #25164 #28770 > - lead-out needed with dmix > - Use lock-less design to reduce contention, cf. #29531, comment #7 > - multi-channel, 5:1 etc. in mmdevapi and DSound > - Bugs in the quartz or winegstreamer area that I don't have on my radar > Winepulse supports 5.1 just fine, but dsound does not. I'm just using the dsound-openal replacement for now in games. It's a slightly patched version of http://repo.or.cz/w/dsound-openal.git ~Maarten
Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27
Hey Dylan, Op 11-02-12 18:48, Dylan Smith schreef: On Sat, Feb 11, 2012 at 9:50 AM, Maarten Lankhorst mailto:m.b.lankho...@gmail.com>> wrote: I have my doubts about these for example: - Richedit windowless mode - There's no way this can be a student project until someone does the thiscall that works both ways, this has been the biggest stumbling block to implementing it. Actually, that stumbling block has been implemented. The next step is implementing ITextServices::TxDraw. Are you sure? I don't see any example calls being wrapped to ITextHost for example.. ~Maarten
Re: Fwd: Google Summer of Code 2012 DEADLINE: 2012-02-27
Hey Jeremy, Op 10-02-12 20:23, Jeremy White schreef: Hi Folks, It's that time of year again - summer of code is going to start up soon. Maarten, you've been coordinating things for us for a while now - are you still game? Would you like help? Anyone else willing to volunteer to help admin the process? I'll apply wine again this year, but I want to ask everyone to help update our summer of code project wiki page. http://wiki.winehq.org/SummerOfCode I feel like we're not getting enough accessible projects that also have the correct length. I'm looking for something that's non-trivial but can still be done incrementally, having huge delta's to winehq has proven to not lead to meaningful contributions, and some of the projects on that list are too small, too complicated or might not be integrated into wine because it would be above a student's level get it done right. I have my doubts about these for example: - Message mode pipes - if AJ doesn't know how to do it, how can a student do it right? - Sandboxing, what's to prevent an app from simply doing syscalls in assembly, a real sandbox is not going to work - Richedit windowless mode - There's no way this can be a student project until someone does the thiscall that works both ways, this has been the biggest stumbling block to implementing it. - TestSuite - All previous attempts have failed, I believe that compiling testsuites for other projects would be a good project instead, fixing all problems that show up and don't show up on windows. Improving winetestbot to something more standardized and maintained would be nice too, but hardly a summer of code project, since it's too short. But that's just my opinion, feel free to add your own projects to that list. :-) ~Maarten
Re: brainstorm: what are the audio stumbling blocks?
Hey Joerg,
Op 27-01-12 16:35, joerg-cyril.hoe...@t-systems.com schreef:
Maarten,
thank you for participating!
Provide a hidden API in mmdevapi?
No need, you know how mmdevapi behaves, you can write it in such a
way without adding latency by using GetCurrentPadding or the clock.
I don't know what you mean. What I mean is follows:
mmdevapi has no notion of rewinding.
Rewinding is what PulseAudio recommends to master latency:
http://0pointer.de/blog/projects/guide-to-sound-apis.html
"Use snd_pcm_rewind() if you need to react to user input quickly.
Do not assume that snd_pcm_rewind() is available and works and to which
degree."
Let's say DSound uses a 200ms primary buffer. It can (and I believe
Wine's DSound did that) mix all of the playing secondary buffers and
feed 200ms of samples to ALSA.
Effect: 200ms audio playing with nothing else to do.
Now let' suppose after 50ms, Play is invoked on an explosion buffer.
DSound can query the hw pos and remix the remaining 150ms (or 140 to
play safe) to include that noise. With ALSA, it can do so
- either by using snd_pcm_rewind or
- via direct access to the ALSA buffer (mmap).
The key point is that DSound's model (the HW buffer) is compatible
with both feeding arbitrary large amounts of data in advance *and*
quickly adding sounds with as little latency as possible.
Enters mmdevapi. No rewinding. A Release'd frame will be played,
unless you Stop and Reset.
If you Release 200ms of data now, additional samples can only be heard
afterwards. The solution so far: write next to nothing in advance --
10ms! -- and rely on super fast interrupt& wake-up to reliably submit
another 10ms just in time.
Assessment: failure.
Wobbling sound and underruns reported in bugzilla.
No wonder MS sells w7 with new machines only. The old ones
can't stand the 10ms interrupt rate.
I'm fairly confident older machines handle that properly too. Just
requires properly written drivers.
Windows vista was a lot more bloated than 7.
I wouldn't count on rewinding for alsa either, I'm not even sure if dmix
finally supports it or not, buffer slightly more data instead. I think
this is what IAudioClient::GetStreamLatency is meant for.
Alternatives:
A. Every DSound secondary buffer gets its mmdevapi stream.
DSound::Play immediately calls IAC::Start.
Some says this is not useable because every mmdevapi stream maps 1:1 to
snd_pcm_open and it's rumoured that cards would not support the
amount of simultaneous connections corresponding to the number of
secondary buffers that DSound apps typically use (rumour has it over
20). Again, DSound is not my domain of expertise.
Doesn't work on streams where you can alter the frequency..
That's why I've been arguing in bug #29531 that mmdevapi implements
its own mixer. ALSA would only see one connection.
How to implement that mixer? Now we circled once and are back at the
above point about rewind/mmap.
B. Special DSound hooks that bypass mmdevapi's streaming design,
allowing to both write 200ms of data in advance and overwrite part
of it as needed -- hidden API or COM interfaces.
C. Other?
Well, that was the old DSound. XAudio2 ("the rage bug #28723")
apparently goes the "every 10ms" route, hence Wine needs to support
that in any case.
I've repeatedly argued that the fact that an app may may use 10ms (and
risk gfx and sfx glitches and write 3GHz quadcore as min. requirement
on the back of the DVD cover) should not cause apps using 200ms
buffers to suffer glitches. How to meet both ends?
Or just fix things properly and use rtkit for time critical threads,
the real problem would be context switches with wineserver. The
extra task switches and reliance on the scheduler to get
things right could cause more problems..
~Maarten
Re: brainstorm: what are the audio stumbling blocks?
Op 26-01-12 12:59, joerg-cyril.hoe...@t-systems.com schreef: Hi, What are the areas that would have the most impact if fixed? You are invited to participate and share your thoughts. I believe we need to distinguish winmm/dsound/mmdevapi/OS. mmdevapi: A. lock-less timer callback design, bug #. But I don't think where we would get the most improvement from avoiding a few EnterCriticalSection. B. Stability of time base, bug #. Perhaps major. My render "worst case" test showed that CreateTimerQueue never invoked callbacks every 10ms as asked rather than 8 or 12ms. I don't know if that's the Linux jiffies we see here. C. too small ALSA buffer for the backend I've sketched a "hidden frames" design that would allow using a larger ALSA or OSS buffer, but that needs a reliable estimate of how much ALSA has buffered. Also, that's at odds with DSound and XAudio2 which want short latency and presumably don't send much data in advance. Every audio HW guy recommends using audio buffers as large as possible. Can't we just because of the f**ing 10ms period? Sorry, we don't control delivery, and can't tell applications how to behave... Just bite the bullet and add a winepulse driver already, I'll even fix mine to work better if it had a chance of getting accepted, not having a driver for the default linux audio system is just silly.. D. timer frequency Is it really important to match native's 10ms period? The UNIX world is trying to decrease the number of interrupts in order to preserve battery life, but we go backwards and move from a model which dynamically computed the next wake-up based on the number of submitted frames to a tiny fixed period. Are we crazy? E. lead-in aka. "ALSA won't start", bug # F. lead-out aka. finish playing trailing frames not modulo period size, bug # G. other mmdevapi winmm: H. GetPosition is not (yet) == mmdevapi's GetPosition I. other winmm DSound: J. time base? It uses timeSetEvent. What if using mmdevapi's event? K. buffer size too small or not matching whatever needs? L. issues with GetCurrentPadding/GetPosition The "true position" may be too far away from the write pointer, e.g. PA's typical 2s latency. Deal with that, matching DSound's and the apps' expectations as well as Linux/BSD/OSX sound systems. See V. M. DSound's underlying model is a ring buffer. This does not match mmdevapi's. Should we bypass mmdevapi because all it adds is latency? Reinvent HW acceleration? Provide a hidden API in mmdevapi? No need, you know how mmdevapi behaves, you can write it in such a way without adding latency by using GetCurrentPadding or the clock. N. other DSound XAudio2: Modern apps will use that because mmdevapi is too low-level, presumably DSound usage will decrease. O. XAudio2 appears to use the "worst case small period size writes" known from the Rage bug # P. other Capture: Q. whatever capture issues UNIX host: R. thread priority -- no "Pro Audio" / Real-Time priority Not going to happen, ever. AJ nuked all my attempts at it, dbus+rtkit watchdog version is here: http://repo.or.cz/w/wine/multimedia.git/commit/431e943193d0d916a7bb6be32b0c20a432854474 S. reliability of event/interrupt delivery over sustained intervals (hours, not minutes). ...? T. Wine SetEvent& server round-trip times This is indeed an awful case, but with the wineserver designed the way it is there's no other way around it, I honestly wouldn't be surprised if this is a performance issue on its own for some games... Other: U. FMOD& whatever, any particular constraints? Last I checked (ages ago) fmod just worked. Might be different since last rewrite though.. V. other? (rant in general) Stop trying to support pulseaudio with winealsa, with all the efforts you would have had a fully functioning driver by now. See my tree for a start, but it doesn't appear to work in extremely low latency cases (winepulse -> pulseaudio -> jack with jack set up for 40 * 3 samples buffer), need to look at it more first. Thanks for your contribution, Jörg Höhle ~Maarten
Re: Rethinking WineConf
Hey, Op 17-01-12 22:01, Dan Kegel schreef: On Tue, Jan 17, 2012 at 12:43 PM, Jeremy White wrote: So, exploring #3 a bit further - what if we asked for our own track within FOSDEM 2013? (I presume that would be February 2013 in Brussels) It would let us all get together, allow us to have a few sessions targeted at non Wine developers, and could also save us some hassle. And I like Belgian beer. FOSDEM was the only conference mentioned by more than one person in my little survey :-) I see Fosdem 2012 has a mono room: http://weblog.savanne.be/470-mono-developer-room-at-fosdem-2012-cfp I wonder if that would be a model to, um, emulate. - Dan Yeah there's some Xorg stuff going on as well. I'm visiting fosdem 2012 for that reason. Would be interesting to know if any wine devs go this year. Might meet up, and drink something non-alcoholic together. I'm only there saturday though. ~Maarten
Re: Compiling Wine without prelink
Hey Roger, On 11/27/2011 10:29 PM, Roger Cruz wrote: > What is the proper way to ask the configure script not to use 'prelink' on > the generated shared libraries? I don't want to remove the prelink from my > development platform but just tell the configurator to ignore it. > Prelink is only used to force dlls to certain addresses, not for anything else. Without prelink this would not work..
Re: [Wine] WineHQ database compromise
Hey,
On 10/12/2011 12:46 AM, Josh Juran wrote:
> On Oct 11, 2011, at 3:37 PM, Conan Kudo (ニール・ゴンパ) wrote:
>
>> On Tue, Oct 11, 2011 at 3:39 PM, Josh Juran wrote:
>>
>>> Since bugzilla passwords were sent in cleartext anyway, I sincerely hope
>>> none of them were otherwise valuable. (Remember FireSheep?)
>> Wait, what? Bugzilla sends passwords in cleartext? That isn't very smart...
>> Is there no way to replace this with some sort of client based hashing or
>> something?
> To clarify, your browser sends your password to bugzilla in cleartext, since
> HTTPS isn't an option.
>
> Firesheep was a lesson that even once passwords are secure, session
> credentials are still vulnerable to sniffing. Some sites went to HTTPS-only
> sessions after that.
>
If I go to any https://*.winehq.org website I get the certificate for
test.winehq.org , otherwise you could use the firefox https anywhere to force
https on.
Or better yet, force automatic redirect to https, with
Strict-Transport-Security:
https://hacks.mozilla.org/2010/08/firefox-4-http-strict-transport-security-force-https/
If winehq can't get more ips for every subdomain (ssl sucks), would the
solution be moving it to https://winehq.org/{bugs,appdb,test,source} ?
Cheers,
Maarten
Re: WineHQ database compromise
Hey everyone, On 10/11/2011 09:13 PM, Jeremy White wrote: > Hi, > > I am sad to say that there was a compromise of the WineHQ database system. > > What we know at this point that someone was able to obtain unauthorized > access to the phpmyadmin utility. We do not exactly how they obtained > access; it was either by compromising an admins credentials, or by > exploiting an unpatched vulnerability in phpmyadmin. > > We had reluctantly provided access to phpmyadmin to the appdb developers > (it is a very handy tool, and something they very much wanted). But it > is a prime target for hackers, and apparently our best efforts at > obscuring it and patching it were not sufficient. > > So we have removed all access to phpmyadmin from the outside world. > > We do not believe the attackers obtained any other form of access to the > system. > > On the one hand, we saw no evidence of harm to any database. We saw no > evidence of any attempt to change the database (and candidly, using the > real appdb or bugzilla is the easy way to change the database). > > Unfortunately, the attackers were able to download the full login > database for both the appdb and bugzilla. This means that they have all > of those emails, as well as the passwords. The passwords are stored > encrypted, but with enough effort and depending on the quality of the > password, they can be cracked. > > This, I'm afraid, is a serious threat; it means that anyone who uses the > same email / password on other systems is now vulnerable to a malicious > attacker using that information to access their account. > You may also want to change your testbot password if you re-used your password.. https://testbot.winehq.org/ForgotPassword.pl Cheers, Maarten
Re: Alexandre's keynote
Hey JWhite, On 10/02/2011 12:10 AM, Jeremy White wrote: > Thanks to Jon Parshall's hard work, we have Alexandre's keynote available > here: > > http://www.youtube.com/watch?v=2rdDvMonTnQ > > Remember to have your libation at hand so you can play the game... > > Cheers, > > Jeremy > > Nice work, is there a pdf available too? :) ~Maarten
Re: Favorite bug: deadlock preventing backtraces?
Hey Dan, On 09/29/2011 06:00 AM, Dan Kegel wrote: > On one of my boxes, if I run winmm/midi.ok in a loop, it will > eventually deadlock/crash > ( http://bugs.winehq.org/show_bug.cgi?id=28388 ): > err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main > process heap section" wait timed out in thread 0022, blocked by 001f, > retrying (60 sec) > wine: Critical section 00110060 wait failed at address 0x7bc3484a > (thread 0022), starting debugger... > err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main > process heap section" wait timed out in thread 0022, blocked by 001f, > retrying (60 sec) > > Sadly, no backtrace follows ( http://bugs.winehq.org/show_bug.cgi?id=28265 ). > Since I'm not around when it finally happens, I haven't tried btall yet. > > I suppose I should write a shell script to watch for that error > message in the log, > and run btall then... any better ideas? > > (I did try giving winedbg a private heap, didn't seem to prevent the > deadlock.) > > I'm wondering if it's because of the lock in virtual_handle_stack_fault, what if you remove that? :P
Re: using (or not) blocking mode with OSS4
Hey Joerg, On 09/26/2011 02:57 PM, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > I've had a glance at the OSS4 mmdevapi logs attached to bug #28056. > Among others, it appears that every renderer iteration takes way too > much time. One possible explanation is that OSS write() takes a lot > of time to return, presumably in an attempt to write more than what's > possible without blocking. > > If you look at AudioRenderClient_ReleaseBuffer and oss_write_data, > you'll see that it writes as much as it has, without querying > GETOSPACE. So it can block. > > open() is called without O_NONBLOCK, so write() will block when given > too much data. > > I don't know yet whether O_NONBLOCK should be used. It's not what the > OSS people recommend. One can argue that NONBLOCK is superfluous when > write is limited via GETOSPACE. > http://manuals.opensound.com/developer/open.html > http://manuals.opensound.com/developer/audio_timing.html > http://manuals.opensound.com/developer/SNDCTL_DSP_NONBLOCK.html > > What do you think about using (or not) blocking mode with OSS? > > W.r.t. ALSA, I'm considering keeping non-blocking mode but switch from > a periodic timer to poll(ALSA_fd, period_timeout). Given a lot of > data, poll would return after the timeout, but when underrun is close, > this should allow to wake up closer to when data is actually needed. > ALSA needs nonblocking because you can never guarantee the pulse plugin works correctly, or one of the other plugins. However for oss it makes sense to query GETOSPACE, so just do that. Nonblocking shouldn't be needed then. ~Maarten
Re: IPv6 issue on TestBot?
Hey, On 09/22/2011 04:54 PM, Michael Stefaniuc wrote: > Per Johansson wrote: >> 22 sep 2011 kl. 12:14 skrev Michael Stefaniuc: >> >>> Wow! /66? And that works? While the standard allows for that you "should >>> use /64" which everybody and his dog read it as that is the only thing >>> that needs to work and the only thing that get tested. IPv6 brings back >>> the class-full thinking which everybody has to painfully unlearn once >>> IPv6 catches on... >>> >>> "Safe" prefix length (especially if involving client devices) are: >>> /64 - LAN >>> /126 and /127 - point to point >>> /128 - host routes >> RFC3513 is quite more strict than "should": > Which is obsoleted by RFC4291, but that seems to have kept this > paragraph. Anyway the correct RFC term to make it mandatory is "must". > And it isn't a "must". Also the RFC4291 is from 2006 which is *old*. > >>All global unicast addresses other than those that start with binary >>000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as >>described in section 2.5.1. Global unicast addresses that start with >>binary 000 have no such constraint on the size or structure of the >>interface ID field. >> >> (2001:: has the binary prefix 001). So this might very well be the problem. > The same RFC4291 says: >Except for the knowledge of the subnet boundary discussed in the >previous paragraphs, nodes should not make any assumptions about the >structure of an IPv6 address. > > It might be the problem but not because of the RFC; it just might be a > typo as it is a manually set IP. > >> I've heard the reason for 64 bits is that it's what currently fits in most >> computer registers, but I don't know if it's true. > What really helps to understand IPv6 is: > - IPv6 is an old protocol >15 years. That predates the Internet taking over. > - IPv6 was designed based on the assumption that it will make the > Internet again a friendly, warm and cozy place; a big any to any network > without barriers/firewalls. > - IPv6 isn't better than IPv4, it is different. > - IPv4 still outperforms IPv6 in the new feature development. IPv6 is > trying to play catch up. A few things that were long ago deprecated in > IPv4 are still mandatory for IPv6 to be "standards compliant". > - Don't assume that if the IPv6 standard says something the > implementations really follow that. Test, test, test. > > So no, the /64 host part has nothing to do with current hosts having > 64bit registers now. I'm pretty sure that they were hoping to have > 128bit computers by now. It had more to do with thinking that a globally > unique identifier for the host is a good think to have and the MAC > address already provided that with 48bits. But 48 isn't a nice number so > it was rounded up to 64 which makes for a nice "design" as it is half of > the IPv6 address. > Discussion aside, seems that using /64 works, so I'm keeping that. With the change testbot.winehq.org works again when using ipv6. I am not sure why it was set to /66, so I just hope nothing breaks as a result of this change. ~Maarten
Re: IPv6 issue on TestBot?
Hey, On 09/22/2011 11:25 AM, Ben Peddell wrote: > On 22/09/2011 6:24 PM, Maarten Lankhorst wrote: >> Hey, >> >> On 09/14/2011 12:47 PM, Francois Gouget wrote: >>> Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( >>> This makes accessing it from my desktop very annoying. >>> >>> $ time wget -4 --quiet http://testbot.winehq.org/ >>> real0m2.150s >>> user0m0.000s >>> sys 0m0.000s >>> >>> $ time wget -6 --quiet http://testbot.winehq.org/ >>> ... still stuck after 6+ minutes >>> >>> $ telnet -6 testbot.winehq.org >>> Trying 2001:888:2000:38:1000::2... >>> ... same thing >>> >>> >>> According to http://test-ipv6.com/ my desktop is configured just fine >>> and I only have trouble with the TestBot. >>> >>> Could this be a firewall problem? (testbot exposing an IPv6 address but >>> the firewall dropping any IPv6 packets) >>> >>> >>> In the mean time I'm going to use my laptop which is still IPv4 only >>> :-/ >> That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping >> work? >> >> ~Maarten >> > # traceroute -4 -T -p80 testbot.winehq.org > traceroute to testbot.winehq.org (82.94.219.252), 30 hops max, 60 byte > packets > ... > 9 te5-4.swcolo1.3d12.xs4all.net (194.109.12.30) 159.889 ms 159.942 > ms 159.868 ms > 10 v2.gse.nl (82.94.219.252) 161.955 ms 159.354 ms 164.692 ms > > # traceroute -6 -T -p80 testbot.winehq.org > traceroute to testbot.winehq.org (2001:888:2000:38:1000::2), 30 hops > max, 80 byte packets > ... > 11 te5-4.swcolo1.3d12.xs4all.net (2001:888:0:114::2) 145.296 ms > 145.109 ms 145.817 ms > 12 * * * > ... > 30 * * * Testbot has 2 ips assigned to it: inet6 addr: 2001:888:2000:38:1000::1/66 Scope:Global inet6 addr: 2001:888:2000:38:1000::2/66 Scope:Global Does the ::1 work? ~Maarten
Re: IPv6 issue on TestBot?
Hey, On 09/14/2011 12:47 PM, Francois Gouget wrote: > Connecting to https://testbot.winehq.org/ over IPv6 hangs for ages :-( > This makes accessing it from my desktop very annoying. > > $ time wget -4 --quiet http://testbot.winehq.org/ > real 0m2.150s > user 0m0.000s > sys 0m0.000s > > $ time wget -6 --quiet http://testbot.winehq.org/ > ... still stuck after 6+ minutes > > $ telnet -6 testbot.winehq.org > Trying 2001:888:2000:38:1000::2... > ... same thing > > > According to http://test-ipv6.com/ my desktop is configured just fine > and I only have trouble with the TestBot. > > Could this be a firewall problem? (testbot exposing an IPv6 address but > the firewall dropping any IPv6 packets) > > > In the mean time I'm going to use my laptop which is still IPv4 only > :-/ That ipv6 address is set on testbot, so it ought to work. Does ICMP6 ping work? ~Maarten
Update on testbot
Hi all, I moved the windows 7 x64 vm with sp1 applied to the base pool now. This means that all submitted patches will be run on that vm as well. The original win7 vm is still available under its own name. Since all tests pass on that according to winehq tests I'm keeping it in the base pool. I hope to see all tests on the new vm fixed as well. They mostly appear to be related to the ie9 update, but msctf:inputprocessor and msi:install fail as well. ~Maarten
Re: Unimplemented function?
Hey, On 09/18/2011 12:52 PM, Luis Carlos Busquets Pérez wrote: > It seems that there is a regression in wine 1.3.28. Before bi-secting, I woul > dlike to understand how that can happen. Apparently PlaChessV5.exe crashes > due to: > > wine: Call from 0x68215ca8 to unimplemented function msvcrt.dll._snwprintf_s, > aborting > > > but when I look at the spec file, the function is defined: > > @ varargs _snwprintf_s(ptr long long wstr) MSVCRT__snwprintf_s > > and it exists in wcs.c > > How is it that them it results as undefined? Are you using a native msvcrt dll? ~Maarten
Re: Something's rotten in git today...
Hey Dan, On 09/15/2011 02:02 AM, Dan Kegel wrote: > It might be just me, but I've seen five very strange test failures > today out of about 30 build/test runs. > Has anybody else noticed problems? > Does it happen if you try wine.git from before yesterday too? ~Maarten
Re: quartz: Fix converting between the media time and REFTIME
Hey, On 09/14/2011 05:07 PM, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > I've never tried to understand quartz, but I'd like to know whether quartz > expects particular behaviour from the underlying winmm or mmdevapi > time/position/length functions. > For instance, quartz says its clocks are monotically increasing, whereas no > such requirement is documented (or at least known to me) for the audio stream > positions. This may seem obvious, but then I came across some mailing list > where > people reported a sudden backward change in stream position when > pluggin/unplugging > earphones or the like. > Is quartz very decoupled from the underlying audio information? > Who stops the clock (if at all) while the stream is paused? There are 3 different times in quartz which makes it all confusing. However, wine just saves the time when pausing, and subtracts the difference when running again, so for audio clocks it would be a noop, but for wall clocks it's necessary to continue it again without skipping for the amount of time paused. http://msdn.microsoft.com/en-us/library/dd374626%28v=vs.85%29.aspx There is also a separate time for seeking, where it corresponds to the time in the file, for example when you seek to 03:10 in a video. This makes it kind of confusing, and wine doesn't handle it completely right in the parsers iirc, but with wineqtdecoder and winegstreamer, that isn't much of an issue. :) > BTW, in theory I have the tools to easily test quartz, using my interactive > MCI shell > http://bugs.winehq.org/show_bug.cgi?id=20232#c10 > > However every time I tried, I found mciqtz too underpowered to be able > to reasonably use it. :-( > > Using the MCI to use mciqtz (which in turn uses quartz.dll) goes as follows: > wine wintest.exe mcishell > > open foo.wav alias w type mpegvideo > status w length > play w from 0 notify wait > close w > # lots of other commands are available > > open foo.avi alias a type mpegvideo > window a state show > status a length > play a from 0 > close a > > Omit the "type mpegvideo" and mciwave or mciavi will be used instead of > mciqtz32.dll I have some mciqtz changes in http://repo.or.cz/w/wine/multimedia.git/blobdiff/327ce94048dba45c0ed8f727b44aaae6c71a92db..0dc86046e6bec6b0a308c9aab19b8ca4b1c08958:/dlls/mciqtz32/mciqtz.c But I lost track, so I don't know how valid those are still.
Re: audio: when is a "Resource temporarily unavailable"?
Hey, On 09/12/2011 02:14 PM, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > Bug #28056 involving FreeBSD and OSS exhibits: > warn:oss:AudioRenderClient_ReleaseBuffer write failed: 35 (Resource > temporarily unavailable) > > My own notes from times as old as wine-1.1.8 show the same error with ALSA: > err:wave:wodPlayer_WriteMaxFrags Error in writing wavehdr. Reason: Resource > temporarily unavailable > > The symbolic errno constant is EAGAIN=EWOULDBLOCK. So we look at write manpage.. EAGAIN or EWOULDBLOCK The file descriptor fd refers to a socket and has been marked nonblocking (O_NONBLOCK), and the write would block.POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable appli‐ cation should check for both possibilities. > Does anybody have a suspicion when/why this happens? > - is audio simply not reliable? > - is Wine not correctly driving audio output? > - ...? > > FWIW, my test experiments outside Wine recently produced EWOULDBLOCK > once despite non-blocking mode in ALSA, when attempting to write a small > number of frames, less than period_size. > > Is this failure really temporary or would it be safer > to close or reset the audio device given such an error value? > What's your experience? > Usually: you're trying to put more data in the audio buffer than the amount that can written. Similar errors happen on alsa, when trying to write > snd_pcm_avail(); Looks like a bug to me. ~Maarten
win7 pro sp1 x64 testbot live
Hi all, I've added a win7 sp1 testbot, it's currently in the extra vm's pool, so it requires some extra actions to find it, but if you want to run your tests against windows 7 sp1 with ie9 installed, you should now be able to. Happy testing!! ~Maarten
Re: The sad state of audio GetPosition
On 08/22/2011 05:31 PM, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > Maarten Lankhorst wrote: >> exclusive mode wants you to fill the entire buffer at the same time. > You're confusing this with exclusive + EVENTCALLBACK mode, which I'm not > using. > There are 4 combinations of shared/exclusive and EVENTCALLBACK or not. > Only one of the 4 needs no GetCurrentPadding and uses a full buffer each time. > > So far I've only been testing without EVENTCALLBACK > (though test_event contains some non-rendering code using it). http://msdn.microsoft.com/en-us/library/dd370844%28v=vs.85%29.aspx I meant an entire period then, this describes how windows handles it, my guess is that if you don't fill a period, you get an underrun, no matter how you handle it. >> it wouldn't surprise me if that's why it drops things.. > I'd expect GetBuffer to return AUDCLNT_E_BUFFER_SIZE_ERROR as documented for > that case. Ah true. Event driven is slightly different. :) > > Last week I wrote: >> Somewhat I found the old behavior more consistent. > Upon reflection, the new behavior is better. It makes more sense to drop > old frames than to keep them around thus play ghost sounds from the past. > > However, I'd even more prefer shared and exclusive mode to behave the same > *and* not drop frames. > I believe shared mode does not drop partial fills (based solely on what > GetPosition returns) and would have expected exclusive mode to do that > too. I don't know why MS decided to do that but I now see > why they recommend that programs add silence at the end of their > sound: it works around that odd behaviour. But it's not the same, wine doesn't officially handle exclusive mode. Instead it might be better to just report failure and only allow shared mode. On windows you're not required to support exclusive mode, and you can disable exclusive mode in the audio control panel. > > Maarten also wrote: >> I prefer 0 tracking, and just check the return value of snd_pcm_writei. > I can understand that but then we need to throw rate-limiting into the > discussion. We are talking about GetPosition here; computing > GetPosition solely on the base of snd_pcm_writei (let's throw in > avail_update without delay) gives us already known bugs, > e.g. PulseAudio backend audio 2s off video sync. Ah true, I do think you only want to observe underruns, and not act on them in GetPosition and GetClock, just report that all data is played. If that still breaks pulseaudio, I think it's time to get a real pulseaudio driver.. > And without snd_pcm_delay, the sole culprit would be: Wine. > If, OTOH, we use it, we can hope other projects will fix their bugs. > snd_pcm_delay would map to clock, while snd_pcm_avail maps to position, they're not the same, so it would make sense to handle them separately. ~Maarten
Re: The sad state of audio GetPosition
On 08/22/2011 02:13 PM, joerg-cyril.hoe...@t-systems.com wrote:
> Hi,
>
> These exclusive mode test failures look like nothing:
> render.c:1086: Test failed: GetCurrentPadding returned 576, should be 0
> render.c:1092: Test failed: Position 90720 at end vs. 91296 played frames
> but they made me completely rework my model of how mmdevapi works.
>
> 91296 = 90720 + 576 remainder
> 90720 = 720 * 126
> 720 = 15ms period at 48000 frames/s
>
> It looks like only a multiple of period_size frames are rendered.
> There are also test runs which end with GCP > period_size despite underrun
>
> Only Vista and w2k8 present these 2 errors. w2k8R2 and w7 only
> present the second one. In shared mode, GetCurrentPadding (GCP)
> returns 0 and GetPosition returns all submitted ("played") frames.
> What happened?
>
> Possible explanations:
> Vista + w2k8 exclusive mode:
> a) Bug in native that forgets to account for sub-period_size data. Or
> b) Play only multiples of period size. Wait until period_size data
>accumulates before sending the next packet.
Have to go with this one, exclusive mode wants you to fill the entire buffer at
the same time..
> c) other...
>
> w2k8R2 + w7 exclusive mode:
> a) Bug in native that sets GCP to 0 (like in shared mode). Or
> b) At each period tick, only play data if a full period is available.
>Drop partially filled buffers (explains padding = 0) instead of
>playing them much later when the buffer fills up (no ghost sounds).
> c) Bug in native that forgets to increment Position yet plays data.
> d) other...
If I look at msdn, exclusive mode wants you to fill the entire buffer in 1 go,
doing partial data doesn't make sense, and it wouldn't surprise me if that's
why it drops things..
> shared mode:
> a) At each 10ms period tick, mix a period_size of all streams that
>provided a full period of data. Ignore other streams yet always
>decrement GetCurrentPadding and sum played/ignored frames.
> b) At each 10ms period tick, mix all streams. Handle streams with
>padding < period_size as follows:
>- if previous frame was full, mix at beginning of buffer (trailer)
>- otherwise mix at end (expect beginning of next sound)
> c) At each 10ms period tick, mix all streams, padding streams with
>less than period_size frames with silence (i.e. mix at beginning).
> d) other...
> If I were MS, I'd implement heuristic b).
>
> This is all unlike what Wine does...
I'm inclined to believe it's C
> I'll probably write audible audio tests in the next few weeks to be
> able to test what native does (e.g. emit a short beep < period size
> every few ms and listen to what happens).
>
> Regards,
> Jörg Höhle
>
>
Re: The sad state of audio GetPosition
On 08/19/2011 05:10 PM, joerg-cyril.hoe...@t-systems.com wrote:
> Maarten Lankhorst wrote:
> [nice to hear from you]
>
>>> IMHO AudioClient_Stop must not map to
>>> snd_pcm_drop. It is more like snd_pcm_pause. Or perhaps simply lead
>>> ALSA into an underrun.
>> afaict pause, with reset mapped to drop,
> Indeed. But I believe I need a fallback because ALSA says that
> pause "works only on the hardware which supports" it.
>
>
>> I can't remember why pause didn't work, but if it works go for it.
> I was solely thinking aloud that pause is TRT, not tried out yet.
>
> However, I received test results from a "Windows 7 Ultimate" machine.
> It exhibits a similar bug -- in exclusive mode only:
> render.c:948: Test failed: Position 18191 too far after 100ms
> Shared mode works as my tests expect it (<= 48000/10 frames).
>
>
>>> +snd_pcm_status_alloca(&status);
>> HeapAlloc(GetProcessHeap(), HEAP_ZERO_FLAG, snd_pcm_status_sizeof())
>> or something like that if available please..
> Really? I don't want to go through the overhead of memory allocation
> when all I need is a stupid small amount of stack allocated memory.
>
>
>>> +if(!This->initted){
>>> +return AUDCLNT_E_NOT_INITIALIZED;
>> Unneeded part.
> Can't you obtain a handle to that COM object prior to
> calling Initialize which sets This->fmt?
No.
>> Follow that flow..
> I beg your pardon?
IAudioClock is not available until Initialize has succeeded, so the check above
is pointless.
>
>>> +if(0){
>>> +avail_frames = snd_pcm_status_get_avail(status);
>>> +delay_frames = snd_pcm_status_get_delay(status);
>> if 0 is bad...
> I tried out pcm_status because somebody in alsa-devel mentioned that
> it allows to grab avail + delay in one (sync'ed?).
> However, I found delay to be always 0 inside status!?!
>
> Also, I found out that I need to call avail_update and delay
> in a particular order, otherwise I get stale values from an old call
> prior to the last sleep...
>
>
>>> +if(avail_frames <= This->bufsize_alsa + MAX_LATE_SECONDS *
>>> This->fmt->nSamplesPerSec
>>> + && delay_frames > 0)
>> Isn't delay_frames < 0 the definition of underrun?
> Indeed.
> There are potentially N distinct underruns:
> - the front end -- what snd_pcm_avail_update knows about;
> - intermittent buffers (USB);
> - the speaker -- what snd_pcm_delay knows about.
> There could be a short front-end buffer underrun that
> goes unnoticed by the speaker if the TCP or USB in
> between buffers enough data *and* is able to speed up.
>
>> no point in adding MAX_LATE_SECONDS
> That is some form of guard against broken values. E.g. people reporting
> in alsa-devel that PA sometimes complains about avail ~ MAXINT and such weird
> values.
>
>> Getting an avail update again? Why?
> The theory is:
> position = written_frames(into ALSA) - delay
> and translates to:
> This->written_frames - This->held_frames - delay
>
> However sometimes I can't trust delay.
> I still need to figure out when.
> - IIRC after an underrun, snd_pcm_delay yields error X.
> - or was it before starting?
> - ...
>
> The upper bound on position is always:
> This->written_frames(ReleaseBuffer) - This->held_frames - ALSA_padding
> (what ALSA's front end has not yet processed, in absence of underrun).
>
> Perhaps that would be robust:
> 1. Compute upper bound
> 2. position = clamp(0, delay > 0 ? written-delay : written, upper_bound);
> 2b. except when not yet started ...
> 2c. except while stopped ...
>
> I was even considering:
> 3. if position < This->previous_position stick to previous...
>
> Yet perhaps it's better to allow intermittent garbage values
> than to stick to garbage!
>
> OTOH, the delay values I see in the logs are subject to such variation (with
> PA)
> that I'm considering going with a clock instead, or perhaps:
> - query delay once per tick (e.g. 10ms) => last_pos
> - when asked, compute position from last_pos + time since tick * rate
>
> The last_pos slot may be needed anyway once stopped in pause mode.
>
Don't worry about underruns and checking the way you do is fragile, I prefer 0
tracking, and just check the return value of snd_pcm_writei. Experience taught
me this is the most stable way of doing underrun handling in alsa. Remove all
the checks you're doing please, they will just break things more.
Re: What gstreamer plugins are actually needed?
On 08/20/2011 12:15 AM, Scott Ritchie wrote: > I'm trying to cleanup a bit of a packaging mess whereby Wine currently > pulls in 250 or so gstreamer plugins. > > Which ones are actually useful for applications? Do we even know? > > Thanks, > Scott Ritchie > > wine-gstreamer only needs decoding and parser filters, and gstreamer-plugins-base, but honestly I'd leave in as many as possible because you never know which one wine wants. I honestly don't know about the subsets, it seems people file bugs about tons of exotic codecs because older games have a wide variety of those.. ~Maarten
Re: The sad state of audio GetPosition
On 08/19/2011 01:30 PM, joerg-cyril.hoe...@t-systems.com wrote:
> Reece,
>
> I wrote the text in a hurry and forgot that Wine results
> are most interesting to me with my patch applied.
>
> Please use my patch with something like:
> WINETEST_DEBUG=3 WINEDEBUG=warn+alsa wine mmdevapi_test.exe render
>
>> render.c:897: Test failed: Position 24000 too far after 200ms
> That's not PA's fault. IMHO AudioClient_Stop must not map
> to snd_pcm_drop. It is more like snd_pcm_pause. Or perhaps
> simply lead ALSA into an underrun. I've not made up my mind
> yet as the models (mmdevapi vs. ALSA) are different w.r.t. buffering.
afaict pause, with reset mapped to drop, but for historic reasons
that didn't work (surprise! love from dmix). Even worse,
snd_pcm_drain would deadlock if called twice.
I can't remember why pause didn't work, but if it works go for it.
>
> As you can see, the patch is nowhere final.
>
> #From 60689763bd21513bd9b8dbd2df3abc5f2586f1f2 Mon Sep 17 00:00:00 2001
> #From: =?UTF-8?q?J=C3=B6rg=20H=C3=B6hle?=
> Date: Wed, 17 Aug 2011 21:04:34 +0200
> Subject: winealsa: Play with GetPosition.
>
> ---
> dlls/winealsa.drv/mmdevdrv.c | 52 ++---
> 1 files changed, 43 insertions(+), 9 deletions(-)
>
> diff --git a/dlls/winealsa.drv/mmdevdrv.c b/dlls/winealsa.drv/mmdevdrv.c
> index 3e3edc3..51e9b81 100644
> --- a/dlls/winealsa.drv/mmdevdrv.c
> +++ b/dlls/winealsa.drv/mmdevdrv.c
> @@ -2289,26 +2289,60 @@ static HRESULT WINAPI
> AudioClock_GetPosition(IAudioClock *iface, UINT64 *pos,
> UINT64 *qpctime)
> {
> ACImpl *This = impl_from_IAudioClock(iface);
> -UINT32 pad;
> -HRESULT hr;
> +int err;
> +snd_pcm_uframes_t avail_frames;
> +snd_pcm_sframes_t delay_frames, pad_frames;
> +snd_pcm_status_t *status;
>
> TRACE("(%p)->(%p, %p)\n", This, pos, qpctime);
>
> if(!pos)
> return E_POINTER;
> +snd_pcm_status_alloca(&status);
HeapAlloc(GetProcessHeap(), HEAP_ZERO_FLAG, snd_pcm_status_sizeof()) or
something like that if available please..
> EnterCriticalSection(&This->lock);
>
> -hr = IAudioClient_GetCurrentPadding(&This->IAudioClient_iface, &pad);
> -if(FAILED(hr)){
> +if(!This->initted){
> LeaveCriticalSection(&This->lock);
> -return hr;
> +return AUDCLNT_E_NOT_INITIALIZED;
> }
Unneeded part. Follow that flow..
>
> -if(This->dataflow == eRender)
> -*pos = This->written_frames - pad;
> -else if(This->dataflow == eCapture)
> -*pos = This->written_frames + pad;
> +if((err = snd_pcm_status(This->pcm_handle, status)) < 0){
> +LeaveCriticalSection(&This->lock);
> +ERR("ALSA status error: %d (%s)\n",
> +err, snd_strerror(err));
> +return E_FAIL;
> +}
> +if(0){
> +avail_frames = snd_pcm_status_get_avail(status);
> +delay_frames = snd_pcm_status_get_delay(status);
> +}else{
> +avail_frames = snd_pcm_avail_update(This->pcm_handle);
> +err = snd_pcm_delay(This->pcm_handle, &delay_frames);
> +if(err < 0){ /* e.g. in STATE_PREPARED */
> +ERR("ALSA delay error: %d (%s)\n",
> +err, snd_strerror(err));
> +delay_frames = 0;
> +}
> +}
if 0 is bad...
> +pad_frames = This->bufsize_alsa - avail_frames;
> +#define MAX_LATE_SECONDS 5 /* huge USB or network latency */
> +if(avail_frames <= This->bufsize_alsa + MAX_LATE_SECONDS *
> This->fmt->nSamplesPerSec
> + && delay_frames > 0)
> +*pos = This->written_frames - This->held_frames - delay_frames;
Isn't delay_frames < 0 the definition of underrun? no point in adding
MAX_LATE_SECONDS
> +else if(pad_frames > 0)
> +/* delay may be slightly < 0 past reset */
> +*pos = This->written_frames - This->held_frames - pad_frames;
> +else
> +*pos = This->written_frames - This->held_frames;
> +/* FIXME: if(This->dataflow == eCapture) */
> +ERR("avail %lu, delay %ld, sum %ld, alsa %lu, written %lu, held %u:
> %lu\n",
> +avail_frames, delay_frames, avail_frames+delay_frames,
> This->bufsize_alsa, (ulong)This->written_frames, This->held_frames,
> (ulong)*pos);
> +avail_frames = snd_pcm_avail_update(This->pcm_handle);
> +err = snd_pcm_delay(This->pcm_handle, &delay_frames);
> +ERR("avail %lu, delay %ld, sum %ld, alsa %lu, written %lu, held %u:
> %lu\n",
> +avail_frames, delay_frames, avail_frames+delay_frames,
> This->bufsize_alsa, (ulong)This->written_frames, This->held_frames,
> (ulong)*pos);
>
> LeaveCriticalSection(&This->lock);
>
Getting an avail update again? Why?
Re: w9x testbot state?
Hey James, On 08/07/2011 05:12 AM, James McKenzie wrote: > On 8/3/11 7:10 AM, Maarten Lankhorst wrote: >> On 08/01/2011 07:12 PM, joerg-cyril.hoe...@t-systems.com wrote: >>> Hi, >>> >>> what happened to the w9x test bots? I'd like them to run some kernel32 >>> tests. >>> Testbot says "offline". >>> >> They were hosted at Gé's house. Testbot can no longer reach them. >> > Are there plans to 'revive' them? > > If not, if I am provided with a test file, I do have a Windows98SE disk here > that I could run tests against. This would be a manual process and would take > time. Winetestbot is in only urgent maintainance mode until all non-winetestbot related services are moved off. If I can find the windows vms themselves, I'll bring them back to live, otherwise you'll have to wait until the servers are maintained properly again. :) ~Maarten
Re: w9x testbot state?
On 08/01/2011 07:12 PM, joerg-cyril.hoe...@t-systems.com wrote: > Hi, > > what happened to the w9x test bots? I'd like them to run some kernel32 tests. > Testbot says "offline". > They were hosted at Gé's house. Testbot can no longer reach them. ~Maarten
Re: Glitch-free iTunes?
Hey, On 07/05/2011 10:49 AM, Charles Davis wrote: > On 7/5/11 2:23 AM, Damjan Jovanovic wrote: >> On Tue, Jul 5, 2011 at 10:13 AM, Stefan Dösinger >> wrote: >>> Do we need full-fledged support for USB drivers for iTunes? I've been told >>> in >>> the past that all we need to do is properly report the new USB drive to >>> iTunes >>> when an iPod is attached, and can leave the USB mass storage handling to the >>> Linuy OS. Of course "properly reporting" isn't as simple as creating a drive >>> letter and setting its type to USB drive. >>> >>> I'm sorry to interrupt this nice project management discussion by throwing >>> in >>> a technical question :-) >>> >>> >> It used to work that way, but Dan Kegel's analysis of a recent version >> of iTunes seems to indicate it now pulls in USBD.SYS. Maybe they >> changed it or maybe they now do direct USB I/O in addition to going >> through the mass storage interface? > I have a Mac, and an iPod Touch. When I plug the iPod in, it doesn't > show up as an external disk in the Finder. So on Mac, iTunes definitely > does direct USB I/O. It's probably safe to assume it does on Windows, too. There are 2 ways really. Old ipods used usb mass storage which I had working at 1 point, but in a hacky way. ipod touch and iphone need direct usb, which never worked. ~Maarten
Re: Regression today?
Hey Susan, On 06/21/2011 01:03 PM, Susan Cragin wrote: > >Susan Cragin wrote: > >> I think a regression was introduced today. I got the following trying to > >> run NatSpeak 11.0 with today's git. > >> wine-1.3.22-255-g4c0c0d3 > >> Should I do a regression test and file a bug, or is it obvious from this? > >> Or is it me -- something to do with my new Oneiric Ocelot? Or the new 3.0 > >> kernel? > >The 3.0 kernel works for me now (3.0-rc4) as good as any of the previous > >stable releases. Before -rc4 I get a kernel oops after the radeon GPU > >lockup + soft reset I get with SC2. Now I'm left with the GPU lockup but > >previous kernels show the same problem. > > Hmmm... > I have the 3.0-1.2. I haven't really tested naturally speaking lately, but in git reflog you can always find back your previous HEAD and test with it once to see if wine has regressed. I'm running rc4 with some usb patches to fix suspend here. :-) I also use nouveau.git from time to time for testing, but it's still not entirely stable for me. ~Maarten
Re: deadlock in mmdevapi AudioClient_Stop (winealsa.drv/mmdevdrv.c)
Hi Joerg, Op 15-06-11 10:00, joerg-cyril.hoe...@t-systems.com schreef: > 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 ceases the audio client object lock (This->lock). > > AudioClient_Stop performs > EnterCriticalSection(&This->lock); then > DeleteTimerQueueTimer(g_timer_q, This->timer, INVALID_HANDLE_VALUE); > > Now imagine Stop is invoked, EnterCriticalSection executed then the thread is > preempted. > Suppose the timer callback kicks in: alsa_push_buffer_data will block on > This->lock. > When the thread is resumed, DeleteTimerQueue will hang forever waiting for > all timer callbacks to come to an end. > > My opinion is that critical sections are great to prevent concurrent > execution while > things are running, but they are hell to tear down properly. > > IMHO, LeaveCriticalSection + Re-EnterCriticalSection around DeleteTimerQueue > is not a solution. > I consider using Leave+EnterCS around anything that can wait/block an > anti-pattern > (there are a few places like that in Wine). I believe a "restart op" is > needed in general > (like a "restart transaction if it failed" in databases) as anything could > have happened while waiting. You're right, This->timer should be set to NULL inside the lock, and DeleteTimerQueueTimer should be run afterwards. ~Maarten
Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
Hey Stephane, Op 12-06-11 10:26, BACRI Stephane schreef: > Hi Maarten. > Thx for your answer. Joerg's comment was on the code surrounding the patch, > not on the patch. That's why I did not understand that I had to correct this > code. > Shall I propose a new patch with these correction? Or an additional one? Or > may the maintainer of winealsa.drv do so? I don't know why it was rejected, it might be best to fix the thing first. ~Maarten
Re: About building test suite for Windows
Op 12-06-11 07:54, Patrick Gauthier schreef: > Hi, > > As I was writing my task dialog test I ran into a few problems trying to > test on Windows... > > First, I tried building it using make crosstest but I keep getting this: > > $ gmake crosstest > crosstest is not supported (mingw not installed?) > gmake: *** [crosstest] Error 1 > > I am on FreeBSD 8.2-RELEASE (i386), I have the following mingw ports > installed (using pkg_add) > > mingw32-bin-msvcrt-r3.18.a3.14 > mingw32-binutils-2.21,1 > mingw32-directx-20020518 > mingw32-gcc-4.5.0_1,1 > mingw32-pdcurses-3.4 > mingw32-pthreads-2.8.0 What is your mingw prefix? ~Maarten
Re: winealsa.drv/midi.c: Adds the midi MTC Quarter Frame messages support.
Hello, 2011/6/11 BACRI Stephane : > Hi all. > Was there something incorrect in this patch I submitted in may, or in the > way I submitted it? > Perhaps should I have mentioned that it had been tested in several ways with > hardware & software. joerg commented on this 11th may: http://wine.1045685.n5.nabble.com/winealsa-drv-midi-c-Adds-the-midi-MTC-Quarter-Frame-messages-support-td4387453.html ~Maarten
Re: Ge (Greg) van Geldorp
Sad news indeed. His work on getting winetestbot integrated into wine was amazing. He was also nice every time I talked to him. I'll miss him. Hierbij mijn steunbetuiging aan zijn nabestaanden. ~Maarten
Re: Tahoma Font License
Hi mark, 2011/5/25 Mark Page : > > I am a bit confused by the Wine "tahoma" license: "Wine Tahoma Regular" ... > GNU Lesser General Public License 2.1 > > It would be useful to add the font to the ClanLib SDK resources (ClanLib has > a zlib style license) > > It is not clear how a font can be licensed using LGPL, since LGPL is based > around software libraries. > > Ideally I feel it should have a creative commons license > > I believe Creative commons did not exist when that font was created tahoma.sfd: Copyright: Copyright (c) 2004 Larry Snyder, Based on Bitstream Vera Sans Copyright (c) 2003 by Bitstream, Inc. Font renamed in accordance with former's license. Please do not contact Bitstream Inc. for any reason regarding this font. So just look up the original without contacting bitstream inc. ? Cheers, Maarten
requesting review and/or testing for directsound changes
Hi all, with http://repo.or.cz/w/wine/multimedia.git and http://repo.or.cz/w/openal-soft.git you should be able to get the benefits of openal-soft's mixer while continuing to use whatever driver you want for mmdevapi. As a result directsound will only support openal-soft, but multi channel is suddenly supported, as is support for the floating point format. 24-bits and 32-bits int are currently not, but as soon as that capability is added to openal-soft.git wine will have a nice working dsound implementation with support for a lot of things that are missing now. The resampling code will also be a lot better and you should expect a higher quality when resampling is used. The capture changes should work nicely, and I don't expect a problem with that, since it's based on openal. The rendering code is essentially reviving the old dsound-openal, and outputting it to mmdevapi. Note: 24-bits and 32-bits int are unsupported and will most likely cause a crash, disable the #if 1 in get_fmtstr_EXT to prevent lying about support. It was put in place so the wine dsound tests would pass. A dsound.dll.so binary with openal-soft.git statically linked in can be found at: http://www.astro.rug.nl/~lankhorst/dsound.dll.so If you're using pulseaudio, patch your 32-bits alsa-plugins with the attached patch, or silence may occur when using the new mmdevapi drivers. Cheers, Maarten 0001-Pulse-Fix-snd_pcm_avail-returning-0-in-some-cases.patch Description: application/mbox
Re: Try to implement my first stub function - AbortPrinter() - (try 4)
Hello, Op 14-04-11 10:37, Loïc Maury schreef: Hello, From what was said from the last comments, I have modified the code and I have added the test patch. What do you think ? You're doing all the HeapFrees manually, is there a destruction function you can use? Cheers, Maarten
Summer of Code 2011 is on!
Hi all, As you may have known wine has been accepted for summer of code 2011 as a mentoring organization. As such the wine project is now looking for students to participate this year with wine. On our wiki page[1] you can find some ideas, but if you come up with your own idea you will have a lot better chance of getting accepted, as long as you listen to feedback. Summer of code is not just learning to code, but also getting your code accepted into the wine git tree. We'll try to help with that, but the interaction with the wine community is definitely required. For some advice you can read [2] for example. [1] http://wiki.winehq.org/SummerOfCode [2] http://bit.ly/efXVqz Cheers, Maarten PS1: Is anyone willing to add a 'news' blurb about summer of code to the main site? PS2: Also looking for mentor applies.
Re: kernel32: CreateProcessA should not call CreateProcessW directly
Hi Dan, Op 16-03-11 20:06, Dan Kegel schreef: Does that work when compiling with -O3 ? Maybe you need a noinline attribute, http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes I don't think it will ever be inlined because of the calling convention differences. Doing a dumb -O3 to be sure confirms it. Cheers, Maarten.
Re: winmm DriverCallback with 0 CALLBACK_WINDOW
Hey, Op 16-03-11 15:52, joerg-cyril.hoe...@t-systems.com schreef: Hi, Testbot job #9994 proves that Wine and native differ in their handling of a 0 CALLBACK_WINDOW handle. Wine's PostMessage redirects a 0 handle to PostThreadMessage(currentThreadID()), while native finds no notification on the thread's queue in such a case. (As a consequence, Wine's player thread will send notification messages to itself ...) Considering PostThreadMessage(NULL) is supposed to post to the thread queue this is fine, feel free to fix though. Alas, the test case does not allow to tell whether the difference in with - winmm:DriverCallback or - whether winmm:midiOutOpen sees the 0 handle and remap to CALLBACK_NULL internally, before ever calling DriverCallback. Likewise, a NULL CALLBACK_FUNCTION does not cause a crash since w2k, but we don't know whether winmm:DriverCallback catches that case (as Wine does nowadays) or whether winmm:wave/midi/mixer/Open remap that to maybe CALLBACK_NULL and proceed. Is there any means to tell the difference, short of writing a real driver with debug output and installing it on a native system, having native DriverCallback called directly? In that case I wouldn't worry about it, just handle it in DriverCallback to save on duplication. BTW, why does winealsa.drv:mixer use a custom callback mechanism instead of the generic DriverCallback that the other winmm drivers use? Historical reasons only? I honestly can't remember. Probably because I only checked with sndvol32, feel free to send in a patch for it though. Cheers, Maarten
Re: lifetime of the MIDI/MIXER/WAVEOPENDESC structure?
Hey, Op 16-03-11 16:03, joerg-cyril.hoe...@t-systems.com schreef: Hi, MSDN is silent about the lifetime of the MIDI/MIXER/WAVEOPENDESC structure that is deliverred via the W/MODM_OPEN/MXM_OPEN message to the winmm drivers (WAVEOOPENDESC is not even documented for MS-Windows (not CE) anymore). http://msdn.microsoft.com/en-us/library/ff537518%28v=vs.85%29.aspx MIDIOPENDESC IMHO, it would make a lot of sense if the structure remained allocated for the whole lifetime of the open/close cycle, so the driver need not make a copy of it. Is there anybody who knows more about this topic? I wouldn't count on it, the structure is allocated on the stack, see for example winmm.c: WAVE_Open Cheers, Maarten
Re: winealsa.drv: Waveout rewrite to allow multiple waveopens
Hi Joerg,
Op 08-03-11 12:36, joerg-cyril.hoe...@t-systems.com schreef:
Maarten,
let me apologize for barely taking the time to look at the extra patches
you write outside of the main git tree. I hope other people find more time
to try them out with real apps and report on their findings.
Here are a few comments of mine on your winealsa rewrite (beside bug #22261,
comment #6).
- It's been a pleasure to hear mciwave+winealsa open multiple devices
concurrently
with dmix mixing all playing sounds thanks to this rewrite.
- wodNotifyDoneList is called from within a critical section in wodTick().
This may break havoc with DCB_FUNCTION callbacks, as the driver
does not appear to be re-entrant.
EnterCriticalSection offers no protection from within the same thread.
Some apps are known to call waveOutClose() from within the DONE callback.
Didn't check yet. Maybe useful for the winmm->mmdevapi stuff.
Of course you may delegate this issue to a solution to bug #3930. I'd be
curious
if you have any ideas about how to delay notification to a later point
in time, "until it is safe to do" -- native appears to delay as well.
- You may wish to look into bug #22880.
Lemmix is a small (143KB) downloadable application that opens two waveout
devices.
It plays both music and sound effects on Mac OS using the winecoreaudio
driver, but fails to do so with your ALSA driver, although both devices open
and WINEDEBUG=+wave shows calls to waveOutWrite. I could not figure out
what goes wrong.
@@ -488,8 +488,9 @@ static DWORD wodReset(waveimpl *dev, wavestreamimpl
*wwo) {
savedqueue = wwo->queue;
wwo->queue = wwo->loop = NULL;
wwo->ofs = 0;
-wwo->stopped = 1;
snd_pcm_drop(wwo->pcm);
+snd_pcm_prepare(wwo->pcm);
+snd_pcm_start(wwo->pcm);
LeaveCriticalSection(&dev->crst);
wodNotifyDoneList(wwo, savedqueue);
Cheers,
Maarten
Re: mountmgr.sys: start detecting USB devices
Hi Damjan, Op 02-03-11 18:52, Damjan Jovanovic schreef: Changelog: * mountmgr.sys: start detecting USB devices I'd love to get this kind of work in, but since libhal has been deprecated for a while, wouldn't it be better to use libudev directly instead of expanding our usage of libhal? Cheers, Maarten
Re: Fwd: Applications for Mentoring Organizations Now Being Accepted
Hi Dan, Op 28-02-11 21:41, Dan Kegel schreef: So, shall I do the honors? I've already been applying wine for summer of code this year, haven't finished it up though, you could always join as second backup admin. However I'd like everyone to have another look at our http://wiki.winehq.org/SummerOfCode page. I want to be sure that they're all doable within the allotted time frame, and that they won't be too hard for people just starting on wine. If people can add a few more good ideas I'd be happy. It feels like I'm missing some outside of direct3d. Cheers, Maarten
Re: Valgrind --malloc-fill=A5 --free-fill=DE crashes Wine
Hi Joerg,
Op 21-02-11 12:26, joerg-cyril.hoe...@t-systems.com schreef:
Hi,
I used to run Valgrind with the additional options
--malloc-fill=A5 --free-fill=DE
around Wine 1.2 times. Now I retried it and it crashes
Wine 1.3.13 and 1.3.14 (it fails to load kernel32.dll).
It turns out that malloc-fill is harmless, -free-fill causes havoc currently.
Am I the only one using or seeing this (Ubuntu Lucid)?
It's most likely a valgrind/wine bug, does this patch work?
Cheers,
Maarten
>From 344c2234deb65b514bf9f10b5e894bde7c49976c Mon Sep 17 00:00:00 2001
From: Maarten Lankhorst
Date: Fri, 26 Nov 2010 00:03:40 +0100
Subject: [PATCH 08/24] ntdll: HACK to prevent valgrind --free-fill error
---
dlls/ntdll/heap.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/dlls/ntdll/heap.c b/dlls/ntdll/heap.c
index df94410..933d998 100644
--- a/dlls/ntdll/heap.c
+++ b/dlls/ntdll/heap.c
@@ -747,7 +747,7 @@ static void *realloc_large_block( HEAP *heap, DWORD flags,
void *ptr, SIZE_T siz
ARENA_LARGE *arena = (ARENA_LARGE *)ptr - 1;
void *new_ptr;
-if (arena->block_size - sizeof(*arena) >= size)
+if (arena->block_size - sizeof(*arena) >= size && !RUNNING_ON_VALGRIND)
{
SIZE_T unused = arena->block_size - sizeof(*arena) - size;
@@ -1820,7 +1820,7 @@ PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags,
PVOID ptr, SIZE_T size
oldBlockSize = (pArena->size & ARENA_SIZE_MASK);
oldActualSize = (pArena->size & ARENA_SIZE_MASK) - pArena->unused_bytes;
-if (rounded_size > oldBlockSize)
+if (rounded_size > oldBlockSize || RUNNING_ON_VALGRIND)
{
char *pNext = (char *)(pArena + 1) + oldBlockSize;
@@ -1835,7 +1835,8 @@ PVOID WINAPI RtlReAllocateHeap( HANDLE heap, ULONG flags,
PVOID ptr, SIZE_T size
}
if ((pNext < (char *)subheap->base + subheap->size) &&
(*(DWORD *)pNext & ARENA_FLAG_FREE) &&
-(oldBlockSize + (*(DWORD *)pNext & ARENA_SIZE_MASK) +
sizeof(ARENA_FREE) >= rounded_size))
+(oldBlockSize + (*(DWORD *)pNext & ARENA_SIZE_MASK) +
sizeof(ARENA_FREE) >= rounded_size) &&
+!RUNNING_ON_VALGRIND)
{
/* The next block is free and large enough */
ARENA_FREE *pFree = (ARENA_FREE *)pNext;
--
1.7.2.3
Re: [PATCH 01/13] dsound: New sample rate converter core functions.
Hi Krzysztof, Op 11-02-11 12:16, Krzysztof Nikiel schreef: 2011/2/11 Dmitry Timoshkov: Krzysztof Nikiel 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. Thanks for looking at the format conversion functions. The splitting can probably be done in 4 parts: 1. If you have any generic bugfixes, put them in the first few patches. Once those are in you can look at the other parts. Each bugfix should probably be its own separate patch. 2. Single patch to remove the old behavior. At this point you probably only want the mixing to work without requiring reconversion, and have a FIXME or something to say rate conversion is unavailable. 3. A bunch of patches implementing new rate conversion, one logical step at a time. The only requirement is that you want to be able to build wine without it failing, and if possible even running directsound, even if the result is insane.. Having mkfir in the way you put it there will probably not work, since some people will build wine out of tree. My guess is that you should put that in tools. Since the contents of the file won't change often it may just be enough to have the .c file there and have a note in the mkfir.h header that it was generated by tools/mkfir.c, but I'm not AJ so he would have to decide. The reason for this kind of splitting is that even if the code is broken between the removal of the old code and the last patch, it's a lot easier to see bugs. Usually in a patch like this you will spot 2 or 3 bugs you wouldn't have otherwise spotted because you look at the code in logical parts. This also makes bisecting a lot easier. Otherwise you know what commit caused the regression, but you have no idea what part of the code is. Cheers, Maarten
[rfc] dsound: decrease sound latency
Hi all, Please test this and let me know if it's causing any problems in sound playback, preferably with media applications and games, any feedback would be appreciated. The patch won't fix existing problems, it should just decrease the audio lag. As such I would prefer only to receive feedback on issues INTRODUCED or FIXED by this patch. If it's causing issues, I want to know: 1. Whether pulseaudio is running, and pulseaudio --version 2. What distribution you're using 3. (If you know it) the version of alsa's libraries, packages libasound2 and libasound2-plugins in debian/ubuntu Cheers, Maarten dsound.patch Description: application/mbox
Re: quartz: Start DirectSound renderer as soon as possible.
Hi Erich, 2010/11/28 Erich Hoover : > On Sun, Nov 28, 2010 at 8:28 AM, Maarten Lankhorst > wrote: >> ... >> There are other ways to handle this. What you're doing is wrong. I'm >> guessing the assert(!pSample); is wrong, if it's flushing it ought to >> return all samples held. If it has a sample and returned VFW_E_TIMEOUT >> I guess it has to break. The preferred allocator would have to be a >> separate patch. > > If you'd prefer I can attach these separately, but I really consider > this to be three separate patches (applied in this order): > 1) Freeing all pending samples when terminating > 2) Only asserting when VFW_E_TIMEOUT actually times out > 3) Passing a preferred allocator > > Patch 3 is the "main problem" for F3 and the first two are issues with > paused/stopped filters. Without Patch 1 then Patch 3 always causes > Fallout 3 to crash when exiting the main menu, and it will sometimes > (very rarely) crash when exiting the menu without Patch 2. It sounds > to me like you're taking issue with Patch 2 (the VFW_E_TIMEOUT > portion), and I can look into better ways to do this part. The big > thing that I was hoping you could help me with is that, with commit > 64b14c0ecdd13530a92ff636c451523a99253a0b applied, once you exit the > main menu then absolutely all the audio stops working - but only when > both your commit and my patches are applied. It's not obvious to me > how these patches could interact with your commit in this way, and > nothing obvious stands out in the log, so I was hoping you could point > me in the right direction for where to start figuring this out. > Thanks so much for taking the time to look at this. Well, that is because that assertion is wrong. pSample can be returned on timeout when flushing, but it wouldn't contain any data. I assume this is the bug you're hitting in patch 2, so if it holds a sample just break, and release all pSamples returned by that function. Why my commit breaks things? If all sound stops working I'm guessing it is a sound bug. Cheers, Maarten
Re: quartz: Start DirectSound renderer as soon as possible.
Hi Erich, 2010/11/21 Erich Hoover : > I've been working on a set of patches (compiled together and attached for > your convenience) to fix the background music in Fallout 3 (Bug #24478) and > I've run into some trouble recently with commit > 64b14c0ecdd13530a92ff636c451523a99253a0b. Before that commit (or removing > that commit in current git) and applying the patches allows the music to > function in both the main menu, properly stop when the menu is closed, and > later play again when the user is in the game. With said commit applied > these patches still permit the background music to work when at the main > menu; however, the moment the "stop" occurs on exiting the menu then all > audio in the entire game ceases to function. I would really appreciate any > feedback you can provide or pointers on where to look for the source of this > problem. Thanks in advance! There are other ways to handle this. What you're doing is wrong. I'm guessing the assert(!pSample); is wrong, if it's flushing it ought to return all samples held. If it has a sample and returned VFW_E_TIMEOUT I guess it has to break. The preferred allocator would have to be a separate patch. Cheers, Maarten
Re: mciavi should be rewritten using the AVIFile interface
Hi Joerg, 2010/11/17 : > Hi, > > MSDN documents (and I verified) that the MCIAVI allows to access an > open AVIFile object via the special name @NN...NN (decimal address). > Conversely, > open @-1024 type avivideo alias a > crashes native at address c000 -- except on w95 (KB140750). > > This makes it likely that MCIAVI internally uses the AVIFile API > (it might also pull the MMIO file handle out of the AVIFile structure). > > Furthermore, other parameters that the MCI exports, e.g. > MCI_ANIM_*_SPEED, map to what the AVIFile objects provide and is not > present in MMIO handling, reinforcing the hypothesis that the MCIAVI > uses the AVIFile API. > > Hence mciavi.c should be rewritten to use the AVIFile API. I hope > that doing so will prevent a skew that I've observed with some apps, > where sound and video rendering do not match after a few seconds. Just symlink mciqtz32.dll.so to mciavi32.dll.so ? Cheers, Maarten
Re: Where in the code does wine read fonts?
Hi Per, On 04-11-10 14:38, Per Olesen wrote: Hi! I am trying to figure out how wine reads fonts on startup but am having a little trouble. I checked out the source and found a lot of good stuff in "winex11.drv/xfont.c", but I am not sure this is actually the code, that gets executed when my wine boots. What I experience, is that wine reads the X fonts, using the fontconfig library. Is that correct? Maybe I should say *why* I am digging into the font handling in the code. When I rebuild the system fontcache (using "fc-cache"), wine suddenly gets painfully slow to boot. When I revert to the old cache I had before rebuild, it gets fast again. Listing the cache content (using "fc-list") yields the same amount of fonts before and after rebuild, so I find it strange with the extra boot time. Actually, it would be better for me to NOT have wine read the X fonts (I think). So, I tried digging in to understand it better from the code. Is there a central place in the source code I am missing, that could lead me to the lightsource :-) ~/wine/dlls$ git grep -l FONTCONFIG gdi32/Makefile.in gdi32/freetype.c winex11.drv/xrender.c Cheers, Maarten
Re: [PATCH 2/4] quartz: Fix PullPin_EnumMediaTypes
Hi Eich, 2010/11/7 Erich Hoover : > Is there some reason you chose to add an additional function for this, > rather than fill in pPinImpl->pin.pFuncsTable? I ask because I was > working on this issue last night and submitted an attachment to Bug > #24782 for people to try: > http://bugs2.winehq.org/attachment.cgi?id=31770 Mostly consistency, the other functions from pFuncsTable are overridden as well in case of the parser and winegstreamer. Cheers, Maarten
Re: Purist keyword?
Hi Austin, 2010/10/30 Austin English : > On Saturday, October 30, 2010, Shachar Shemesh wrote: >> On 30/10/10 19:25, Austin English wrote: >> >> I meant bugs that only occur by manually removing native dlls. The >> report summaries are usually clear enough, I was hoping to get an easy >> way to search for them and separate them from 'normal' bugs. >> >> >> >> >> I suspect your use of the word "native" is different than the one defined by >> Wine (see, for example, >> http://www.winehq.org/docs/wineusr-guide/config-wine-main). >> >> Native DLLs, in Wine, are DLLs that come from a real Windows system. This as >> opposed to "built-in DLLs", that are DLLs compiled for Wine as winelib, >> carrying the >> ".dll.so" extension. > > No, I mean native. Some applications install native redistibutables, > e.g. msvcr80 or d3dx9_36. > >> To the best of my knowledge, Wine arrives with no native DLLs at all, and >> thus one cannot remove any. Can you point to a bug report you might tag as >> "purist", so we can all get on the same page? > > Sure. I forget not everyone follows wine-bugs, so this was unclear. > See http://bugs.winehq.org/show_bug.cgi?id=24510. Blur runs out of the > box, but if you remove the bundled native dll (being a purist) the > game fails, because wine is missing a dozen or so functions. There are > several similar bugs. I really don't see what 'purist' adds, if a game fails because a builtin dll is missing a function, why would it matter if the game installs a native dll by default or not? The bug is still in the builtin dll, whether you use the builtin dll or not. ;) Cheers, Maarten
Re: Possible patch for #12706
Hi Jeff, 2010/6/25 Jeff Cook : > This is a patch that makes WINE detect snd_usb_audio mics and assign > them a mixer and working master control. See bug #12706 for more > information about this problem: http://bugs.winehq.org/show_bug.cgi?id=12706 > > I wasn't able to test it completely because I wasn't able to switch my > default input device to the USB mic and no one in IRC is helping with > this, but it might make things work because theoretically the only > problem was that WINE was ignoring devices that looked like > snd_usb_audio's microphones. I suggest that someone who CAN get > snd_usb_audio mic as their default test it out and confirm, I would > really appreciate that. If you really want to force it, do lsmod |grep snd and do modprobe -r over all driver modules, snd-usb-audio and usually snd-hda-intel or something like that. Then modprobe snd-usb-audio and it will be the only audio device, so its always the default. ;) ~Maarten
Re: Question about video capture and rendering and encoding in wine
Hello, 2010/6/23 shenyue : > Hi everyone, > > Previously I post this question on wine-user forum, seems nobody > answered/interested, so I post it here. Hope somebody give me > a hand :) > > I have some questions about wine video capture andrendering. > > I'm a newbie to wine, and am working on QQ or any other messengers in wine. > My environment is : ubuntu 10.04, installed wine 1.1.42 (later when I modify > code, wine-1.1.42's source instead), QQ2009. And during my debugging, I also > check some source code from latest wine 1.2-rc4. > > Although QQ's level is "garbage", but fortunately it works almost fine under > wine, including login, text chat, . But the video call can only > partially work.I can see my friend's(he's under windows of course) video, > while I can't see my preview video, and he cannot see mine video too. > And no audio at all. (Audio is another issue, I haven't deal with it now.) > > As a comparison, I run GraphEdt to check what's wrong with video capture and > rendering, my filter graph=video capture + video render. when I 'use clock', > the same thing happens, no video rendering at all, but when I DONOT > 'use clock', video rendering works fine. > > Then I read the source code and find out one problem(maybe right, maybe > wrong), when wine/dlls/qcap/v4l.c send media samples to downstream filters, > it do not set any timestamp on it. Thus if I use VideoRenderer as I did in > GraphEdt, the video render got wrong start and stop reference time for > media sample, and then the synchronisation result will be very strange. > So I modify the v4l.c and set proper timestamp on media sample. Good result, > even when I 'use clock', the capture+render graph works find in GraphEdt. > > But when I turn to QQ, my video capture+preview+encoding graph still seems > don't work. I only made it work for msn messenger a long time ago, in 6.2 or so. I'm surprised it still works. Only change since then has been adding support for libv4l. (v4l2 with v4l1 api) > Then I checked msdn for these things, according to msdn: > "Video frames from a preview pin (as opposed to a capture pin) are not time > stamped. Because of graph latency, a video frame that is stamped with the > capture time will always arrive late at the video renderer. This may cause > the renderer to drop frames, in an attempt at quality control." > "Quality control is a mechanism for adjusting the rate of data flow through > the filter graph in response to run-time performance. If a renderer filter > is receiving too much data or too little data, it can send a quality > message. The quality message requests an adjustment in the data rate. > By default, quality messages travel upstream from the renderer until > they reach a filter that can respond (if any)." > > I've cheked winedbg log, QQ's filter graph looks like: > vfw capture filter + QQ's own video render filter + ... + ddraw/d3d7 > rendering. > QQ did not use smarttee, preview pin, standard VideoRender or > VideoRenderDefault or VideoMixingRender9 (because QQ never query > their id). Instead, I guess QQ write a video render filter by itself, and in > QQ's render filter, it directly use ddraw/d3d7 surface to render, and maybe > it does something similar to smarttee, to output to preview and encoding > at the same time. Could it be a ddraw/d3d7 failure rather than a wine failure? > Since QQ did not use preview pin directly, at first I guess maybe 'not time > stamped' is not correct, so I add some timestamp to capture's output > video frame, still no preview occurs, but result in continuous > IQualityControl interface query, but even latest wine-1.2-rc4 has not > implemented IQualityControl, so I guess, still something wrong in > timestamp synchronisation, and QQ's video render want to use > IQualityControl to fix it which wine doesn't support, so maybe > every frame is dropped, this result in my black preview video window. > I read from wine docs/wiki, once before windows messenger (8.1?) worked fine > in wine, I guess since you have written qcap/vfwcapture, of course somebody > has used wine for camera+preview+maybe encoding before, why it succeeded > by then, but fail now? > Is there anything wrong for me? Because originally I only wrote it to work with msn messenger 6.2 ;). > Btw1: there's a bug in wine-1.1.42's dlls/quartz/memallocator.c, > MediaSample's GetTime() return value is wrong, I've fixed that bug > according to latest wine, but still no video preview, and my friend cannot > see my video. > > Btw2: since qcap only works for v4l1, I ran flashcam to convert v4l2 to > v4l1. But I still wondering, since Maarteen original code supports v4l2, why > it > result in only support v4l1 (but not both v4l1 and v4l2)? Sort of, I didn't adjust the code for v4l2, however with libv4l it should work in linux.. ~Maarten
Re: damnit, X is crashing *every* time I run 3dmark2000
Hi Scott, 2010/6/22 Scott Ritchie : > On 06/21/2010 08:48 PM, Dan Kegel wrote: >> And always after test 17 of 20, I think. I updated to the latest >> nvidia driver supported by Ubuntu 10.04, no change. >> >> The crash persists even with WINEDEBUG=+d3d,+d3d7,+synchronous. >> >> I guess my next move is to drop 3dmark2000. >> >> > > This is exactly what I had hoped to happen when I experimented with > putting Wine's test suite in checkbox (Ubuntu's main QA tool). I'll see > if I can add yagmark to it too and then send it upstream so the tests > get run semi-regularly on maverick. > > Maybe then we won't end up with a crashing driver in the release. Depends, all d3d tests still seem a bit flaky on open source drivers, sometimes even crashing Xorg entirely. :) Cheers, Maarten
Re: [PATCH] atl: Do not fail on Wine64
Hi Marcus, 2010/6/13 Marcus Meissner : > Hi, > > The size is 248 on Wine64 ... (expected 240), so we miss > perhaps a pointer or some alignment. > > Its not fully clear what. > > It at least does not crash when ignoring the size change. Seems wrong to me, does it allow size 240 on 64-bits, or does it allow 248 only? ~Maarten
Re: configure.ac: when checking for ALSA, look for snd_pcm_recover() instead of snd_pcm_hw_params_get_access()
Hello Andrew, On 11-06-10 10:18, Andrew Nguyen wrote: On Sun, Jun 6, 2010 at 4:03 PM, Maarten Lankhorst wrote: Is snd_pcm_recover the only function missing? If so change it to dlsym, and add a copy of snd_pcm_recover to wine if it cannot find the libalsa one.. Is it a problem to eschew the use of dlsym? It feels like modifying winealsa.drv to dynamically load libasound correctly would be much more burdensome than simply replicating the snd_pcm_recover implementation. I have a provisional patch that replaces a half-baked snd_pcm_recover-like internal helper with the actual snd_pcm_recover implementation from libasound. I would welcome any feedback on it. Nah, I dislike the overuse of dlsym in wine too. Can you name the function wine_snd_pcm_recover, and fix the SNDERR() macro's? Otherwise looks good to me. ~Maarten
Re: Three year sever outstanding bug requiring minor fix
Hello Fakename, 2010/6/9 velociraptor Genjix : > Hey, > Please look into this issue, > http://bugs.winehq.org/show_bug.cgi?id=15118 > It seems like a fairly trivial fix which renders this application useless. A > detailed description of the implementation needed is provided in that > ticket. > Thank you Wine is run by volunteers, you cannot tell others what to do since they work on wine voluntary. If you want the bug fixed, your best bet is to try to fix it yourself. We can likely help you if you can program in C, but just posting 'please fix this bug for me' is rude and selfish. Cheers, Maarten
Re: Track the number of audio bytes played as a 64 bit number
Hello Dmitry, 2010/6/7 Dmitry Baryshev : > Make wine-1.1.43 track the number of audio bytes played as a 64 bit number > rather than a 32 bit number to avoid overflows. It may happen happen on > constantly used audio content, possibly causing inbound voice to stop > working > in some voice applications. Please send patches in the format "module: Description", and your patch mangled the tabs in winealsa :) Likely other patches are affected too. Cheers, Maarten
