March 2004 - Wine-Devel - list.winehq.org

Re: i810 audio fixes 1/2

by Paul Davis

>The intermediate buffering is the issue. It's not a real big issue >now with only a single buffer but it will be when wine supports >hardware accelerated secondary buffers. You don't want 32 or >64 streams of data each going through multiple intermediate >buffers for SRC, format, and volume changes. The point of >direct sound is to provide the application programmer enough >information about and control over the hardware to ensure >optimal performance if desired. Hiding the hardware with layers >of plugins is not the optimal approach. Even Microsoft learned >that lesson the hard way. Alsa's approach of providing a >consistent interface requardless of the amount of code or time >or CPU resources used is great if that's what you want but they >also need to provide a fast path to the hardware when that's >desired. I know they are considering this but it is not a priority. the extent to which you are right depends on the intended target. for pro-audio/music software, you're wrong. the APIs used by these programs do not and will not use the kinds of h/w features you mention. ASIO, in particular, does not model this kind of h/w, and there are very good reasons for that, "learned the hard way". Neither does GSIF or CoreAudio, the other two main "serious" audio APIs used by proaudio/music applications. we (i write this kind of stuff) don't use h/w features like this because the h/w is crap and there is never enough control over the algorithms. the reverbs found on audio interfaces aren't generally even close to usable for music production. and you can't use stuff like gain control because of the way the apps are structured (they are already implementing mixers with at least as much functionality as a high end mixing console). for games and some consumer software, yes, its probably true that using h/w facilities like this is desirable. there has been quite a bit of discussion about a new HAL for this stuff in ALSA over the last couple of months. some people are looking at specific cards for ideas about how to approach this. the model is still that the application code will be (more or less) identical, except perhaps for a few calls to toggle the choice of using h/w features if they exist. --p

March 30, 2004

Re: i810 audio fixes 1/2

by Robert Reif

The intermediate buffering is the issue. It's not a real big issue now with only a single buffer but it will be when wine supports hardware accelerated secondary buffers. You don't want 32 or 64 streams of data each going through multiple intermediate buffers for SRC, format, and volume changes. The point of direct sound is to provide the application programmer enough information about and control over the hardware to ensure optimal performance if desired. Hiding the hardware with layers of plugins is not the optimal approach. Even Microsoft learned that lesson the hard way. Alsa's approach of providing a consistent interface requardless of the amount of code or time or CPU resources used is great if that's what you want but they also need to provide a fast path to the hardware when that's desired. I know they are considering this but it is not a priority. Paul Davis wrote: > >I believe it makes sense for wine to keep the oss and alsa > >drivers as low level as possible for users that require performance > >over useability. The straight to hardware philosophy of direct sound > >should be honored when possible. This would be appropriate for > >games, voip or low latency music applications. > > ALSA is designed to avoid this sort of dichotomy. It does not matter > to the app whether it opens "hw:0" or "plughw:0" or "plug:dmix:0" - > the same code is used in every case. The fact that each of these > virtual devices has quite different operating characteristics should > be of interest to the user, but not to the code. > > There are places where this doesn't work. alsa-devel wants to hear > about them, and plans to fix them. > > >If usability rather than performance (as in multiple applications) is > >important, then higher level drivers like jack or arts should be used. > > JACK is not aimed at usability, but performance. It enforces timing > constraints rather than leaving it to a bunch of hapless apps to mess > it up. You cannot hope to use JACK within Wine without intermediate > buffering, which actually makes using JACK somewhat pointless. I say > somewhat only because it still permits device sharing, but at the cost > of losing sample accurate synchronization. > > --p

March 30, 2004

RE: Handling dialogs created without using templates

by Santosh Siddheshwar

Hi, Yes attached is a sample which is pretty similar to what I described below. Regards Santosh Siddheshwar <<GetParent.zip>> > -----Original Message----- > From: Dmitry Timoshkov [SMTP:dmitry(a)baikal.ru] > Sent: Tuesday, March 30, 2004 12:51 PM > To: Santosh Siddheshwar > Cc: wine-devel(a)winehq.com > Subject: Re: Handling dialogs created without using templates > > "Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > > > I have an application that creates dialogs without using any of the > Win32 > > Dialog creation APIs. I find that a lot of the > > functionality in DEFDLG_Proc (DM_SETDEFID, DM_GETDEFID & WM_NEXTDLGCTL) > is > > unavailable for use with > > dialogs created this way. This is because we allocate the DIALOGINFO > > structure only in the dialog creation APIs. Dialogs > > created without using these APIs have NULL DIALOGINFO structure. I also > find > > that allocating this structure and initializing > > the members of the structure will get around this problem. Does anyone > > visualize any problems with this approach? > > Also where would the best place to put such code? > > Do you have a small, self-contained sample code which demonstrates > what you have described? > > -- > Dmitry. ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

March 30, 2004

Re: Handling dialogs created without using templates

by Dmitry Timoshkov

"Santosh Siddheshwar" <santosh.s(a)sonata-software.com> wrote: > I have an application that creates dialogs without using any of the Win32 > Dialog creation APIs. I find that a lot of the > functionality in DEFDLG_Proc (DM_SETDEFID, DM_GETDEFID & WM_NEXTDLGCTL) is > unavailable for use with > dialogs created this way. This is because we allocate the DIALOGINFO > structure only in the dialog creation APIs. Dialogs > created without using these APIs have NULL DIALOGINFO structure. I also find > that allocating this structure and initializing > the members of the structure will get around this problem. Does anyone > visualize any problems with this approach? > Also where would the best place to put such code? Do you have a small, self-contained sample code which demonstrates what you have described? -- Dmitry.

