January 2003 - Wine-Devel - list.winehq.org

Re: DirectSound and i810 soundcards

by Glen Kaukola

Ok, here's output from dsound_test.exe, I heard all 6 sounds: C:\Documents and Settings\sauron\Desktop>dsound_test.exe dsound dsound.c:373:Testing Primary Sound Driver - dsound.c:387: DirectSound Caps: flags=0x00000b5b secondary min=8000 max=48000 dsound.c:398: Testing the primary buffer dsound.c:240: Caps: flags=0x00000009 size=32768 dsound.c:254: tag=0x0001 22050x8x2 avg.B/s=44100 align=2 dsound.c:270: status=0x0000 dsound.c:307: Playing 440Hz LA at 11025x16x2 dsound.c:413: Testing a secondary buffer at 11025x8x1 dsound.c:240: Caps: flags=0x000100e8 size=4410 dsound.c:254: tag=0x0001 11025x8x1 avg.B/s=11025 align=1 dsound.c:270: status=0x0000 dsound.c:307: Playing 440Hz LA at 11025x 8x1 dsound.c:322: volume=0 dsound.c:428: Testing a secondary buffer at 48000x16x2 dsound.c:240: Caps: flags=0x000100e8 size=76800 dsound.c:254: tag=0x0001 48000x16x2 avg.B/s=192000 align=4 dsound.c:270: status=0x0000 dsound.c:307: Playing 440Hz LA at 48000x16x2 dsound.c:322: volume=0 dsound.c:373:Testing AC'97 Sound Card - ichaud.sys dsound.c:387: DirectSound Caps: flags=0x00000b5b secondary min=8000 max=48000 dsound.c:398: Testing the primary buffer dsound.c:240: Caps: flags=0x00000009 size=32768 dsound.c:254: tag=0x0001 22050x8x2 avg.B/s=44100 align=2 dsound.c:270: status=0x0000 dsound.c:307: Playing 440Hz LA at 11025x16x2 dsound.c:413: Testing a secondary buffer at 11025x8x1 dsound.c:240: Caps: flags=0x000100e8 size=4410 dsound.c:254: tag=0x0001 11025x8x1 avg.B/s=11025 align=1 dsound.c:270: status=0x0000 dsound.c:307: Playing 440Hz LA at 11025x 8x1 dsound.c:322: volume=0 dsound.c:428: Testing a secondary buffer at 48000x16x2 dsound.c:240: Caps: flags=0x000100e8 size=76800 dsound.c:254: tag=0x0001 48000x16x2 avg.B/s=192000 align=4 dsound.c:270: status=0x0000 dsound.c:307: Playing 440Hz LA at 48000x16x2 dsound.c:322: volume=0 dsound: 307 tests executed, 0 marked as todo, 0 failures. Here's the output from winmm_text.exe, I heard all 24 sounds: C:\Documents and Settings\sauron\Desktop>winmm_test.exe wave wave.c:182:found 1 WaveOut devices wave.c:206: 0: "AC'97 Sound Card" 5.0 (1:100): channels=65535 formats=0fff support=002c wave.c:150:Playing 440Hz LA at 11025x 8x1 0000 wave.c:150:Playing 440Hz LA at 11025x 8x1 0008 wave.c:150:Playing 440Hz LA at 11025x 8x2 0000 wave.c:150:Playing 440Hz LA at 11025x 8x2 0008 wave.c:150:Playing 440Hz LA at 11025x16x1 0000 wave.c:150:Playing 440Hz LA at 11025x16x1 0008 wave.c:150:Playing 440Hz LA at 11025x16x2 0000 wave.c:150:Playing 440Hz LA at 11025x16x2 0008 wave.c:150:Playing 440Hz LA at 22050x 8x1 0000 wave.c:150:Playing 440Hz LA at 22050x 8x1 0008 wave.c:150:Playing 440Hz LA at 22050x 8x2 0000 wave.c:150:Playing 440Hz LA at 22050x 8x2 0008 wave.c:150:Playing 440Hz LA at 22050x16x1 0000 wave.c:150:Playing 440Hz LA at 22050x16x1 0008 wave.c:150:Playing 440Hz LA at 22050x16x2 0000 wave.c:150:Playing 440Hz LA at 22050x16x2 0008 wave.c:150:Playing 440Hz LA at 44100x 8x1 0000 wave.c:150:Playing 440Hz LA at 44100x 8x1 0008 wave.c:150:Playing 440Hz LA at 44100x 8x2 0000 wave.c:150:Playing 440Hz LA at 44100x 8x2 0008 wave.c:150:Playing 440Hz LA at 44100x16x1 0000 wave.c:150:Playing 440Hz LA at 44100x16x1 0008 wave.c:150:Playing 440Hz LA at 44100x16x2 0000 wave.c:150:Playing 440Hz LA at 44100x16x2 0008 wave.c:220:Testing invalid 2MHz format wave: 221 tests executed, 0 marked as todo, 0 failures. The sounds all seem to be the same exact note and just at different volumes on the first test. Heh, or I'm completely tone deaf. Francois Gouget wrote: > On Mon, 6 Jan 2003, Glen Kaukola wrote: > > >>Francois Gouget wrote: >> >>>I'm not really sure this is what Windows is doing however. I would be >>>interested if people with Windows NT/2000/XP and an i810 soundcard could >>>run both the dsound and the winmm tests and send me the output. >> >>Hi, I hope I've got the type of sound card you're after. I'm pretty >>sure the i810 module gets loaded when I run Linux. >> >>Anyway, here's the output I get on win2k from dsound_test.exe: > > > Thanks. I forgot to mention to do the following before running the > tests: > set WINETEST_INTERACTIVE=1 > > This will cause them to play test tones and do more tests. I would be > interested to know if you hear all the tones and if you could send me > the corresponding output of each test. >

