Re: po: Spanish translation update for cmd.rc (almost complete)
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. --- es.po.orig 2012-02-29 14:03:04.221539001 +0100 +++ es.po 2012-02-29 20:56:25.511539002 +0100 @@ -9437,11 +9437,10 @@ "Not Yet Implemented\n" "\n" msgstr "" -"No implementado\n" +"Aún no implementado\n" "\n" #: attrib.rc:28 cmd.rc:318 -#, fuzzy msgid "%1: File Not Found\n" msgstr "%1: Archivo no encontrado\n" @@ -9514,55 +9513,53 @@ "Changes to default directory, environment variables etc made within a\n" "called procedure are inherited by the caller.\n" msgstr "" -"CALL se utiliza dentro de un archivo por\n" -"lotes para ejecutar comandos desde otro archivo por lotes. Cuando el\n" -"archivo por lotes existe, el control regresa al archivo que lo llamó. El\n" -"comando CALL puede proporcionar parámetros para el procedimiento llamado.\n" -"\n" -"Los cambios sobre el directorio por defecto, variables de entorno, etc.\n" -"realizados desde dentro de un procedimiento llamado son heredados por el\n" -"llamante.\n" +"CALL se utiliza dentro de un archivo de\n" +"lotes para ejecutar comandos existentes dentro de otro archivo de lotes.\n" +"Cuando el archivo de lotes existe, el control regresa al archivo desde el\n" +"que fue llamado. Con el comando CALL se pueden pasar parámetros al\n" +"procedimiento llamado.\n" +"\n" +"Cualquier cambio sobre el directorio por defecto, las variables de entorno u\n" +"otro cámbio realizado desde una llamada a procedimiento son heredados por el\n" +"procedimiento que realizo la llamada.\n" #: cmd.rc:40 -#, fuzzy msgid "" "CD is the short version of CHDIR. It changes the current\n" "default directory.\n" -msgstr "Ayuda sobre CD\n" +msgstr "" +"CD es la versión corta del comando CHDIR. Este\n" +"comando cambia el directorio actual.\n" #: cmd.rc:41 -#, fuzzy msgid "CHDIR changes the current default directory.\n" -msgstr "Ayuda sobre CHDIR\n" +msgstr "CHDIR cambia el directorio actual.\n" #: cmd.rc:43 msgid "CLS clears the console screen.\n" -msgstr "CLS limpia la pantalla de la consola.\n" +msgstr "CLS limpia la consola actual.\n" #: cmd.rc:45 -#, fuzzy msgid "COPY copies a file.\n" -msgstr "Ayuda sobre COPY\n" +msgstr "COPY copia un archivo.\n" #: cmd.rc:46 -#, fuzzy msgid "CTTY changes the input/output device.\n" -msgstr "Ayuda sobre CTTY\n" +msgstr"" +"CTTY cambia el dispositivo de entrada/salida\n" +"por defecto.\n" #: cmd.rc:47 -#, fuzzy msgid "DATE shows or changes the system date.\n" -msgstr "Ayuda sobre DATE\n" +msgstr "DATE muestra o cambia la fecha del sistema.\n" #: cmd.rc:48 -#, fuzzy msgid "DEL deletes a file or set of files.\n" -msgstr "Ayuda sobre DEL\n" +msgstr "DEL borra un archivo o grupo de archivos.\n" #: cmd.rc:49 -#, fuzzy msgid "DIR lists the contents of a directory.\n" -msgstr "Ayuda sobre DIR\n" +msgstr "DIR muestra el contenido de un directorio.\n" #: cmd.rc:59 msgid "" @@ -9575,19 +9572,18 @@ "default). The ECHO OFF command can be prevented from displaying by\n" "preceding it with an @ sign.\n" msgstr "" -"ECHO muestra en el dispositivo de terminal actual.\n" +"ECHO muestra la suministrada en el terminal actual.\n" "\n" -"ECHO ON provoca que todos los comandos subsiguientes en un archivo por\n" -"lotes sean mostrados en el terminal antes de ser ejecutados.\n" +"ECHO ON muestra en pantalla los comandos de un archivo de lotes\n" +"previamente a su ejecución.\n" "\n" -"ECHO OFF invierte el efecto de un previo ECHO ON (ECHO es OFF por\n" -"defecto). El comando ECHO OFF puede prevenirse de ser mostrado\n" -"precediéndolo por un signo @.\n" +"ECHO OFF invierte el efecto de un ECHO ON previamente activado (ECHO\n" +"por defecto es OFF). Es posible ocultar el comando ECHO OFF añadiendo\n" +"un signo @ delante de él.\n" #: cmd.rc:61 -#, fuzzy msgid "ERASE deletes a file or set of files.\n" -msgstr "Ayuda sobre ERASE\n" +msgstr "ERASE borra un archivo o grupo de archivos.\n" #: cmd.rc:69 msgid "" @@ -9598,13 +9594,13 @@ "The requirement to double the % sign when using FOR in a batch file does\n" "not exist in wine's cmd.\n" msgstr "" -"El comando FOR se utiliza para ejecutar un comando para cada uno de\n" -"un conjunto de archivos.\n" +"El comando FOR se utiliza para ejecutar un comando en una lista de\n" +"archivos.\n" "\n" -"Sintaxis: FOR %variable IN (conjunto) DO comando\n" +"Sintaxis: FOR %variable IN (lista) DO comando\n" "\n" -"La necesidad de doblar el signo % cuando se utiliza FOR en un archivo\n" -"por lotes no existe en cmd.\n" +"La necesidad de repetir el signo % cuando se utiliza FOR en un\n" +"archivo de lotes no existe en el cmd de Wine.\n" #: cmd.rc:81 msgid "" @@ -9619,27 +9615,27 @@ "\n" "GOTO has no effect when used interactively.\n" msgstr "" -"El comando GOTO transfiere la ejecución a otro ma
Re: po: Spanish translation update for cmd.rc (almost complete)
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. --- es.po.orig 2012-02-29 14:03:04.221539001 +0100 +++ es.po 2012-02-29 20:56:25.511539002 +0100 @@ -9437,11 +9437,10 @@ "Not Yet Implemented\n" "\n" msgstr "" -"No implementado\n" +"Aún no implementado\n" "\n" #: attrib.rc:28 cmd.rc:318 -#, fuzzy msgid "%1: File Not Found\n" msgstr "%1: Archivo no encontrado\n" @@ -9514,55 +9513,53 @@ "Changes to default directory, environment variables etc made within a\n" "called procedure are inherited by the caller.\n" msgstr "" -"CALL se utiliza dentro de un archivo por\n" -"lotes para ejecutar comandos desde otro archivo por lotes. Cuando el\n" -"archivo por lotes existe, el control regresa al archivo que lo llamó. El\n" -"comando CALL puede proporcionar parámetros para el procedimiento llamado.\n" -"\n" -"Los cambios sobre el directorio por defecto, variables de entorno, etc.\n" -"realizados desde dentro de un procedimiento llamado son heredados por el\n" -"llamante.\n" +"CALL se utiliza dentro de un archivo de\n" +"lotes para ejecutar comandos existentes dentro de otro archivo de lotes.\n" +"Cuando el archivo de lotes existe, el control regresa al archivo desde el\n" +"que fue llamado. Con el comando CALL se pueden pasar parámetros al\n" +"procedimiento llamado.\n" +"\n" +"Cualquier cambio sobre el directorio por defecto, las variables de entorno u\n" +"otro cámbio realizado desde una llamada a procedimiento son heredados por el\n" +"procedimiento que realizo la llamada.\n" #: cmd.rc:40 -#, fuzzy msgid "" "CD is the short version of CHDIR. It changes the current\n" "default directory.\n" -msgstr "Ayuda sobre CD\n" +msgstr "" +"CD es la versión corta del comando CHDIR. Este\n" +"comando cambia el directorio actual.\n" #: cmd.rc:41 -#, fuzzy msgid "CHDIR changes the current default directory.\n" -msgstr "Ayuda sobre CHDIR\n" +msgstr "CHDIR cambia el directorio actual.\n" #: cmd.rc:43 msgid "CLS clears the console screen.\n" -msgstr "CLS limpia la pantalla de la consola.\n" +msgstr "CLS limpia la consola actual.\n" #: cmd.rc:45 -#, fuzzy msgid "COPY copies a file.\n" -msgstr "Ayuda sobre COPY\n" +msgstr "COPY copia un archivo.\n" #: cmd.rc:46 -#, fuzzy msgid "CTTY changes the input/output device.\n" -msgstr "Ayuda sobre CTTY\n" +msgstr"" +"CTTY cambia el dispositivo de entrada/salida\n" +"por defecto.\n" #: cmd.rc:47 -#, fuzzy msgid "DATE shows or changes the system date.\n" -msgstr "Ayuda sobre DATE\n" +msgstr "DATE muestra o cambia la fecha del sistema.\n" #: cmd.rc:48 -#, fuzzy msgid "DEL deletes a file or set of files.\n" -msgstr "Ayuda sobre DEL\n" +msgstr "DEL borra un archivo o grupo de archivos.\n" #: cmd.rc:49 -#, fuzzy msgid "DIR lists the contents of a directory.\n" -msgstr "Ayuda sobre DIR\n" +msgstr "DIR muestra el contenido de un directorio.\n" #: cmd.rc:59 msgid "" @@ -9575,19 +9572,18 @@ "default). The ECHO OFF command can be prevented from displaying by\n" "preceding it with an @ sign.\n" msgstr "" -"ECHO muestra en el dispositivo de terminal actual.\n" +"ECHO muestra la suministrada en el terminal actual.\n" "\n" -"ECHO ON provoca que todos los comandos subsiguientes en un archivo por\n" -"lotes sean mostrados en el terminal antes de ser ejecutados.\n" +"ECHO ON muestra en pantalla los comandos de un archivo de lotes\n" +"previamente a su ejecución.\n" "\n" -"ECHO OFF invierte el efecto de un previo ECHO ON (ECHO es OFF por\n" -"defecto). El comando ECHO OFF puede prevenirse de ser mostrado\n" -"precediéndolo por un signo @.\n" +"ECHO OFF invierte el efecto de un ECHO ON previamente activado (ECHO\n" +"por defecto es OFF). Es posible ocultar el comando ECHO OFF añadiendo\n" +"un signo @ delante de él.\n" #: cmd.rc:61 -#, fuzzy msgid "ERASE deletes a file or set of files.\n" -msgstr "Ayuda sobre ERASE\n" +msgstr "ERASE borra un archivo o grupo de archivos.\n" #: cmd.rc:69 msgid "" @@ -9598,13 +9594,13 @@ "The requirement to double the % sign when using FOR in a batch file does\n" "not exist in wine's cmd.\n" msgstr "" -"El comando FOR se utiliza para ejecutar un comando para cada uno de\n" -"un conjunto de archivos.\n" +"El comando FOR se utiliza para ejecutar un comando en una lista de\n" +"archivos.\n" "\n" -"Sintaxis: FOR %variable IN (conjunto) DO comando\n" +"Sintaxis: FOR %variable IN (lista) DO comando\n" "\n" -"La necesidad de doblar el signo % cuando se utiliza FOR en un archivo\n" -"por lotes no existe en cmd.\n" +"La necesidad de repetir el signo % cuando se utiliza FOR en un\n" +"archivo de lotes no existe en el cmd de Wine.\n" #: cmd.rc:81 msgid "" @@ -9619,27 +9615,27 @@ "\n" "GOTO has no effect when used interactively.\n" msgstr "" -"El comando GOTO transfiere la ejecución a otro mandato dentro de un\n" -"arc
Re: gdiplus: Create GDI brush only when needed. Take 2.
I don't think this is a good idea during code freeze.
Re: bugzilla: show the component, not "comp" and not the assignee
On Mon, Feb 27, 2012 at 10:39, wrote: > Hi, > > Somehow I discovered that bugzilla can display the component in a search > result list. Now I'm using that instead of the useless "assignee" field. > Here's part of the URL I'm using: > > &columnlist=bug_severity%2Cop_sys%2Ccomponent%2Cbug_status%2Cshort_desc& > > Unfortunately, the column named "Comp" only holds 8 characters, causing ugly > names like: > directx- : you don't know which one out of ten directx-YZ > winmm&mc : one missing letter looks rather stupid > > It would be nice if some bugzilla admin would enlarge that column > > BTW, I recently suggested replacing the mostly useless "assignee" column in > the default search result list by the component. No answer. What do you think? I wouldn't be opposed to either one, but I don't see an option to do so after digging around in the admin panel for about 10 minutes. The closest I found was 'Query defaults' under 'Parameters'. This has two fields: mybugstemplate: buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&email1=%userid%&emailtype1=exact&emailassigned_to1=1&emailreporter1=1 defaultquery: bug_status=RESOLVED&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailqa_contact2=1&order=Importance&long_desc_type=substring similar, yes, but doesn't let me set the default columns. If you or someone else can point to where to set it, I'd be happy to. Cheers, Austin
Debugging WINE 1.3.24 with GDB
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
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
Spelling errors in en_US translation
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
Re: Fix references to the LGPL
Francois Gouget 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 julli...@winehq.org
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. 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
Re: [PATCH] winepulse: Add pulse driver, v8
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
Re: gdiplus: Create a GDI brush only when needed.
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 wrote: > Vincent Povirk 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.
AW: Major mmdevapi and winmm audio bugs
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
Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)
On 29 February 2012 13:32, Stefan Dösinger wrote: > Fine with me, just don't blame me that those bugs aren't fixed :-) Yeah well, 27600 was reported in June last year.
Re: [PATCH] wined3d: Do not use double-buffered dynamic buffers (try 2)
Am Mittwoch, 29. Februar 2012, 11:54:11 schrieb Henri Verbeet: > I guess I didn't explicitly say it yesterday, but I think this should > be deferred and fixed properly after 1.4. While in principle dropping > VBOs might be ok as a temporary fix for the release, the vertex / > index buffer code is pretty fragile in general, and I can't guarantee > that this won't introduce more regressions than it fixes. Fine with me, just don't blame me that those bugs aren't fixed :-) signature.asc Description: This is a digitally signed message part.
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] wined3d: Do not use double-buffered dynamic buffers (try 2)
On 29 February 2012 11:12, Stefan Dösinger wrote: > try 2: Invalidate the index buffer state as well, as the buffer might be > an index buffer. > > Otherwise unmodified reesend after the discussion from yesterday. This > is for bugs 29079, 29897(suspected) and 30019. > I guess I didn't explicitly say it yesterday, but I think this should be deferred and fixed properly after 1.4. While in principle dropping VBOs might be ok as a temporary fix for the release, the vertex / index buffer code is pretty fragile in general, and I can't guarantee that this won't introduce more regressions than it fixes.
Re: [PATCH] README: updated Linux and FreeBSD kernels
On Wed, Feb 22, 2012 at 10:44:31AM +0100, Francois Gouget wrote: > On Wed, 22 Feb 2012, Marcus Meissner wrote: > > > --- > > README | 13 ++--- > > 1 files changed, 6 insertions(+), 7 deletions(-) > > > > diff --git a/README b/README > > index baa6ab3..0cbb047 100644 > > --- a/README > > +++ b/README > > @@ -29,7 +29,7 @@ especially the wealth of information found at > > http://www.winehq.org. > > To compile and run Wine, you must have one of the following: > > > >Linux version 2.0.36 or above > > - FreeBSD 6.3 or later > > + FreeBSD 8.0 or later > [...] > > FreeBSD info: > > - Wine will generally not work properly on versions before FreeBSD > > - 6.3 or 7.0, and FreeBSD 6.3 has additional patches available. See > > - http://wiki.freebsd.org/Wine for more information. > > + Wine will generally not work properly on versions before FreeBSD 8.0. > > + See http://wiki.freebsd.org/Wine for more information. > > Is there a reason why Wine won't work right on FreeBSD 7.0? > Winetest seems mostly ok. > http://test.winehq.org/data/f43f37d3613db57c732196f88e1225191cd62c30/index_BSD.html I followed the note on http://wiki.freebsd.org/Wine who does not mention older versions than 8.0. I have no other information. Ciuao, Marcus
Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?
Yes. Looks good. J. Leclanche On Wed, Feb 29, 2012 at 9:51 AM, Francois Gouget wrote: > On Sat, 25 Feb 2012, Jerome Leclanche wrote: > [...] > > - I don't think an ano telia would be appropriate for this. To be honest > I > > don't even find a semicolon appropriate in English here. > > I don't build with printing support but it sounds to me like it would be > > more appropriate to use a comma, or a dash. > > Would the attached patch be better? > > > -- > Francois Gouget http://fgouget.free.fr/ > The greatest programming project of all took six days; on the seventh day > the > programmer rested. We've been trying to debug the *&^%$#@ thing ever > since. > Moral: design before you implement.
Remove an obsolete string chunk fom the Swedish translation?
This translation seems to have an extra example which is not present in the English string. Would it be ok to remove it? msgid "" "MOVE relocates a file or directory to a new point within the file system.\n" "\n" "If the item being moved is a directory then all the files and " "subdirectories\n" "below the item are moved as well.\n" "\n" "MOVE fails if the old and new locations are on different DOS drive letters.\n" msgstr "" "MOVE flyttar en fil eller mapp till ett nytt ställe inom filsystemet.\n" "\n" "Om du flyttar på en mapp, så flyttas allting under mappen med.\n" "\n" "MOVE misslyckas om den gamla och det den nya stället är på olika\n" "DOS-enhetsbokstäver. Till exempel från C: till D:.\n" ^ -- Francois Gouget http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.
Re: RFT: Use Greek semicolons for comdlg32's printer status enumeration?
On Sat, 25 Feb 2012, Jerome Leclanche wrote: [...] > - I don't think an ano telia would be appropriate for this. To be honest I > don't even find a semicolon appropriate in English here. > I don't build with printing support but it sounds to me like it would be > more appropriate to use a comma, or a dash. Would the attached patch be better? -- Francois Gouget http://fgouget.free.fr/ The greatest programming project of all took six days; on the seventh day the programmer rested. We've been trying to debug the *&^%$#@ thing ever since. Moral: design before you implement. el-printer.bin Description: el-printer.bin
Re: Major mmdevapi and winmm audio bugs
Andrew Eikum wrote: >And, not too surprisingly, TimerQueue isn't sufficient. I've attached >my tests here. The tests ask to execute the callback every 12 ms. On >my Windows 7 VM, I found that it executed with intervals like: >20, 10, 10, 10, 10, 20, 10, 10, 10, 10, ... >With an 11 occasionally interspersed. >So, forget that. No. Did you notice that on *average*, a callback occurs every 12ms (5 within 60ms)? This is the same essential property that winmm:setTimer exhibits too. Wine's CreateTimerQueue is buggy, because it doesn't do that. Wine's winmm:timer does. A patch is needed for CTQ. Now if Wine's CTQ would be fixed, Wine's audio would have fewer underruns. The periodicity is another topic. >my Windows 7 VM I don't trust timings from a VM. 10/20ms may be an artefact. OTOH it may be a design decision from MS related to scheduler quantums or whatever. >Since we're already using poll() in winmm and it seems to work well, >that would be my suggestion. Sure, but then you need an own thread in mmdevapi, don't you? So we're back at the point where I said earlier that I can well imagine a fix to CTQ for wine-1.4.0, but less so a move to an own thread + poll. Regards, Jörg Höhle
Re: doc: Update Italian README
2012/2/28 Frédéric Delanoy > 2012/2/28 Luca Bennati : > > I tried converting README.it to UTF8, instead of the current Extended > ASCII, > > which works really bad on my system. > > However, it does not seems like Git caught this change: could this be > done > > manually? > > I applied the patch manually and it seems the conversion went fine. > Maybe there were some accentuated letters already. > (hint: 'iconv' can be useful for those kind of conversions, or a save > with your favorite editor) > > BTW, > > -6. ESEGUIRE I PROGRAMMI > +6. RUNNING PROGRAMS > > seems wrong... > > Frédéric > It's good that it works as planned. Thanks for spotting that line, I've sent another patch to correct it.
