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

Debugging WINE 1.3.24 with GDB

by louis＠museresearch.com

Hi All, I've been attempting to debug a WINElib application on Fedora 15 (WINE 1.3.24) and not having much success. Winedbg works, but using gdb I'm not able to see symbols or multiple threads. In Fedora 8, running GDB on wine-pthreads (and not wine!) used to work under 1.1.7. However, under 1.3.24 there's no wine-pthreads. I've also tried attaching to various threads after the program was running with little success. I'm also not having any success using "winedbg --gdb"-- the same thing happens there as if I'd run it using just gdb (strange). The big picture is that I'd like to get an IDE such as QtCreator or KDevelop to work debugging a WINE application. Any way that is possible would be a good solution for me; it doesn't necessarily have to be through GDB if there's another way. Thanks for your help in advance! -Louis

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Maarten Lankhorst

Op 29-02-12 17:29, Joerg-Cyril.Hoehle(a)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

Feb. 29, 2012

Re: po: Spanish translation update for cmd.rc (almost complete)

by Eduardo García

Sorry, attached the wrong patch, this one is the correct one. With regards. Eduardo. El 02/29/12 21:00, Eduardo García escribió: > This one was fun to do as I fouund a couple of "my hovercraft is full > of eels" phrases. > > With regards. > > Eduardo. > > > > >

Feb. 29, 2012

Re: po: Spanish translation update for cmd.rc (almost complete)

by Eduardo García

Sorry, attached the wrong patch, this one is the correct. With regards. Eduardo. El 02/29/12 21:00, Eduardo García escribió: > This one was fun to do as I fouund a couple of "my hovercraft is full > of eels" phrases. > > > > > > >

Feb. 29, 2012

Spelling errors in en_US translation

by Julian Rüger

Hi Francois, (and everybody else ;) are there any plans to create an ignore-list for these: http://fgouget.free.fr/wine-po/en_US.spell.html to be able to distinguish real typos from false positives? Most reported errors are false positives (like "codec" or "checksum") but there are real errors, or at least instances of uncommon spelling (like "customising", which is British English afaik, or "Cancelled") which should be fixed (after 1.4), imho. Best regards, Julian

Feb. 29, 2012

Re: Fix references to the LGPL

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > So the problem is that start.rc (it's always about start) > contains slightly incorrect references to the LGPL in its license > message (no less): I would say we should get rid of that license message. No other Wine command-line app does this, and we have the license in the about box already for graphical apps. This would also avoid the need for a different usage message in cmd. -- Alexandre Julliard julliard(a)winehq.org

Feb. 29, 2012

Re: AW: Major mmdevapi and winmm audio bugs

by Maarten Lankhorst

Hey Joerg, Having actually finished the pulseaudio implementation and trying to fix some fallout. Op 29-02-12 16:28, Joerg-Cyril.Hoehle(a)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. Or never use anything but dmix/real hardware with winealsa and just use winepulse for pulseaudio. You know the period size in that case and can force a wake up. pulseaudio's alsa wrapper might have issues because it will wait until at least one frame is filled before marking it as such, in the worst case hiding the pulseaudio native length from alsa applications. > So far we've followed the "decouple" route in winealsa/oss. I believe the key to > the solution in mmdevapi will come from both being able to vary the sleeping > intervals to adapt to clock skew *and* not be bound to be exactly in sync with > the back-end, thanks to a latency-inducing buffer large enough to compensate > for the variability. > IOW, the design goal is to reach during normal playback a state where: > Event received => GetCurrentPadding has (or pretends to have) decreased by > at least 1 period (which implies there's room for writing). I think the key is to use accurate periods and report GetStreamLatency correctly. Use it in wine where needed for winmm and dsound. ~Maarten

Feb. 29, 2012

Re: [PATCH] winepulse: Add pulse driver, v8

by Joerg-Cyril.Hoehle＠t-systems.com

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. >+ 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). 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. + 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) >- 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 Regards, Jörg

Feb. 29, 2012

Re: gdiplus: Create a GDI brush only when needed.

by Vincent Povirk

Looks better. Maybe create_gdi_logbrush should fall back to creating a solid brush, so that pens with weird brushes set will do something vaguely sensible. Eventually, we will want to use a different implementation of pens that does not involve gdi32 in those cases. On Wed, Feb 29, 2012 at 2:29 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Vincent Povirk <madewokherd(a)gmail.com> wrote: > >> The right solution is to remove the gdibrush and logbrush fields from >> GpBrush, and generate the HBRUSH as needed in brush_fill_path. Note >> that brush_fill_path will only be called for solid and hatch brushes >> (those for which brush_can_fill_path returns true), so we don't need >> the code to create a gdi brush for the other types. > > Does the attached patch look better? Next step would be to get rid of bmp > in GpSolidFill structure. > > -- > Dmitry.

Feb. 29, 2012

AW: Major mmdevapi and winmm audio bugs

by Joerg-Cyril.Hoehle＠t-systems.com

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. >... 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. >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. Regarding a), nothing prevents you from using the back-end's favourite notification mechanism to wake up - or use a timer. 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. - 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. - How to continue signaling type a events after IAudioClient_Stop? By continuing to write silence to the back-end?!? - 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. - 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. So far we've followed the "decouple" route in winealsa/oss. I believe the key to the solution in mmdevapi will come from both being able to vary the sleeping intervals to adapt to clock skew *and* not be bound to be exactly in sync with the back-end, thanks to a latency-inducing buffer large enough to compensate for the variability. IOW, the design goal is to reach during normal playback a state where: Event received => GetCurrentPadding has (or pretends to have) decreased by at least 1 period (which implies there's room for writing). Regards, Jörg

Feb. 29, 2012