March 30, 2004

Handling dialogs created without using templates

by Santosh Siddheshwar

Hi, I have an application that creates dialogs without using any of the Win32 Dialog creation APIs. I find that a lot of the functionality in DEFDLG_Proc (DM_SETDEFID, DM_GETDEFID & WM_NEXTDLGCTL) is unavailable for use with dialogs created this way. This is because we allocate the DIALOGINFO structure only in the dialog creation APIs. Dialogs created without using these APIs have NULL DIALOGINFO structure. I also find that allocating this structure and initializing the members of the structure will get around this problem. Does anyone visualize any problems with this approach? Also where would the best place to put such code? Regards Santosh Siddheshwar ********************************************************************* Disclaimer: The information in this e-mail and any attachments is confidential / privileged. It is intended solely for the addressee or addressees. If you are not the addressee indicated in this message, you may not copy or deliver this message to anyone. In such case, you should destroy this message and kindly notify the sender by reply email. Please advise immediately if you or your employer does not consent to Internet email for messages of this kind. *********************************************************************

March 30, 2004

Re: [LostWages] make winehq.org HTML 4.01 Transitional + XHTML 1.0 Transitional Valid

by hatky

On Tuesday 30 March 2004 00:15, Maxime Bellengé wrote: > Hello, I think you forgot the patch > > On Tue, 2004-03-30 at 00:08, hatky wrote: > > Change log: > > Ofir Petruska <hatky(a)users.sf.net> > > Validate the site as HTML 4.01 Transitional + XHTML 1.0 Transitional > > Valid (still declaring declaring HTML 4.01 Transitional) > > * Case fixes (all html tags should be lower case) > > * Quote all attributes > > * End empty tags as " />" I resend it in about the same minute but it's near 200k so it's waiting moderation... -- Hatky, Worshiper of wine (http://www.winehq.org/) Impossible is only an opinion.

March 30, 2004

Re: systray in desktop mode [unified resend]

by Martin Fuchs

Hello Mike, > However, we do want native shell32 to work, so it'll be using the same > protocol. sure. > > Well, let's see how far Mike's upcoming rewritten systray can handle this. > > I may have a look in the new code, and see if I it's possible to do it > > without knowing about the desktop mode. > > Getting explorer/systray to work in Wine may not be easy, however > ReactOS and Wine should be able to share the same shell32 which I think > is the idea, yes? If you want to do exactly what native shell32 does, you can just drop all the old (non-desktop mode) code and replace it with what my patch wanted to do in desktop mode. This is also how the ReactOS implementation already looks like. This is the simple case, because there's no Linux desktop, in which the icons should be integrated. SHELL_NotifyIcon() just passes the messages to any existing "Shell_TrayWnd" window. Your new implementation will also create such a message receiver window. So you want to create your tray window at any startup of Wine regardless if it will be used or not? May be a bit overkill, but it would work. In the result it will look like this: If there is no explorer application, the icons will show up in the Linux systray. If there is an Explorer running, they will show up _both_ in Linux' and Explorer's systray. Regards, Martin

March 30, 2004

Re: i810 audio fixes 1/2

by Paul Davis

>I believe it makes sense for wine to keep the oss and alsa >drivers as low level as possible for users that require performance >over useability. The straight to hardware philosophy of direct sound >should be honored when possible. This would be appropriate for >games, voip or low latency music applications. ALSA is designed to avoid this sort of dichotomy. It does not matter to the app whether it opens "hw:0" or "plughw:0" or "plug:dmix:0" - the same code is used in every case. The fact that each of these virtual devices has quite different operating characteristics should be of interest to the user, but not to the code. There are places where this doesn't work. alsa-devel wants to hear about them, and plans to fix them. >If usability rather than performance (as in multiple applications) is >important, then higher level drivers like jack or arts should be used. JACK is not aimed at usability, but performance. It enforces timing constraints rather than leaving it to a bunch of hapless apps to mess it up. You cannot hope to use JACK within Wine without intermediate buffering, which actually makes using JACK somewhat pointless. I say somewhat only because it still permits device sharing, but at the cost of losing sample accurate synchronization. --p

March 30, 2004

Re: kernel32 test failures under Cygwin

by Steven Edwards

Hello Dmitry, --- Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Could anybody else with a relatively fresh Cygwin or MinGW > installation > try it and report the result? I have a semi-new cygwin install on one of the 2k servers I run so I will make some time soon to play with it again. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! Finance Tax Center - File online. File on time. http://taxes.yahoo.com/filing.html

March 30, 2004

Re: [LostWages] make winehq.org HTML 4.01 Transitional + XHTML 1.0 Transitional Valid

by Vincent Béron

Le lun 29/03/2004 à 17:08, hatky a écrit : > Change log: > Ofir Petruska <hatky(a)users.sf.net> > Validate the site as HTML 4.01 Transitional + XHTML 1.0 Transitional Valid > (still declaring declaring HTML 4.01 Transitional) > * Case fixes (all html tags should be lower case) > * Quote all attributes > * End empty tags as " />" Would be better with the patch... Vincent

March 30, 2004