Jan. 7, 2003

Re: Window menu

by Tony Lambregts

Duane Clark wrote: > I've been using this patch for about a year and a half now, so I might > as well just submit it. > > Changelog: > A window with a WS_EX_APPWINDOW extended style can also > get a menu. > It's about time then.<g> I have been using it since you sent it to me. Works great! -- Tony Lambregts

Jan. 7, 2003

Re: DirectSound and i810 soundcards

by Ove Kaaven

On Mon, 6 Jan 2003, Francois Gouget wrote: > I'm not really sure this is what Windows is doing however. I would be > interested if people with Windows NT/2000/XP and an i810 soundcard could > run both the dsound and the winmm tests and send me the output. Note that test results from Windows XP won't be very useful for this; under XP, dsound primary buffers doesn't map directly to the sound hardware any more, according to MSDN. If you create and use a dsound primary buffer under XP, it will just become another stream sent to XP's kernel-mode sound mixer, before it gets to the hardware. > I believe that Windows lets you call SetFormat on the primary buffer but > I'm not sure if that actually has an effect or not. It should if you have appropriate cooperative level (except under XP). > I don't know why the mmap fails. I would tend to think this is a > limitation or bug of the Alsa driver since it works with the OSS driver. ALSA has resampling features. If you open the sound device at e.g. 11kHz, then ALSA's OSS emulation will, instead of telling you that the chip is 48kHz, install a resampling filter to convert from 11kHz to the hardware's required 48kHz. Unfortunately, that filter gets in the way of direct access, making an mmap fail. (In WineX we test mmap on a range of common frequencies to work around this.) > However it seems that we should be able to cope with this situation. But > I have some questions: > > * in wodOpen we create a wodPlayer thread... except if we are being > called by DirectSound. Won't we need this thread if we cannot mmap the > device? dsound used to completely fail (and return errors to the app) in this case, so it wasn't a problem. The thread should be created if mmap isn't available, yes, but that would have to be verified beforehand (that's what the cap flag checking is for), since both wodOpen and dsound needs to know whether mmap is available (to avoid the problems below). > * when we do a SetFormat, DSOUND_PrimaryClose calls waveOutReset (only > hwbuf, e.g. if mmap failed) which in turn calls OSS_AddRingMessage. > However since we don't have the wodPlayer thread noone ever processes > that message and we remain stuck there. What I'm currently experimenting > with is not sending this message but I wonder if we should not make sure > we have a wodPlayer thread instead (but then, when should we create it?). > > * the next problem is that DSOUND_PrimaryClose calls > waveOutUnprepareHeader with a bunch of WAVEHDR pointers. Adding a test > to avoid this condition is simple but again I wonder if this is quite > normal. Am I right in thinking that this code path (hwbuf==NULL) is > rarely if ever used? <g>

Jan. 7, 2003

Re: DirectSound and i810 soundcards

by Francois Gouget

Ove Kaaven wrote: [...] > Basically the 'true' sample rate should be propagated back to > dsound, so that it knows that the primary buffer is 48kHz and can resample > secondary buffers accordingly. No changes is needed to dsound for this, > wineoss's wodOpen just need to modify its waveformat input parameter if > the WAVE_DIRECTSOUND flag is present, then dsound will happily convert > secondary buffers to that sample rate when mixing them into the primary > buffer. Thanks. After realizing the SetFormat on the primary buffer was causing my half-baked fix to break, that worked fine. So I sent a patch to wine-patches. I'm not really sure this is what Windows is doing however. I would be interested if people with Windows NT/2000/XP and an i810 soundcard could run both the dsound and the winmm tests and send me the output. I believe that Windows lets you call SetFormat on the primary buffer but I'm not sure if that actually has an effect or not. Another thing i wonder about is whether Windows lets you play 11kHz sounds with WAVE_FORMAT_DIRECT using winmm and an i810 soundcard. If not then my winmm test is incorrect, and if yes then I have to wonder what WAVE_FORMAT_DIRECT really means. So if someone can send me these results... Anyway, it works :-) So now I'm trying to get the DirectSound test to work with i810 soundcards+Alsa. The problem is that with this combination we fail to mmap the sound device: err:wave:DSDB_MapPrimary (0x4038dcfc): Could not map sound device for direct access (Input/output error) This can be simulated by adding the following to DSDB_MapPrimary in dlls/winmm/wineoss/audio.c: if (getenv("I810A")) wwo->mapping=(LPBYTE)-1; else wwo->mapping = mmap(NULL, wwo->maplen, PROT_WRITE, MAP_SHARED, wwo->ossdev->fd, 0); Then invoke the test with (quite handy to debug): I810A="1" WINETEST_INTERACTIVE=1 ../../../tools/runtest -P wine -M dsound.dll -T ../../.. -p dsound_test.exe.so dsound.c I don't know why the mmap fails. I would tend to think this is a limitation or bug of the Alsa driver since it works with the OSS driver. However it seems that we should be able to cope with this situation. But I have some questions: * in wodOpen we create a wodPlayer thread... except if we are being called by DirectSound. Won't we need this thread if we cannot mmap the device? * when we do a SetFormat, DSOUND_PrimaryClose calls waveOutReset (only hwbuf, e.g. if mmap failed) which in turn calls OSS_AddRingMessage. However since we don't have the wodPlayer thread noone ever processes that message and we remain stuck there. What I'm currently experimenting with is not sending this message but I wonder if we should not make sure we have a wodPlayer thread instead (but then, when should we create it?). * the next problem is that DSOUND_PrimaryClose calls waveOutUnprepareHeader with a bunch of WAVEHDR pointers. Adding a test to avoid this condition is simple but again I wonder if this is quite normal. Am I right in thinking that this code path (hwbuf==NULL) is rarely if ever used? <g> -- Francois Gouget fgouget(a)codeweavers.com

Jan. 7, 2003

Re: RDP client under Wine?

by Matt Chapman

On Mon, Jan 06, 2003 at 11:52:56AM -0600, Rick Romero wrote: > On Mon, 2003-01-06 at 10:32, Hetz Ben Hamo wrote: > > > > I'm using 1.2 beta 1 version. the -D option is to hide decoration. I tried to > > connect to Windows XP Pro and all I get is 8 bit colors, while my X is set to > > 24 bits (XFree 4.2.1, NVidia binary drivers). I didn't find any info on man > > page how to get more then 8 bit colors... More than 8 bit is not supported in any version. Lots of people whinge about this, but no-one has actually implemented the necessary changes to the X11 frontend. > I tried 1.2 beta 1, and it seems noticeably slower than the patchlevel > I'm currently running. Can you try latest CVS - there is an important optimisation post-1.2beta1 merged from the patches. > The 'Experimental' patches are actually for 1.1.0, while the site > incorrectly says they're for 1.0. They are actually on top of 1.0.0 except someone diffed them against 1.1.0... Please don't use the 'experimental patches' if you can help it, they are nsupported, have incompatible options, etc. The main authors are now contributing to the mainline instead. > (plus the 1.2 beta version doesn't have a 'percent of desktop' option, I > like that one :) I'm not a big fan of 'percent of desktop', since it results in weird geometries which have caused problems in the past. What if rdesktop was to default to the biggest natural size smaller than the current desktop? e.g. 800x600->640x480, 1024x768->800x600, 1280x1024->1024x768. Matt

Jan. 7, 2003

Re: console handling

by Eric Pouech

>>ok, winedbg is too slow to respond, so gdb retries with the same packet, >>and when winedbg is ready, it's out of sync with gdb... >>does the attached hack^H^H^H^Hpatch solve the issue ? > > > Perfect -- thank you! Look: great... I clean it up and submit it -- Eric Pouech

Jan. 6, 2003

Re: Web CVS annotation

by Eric Pouech

Jeff Smith wrote: > I know nothing of cvs administration, but would it be possible > (without too much effort) to add annotation to the web cvs > interface? I find that knowing the last time a particular > piece of code changed can make regression testing and assorted > other tasks happen a lot faster. > from the docs, it seems we need to have the user running the httpd server have rw to the CVSROOT/history directory... that shouldn't be too hard to do... just a matter of time... I've added a bug request for this (#1214) A+ -- Eric Pouech

Jan. 6, 2003

Re: Wine debugging tutorial?

by Eric Pouech

Mike Hearn wrote: > The tutorial up on winehq.org on how to use WineDbg, while pretty > useful, seems a tad out of date (lots of references to 16 bit constructs > etc). Does anybody know of any good tutorials on how to use low level > code debuggers such as this? well part of winedbg command syntax comes from gdb, so a high level gdb tutorial might (partly) do > Coming from a delphi background, I'm more used to the integrated > debugging style, and I'm finding more and more that the wine traces > don't always provide useful information, so I'd like to master this > tool. Oh, also, how do you use the ncurses backend (I think eric > mentioned one recently). I quite like having large scrollback buffers > too. to run winedbg under the curses backend run wineconsole winedbg <winedbg opts> A+ -- Eric Pouech

Jan. 6, 2003

Re: console handling

by Eric Pouech

Dimitrie O. Paun wrote: [info snipped] thanks for the traces ;-) ok, winedbg is too slow to respond, so gdb retries with the same packet, and when winedbg is ready, it's out of sync with gdb... does the attached hack^H^H^H^Hpatch solve the issue ? A+ -- Eric Pouech Name: wd_gdb ChangeLog: fixed protocol packet handling when winedbg is too slow to answer License: X11 GenDate: 2003/01/06 20:39:33 UTC ModifiedFiles: programs/winedbg/gdbproxy.c AddedFiles: =================================================================== RCS file: /home/cvs/cvsroot/wine/wine/programs/winedbg/gdbproxy.c,v retrieving revision 1.3 diff -u -u -r1.3 gdbproxy.c --- programs/winedbg/gdbproxy.c 16 Dec 2002 22:10:34 -0000 1.3 +++ programs/winedbg/gdbproxy.c 6 Jan 2003 20:35:03 -0000 @@ -20,6 +20,10 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +/* Protocol specification can be found here: + * http://sources.redhat.com/gdb/onlinedocs/gdb_32.html + */ + #include "config.h" #include <assert.h> @@ -1788,6 +1792,7 @@ unsigned char in_cksum, loc_cksum; char* ptr; enum packet_return ret = packet_error; + int num = 0; while ((ret & packet_last_f) == 0) { @@ -1814,6 +1819,7 @@ loc_cksum = checksum(gdbctx->in_buf + 1, plen); if (loc_cksum == in_cksum) { + if (num == 0) { int i; ret = packet_error; @@ -1857,6 +1863,11 @@ /* if this fails, we'll have to use POLLOUT... */ gdbctx->out_len = 0; + num++; + } else { + if (gdbctx->trace & GDBPXY_TRC_LOWLEVEL) + fprintf(stderr, "dropping packet, I was too slow to respond\n"); + } } else {

Jan. 6, 2003

Re: winegcc: behave like g++ when invoked as wineg++

by Dimitrie O. Paun

On January 5, 2003 11:47 pm, Dimitrie O. Paun wrote: > ChangeLog > Create a wineg++ akin to g++. Drop support for the abused -xc++ switched. Please don't use this patch, it's broken: I don't delete the link before creating it, so only the first install works. I'll send a bigger update soon. -- Dimi.

Jan. 6, 2003