winecfg: Remove driver selection from Audio tab.
Hi, I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system. For instance, I've not yet had time to report a bug that since wine-1.3.25, one such entry shows an empty name IIRC. It allowed users to easily check whether e.g. Timidity was recognized or whether "MIDI through" was the only output. It allowed users to easily tell whether their 5:1 sound card was recognized beside the default device. Bugzilla shows 350 entries about winecfg & audio. It had a use. What are users supposed to do now? Regards, Jörg Höhle
On Mon, Sep 26, 2011 at 04:50:22PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system.
The goal of that patch, like the subject says, was to remove driver selection. Obviously a side-effect of removing that entire tree was removing the list of detected devices. I personally don't really see the use of listing the detected devices, which is why I just removed the tree wholesale. If folks find the device list useful, I wouldn't be at all opposed to adding it again in some form (obviously it would use MMDevAPI directly instead of WinMM like the old code... except for MIDI devices, I guess). I am opposed to adding the driver selection functionality back in, though. Andrew
On 09/26/2011 09:10 AM, Andrew Eikum wrote:
On Mon, Sep 26, 2011 at 04:50:22PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system.
The goal of that patch, like the subject says, was to remove driver selection. Obviously a side-effect of removing that entire tree was removing the list of detected devices. I personally don't really see the use of listing the detected devices, which is why I just removed the tree wholesale.
If folks find the device list useful, I wouldn't be at all opposed to adding it again in some form (obviously it would use MMDevAPI directly instead of WinMM like the old code... except for MIDI devices, I guess). I am opposed to adding the driver selection functionality back in, though.
Andrew
Could we please wait another week (until after the wineconf) before doing these whole sale changes? Please leave sound system and related winecfg code as-is. Vitaliy.
On 09/27/2011 03:20 AM, Vitaliy Margolen wrote:
On 09/26/2011 09:10 AM, Andrew Eikum wrote:
On Mon, Sep 26, 2011 at 04:50:22PM +0200, Joerg-Cyril.Hoehle(a)t-systems.com wrote:
I'm not satisfied with the removal of the audio tree from winecfg. Beside allowing to switch or disable drivers, one key feature was to allow inspecting the devices that winmm found on this system.
The goal of that patch, like the subject says, was to remove driver selection. Obviously a side-effect of removing that entire tree was removing the list of detected devices. I personally don't really see the use of listing the detected devices, which is why I just removed the tree wholesale.
If folks find the device list useful, I wouldn't be at all opposed to adding it again in some form (obviously it would use MMDevAPI directly instead of WinMM like the old code... except for MIDI devices, I guess). I am opposed to adding the driver selection functionality back in, though.
Andrew
Could we please wait another week (until after the wineconf) before doing these whole sale changes?
Please leave sound system and related winecfg code as-is. Why?
Come to think of it this would be the right time to do it: - We are at the start of the commit period for 1.3.30 - People will be busy traveling to/from WineConf so a regression won't halt their work. - Andrew won't travel so he can fix regressions. - We can directly motivate Andrew to fix those regressions "Oh, regressions still open? No dinner for you tonight!". bye michael
On 09/27/2011 12:17 PM, Michael Stefaniuc wrote:
On 09/27/2011 03:20 AM, Vitaliy Margolen wrote:
Could we please wait another week (until after the wineconf) before doing these whole sale changes?
Please leave sound system and related winecfg code as-is. Why?
Come to think of it this would be the right time to do it: - We are at the start of the commit period for 1.3.30 - People will be busy traveling to/from WineConf so a regression won't halt their work. - Andrew won't travel so he can fix regressions. - We can directly motivate Andrew to fix those regressions "Oh, regressions still open? No dinner for you tonight!".
Exactly because of all the regressions introduced with such a huge change. I'm not a big fan of ripping things out and replacing them with new and shiny just because no one understands how it all needs to be done in the first place. It would be much better to see the entire conversion to mmdevapi in a separate tree stabilized before making it's way to main tree. Wine is driven by wrong objectives. Most developers here don't give much rip about regressions if the code they've put in is "right". This is exactly the wrong way to do it. Don't take it from me, take it from the person who knows it much better and knows what he is talking about: http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-So... "[T]he thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it." You think that all people who'll find their program broken because of this sound rewrite care about the code? Or that now dsound talks to mmdevapi instead of winmm? Or remarks by Andrew that "he doesn't want to fix old code because it's going away anyway. And he'd rather fix new code." a good excuse for their game to stop working on Wine? I'd like you guys to think about what really is important users or code? - Vitaliy
On 28 September 2011 01:33, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
You think that all people who'll find their program broken because of this sound rewrite care about the code? Or that now dsound talks to mmdevapi instead of winmm? Or remarks by Andrew that "he doesn't want to fix old code because it's going away anyway. And he'd rather fix new code." a good excuse for their game to stop working on Wine?
I'd like you guys to think about what really is important users or code?
Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them. Alex
Alex Bradbury wrote:
>Do correct me if I'm wrong here, but users who don't want regressions
>in their favourite apps/games should be using the stable release.
There's some chicken and egg problem.
1. Users find bugs in the stable release.
2. Should they ever report a bug, they'll be asked whether the "unstable"
version is still affected, hence:
=> "nice" users (these who report bugs) end up using the "unstable" version,
which they may not have wanted to run originally.
3. Furthermore, these users are expected to re-check the "unstable"
version from time to time.
Perhaps the Wine Wiki should explain extremely well how people can keep
2 versions of Wine side by side, esp. when using distros.
- one to play games;
- another to play with bug reports.
Then one should explain very well why these people should invest
time to maintain 2 versions of Wine.
Probably the Wine bugzilla should explain why users are expected to do all this.
I guess it's based on the number of users: with so many users, you can't expect
the few devs to fill holes in bug reports. The users need do more work than when
filing a bug on a project with few users where the devs may spend a lot of time
on each individual bug report. If this were explained, perhaps more people would
be willing to help (instead of writing a short note to the forum).
Well, maybe the Debian way is excellent: ideally, Debian "stable" would contain
a particular release of Wine which has proven very good overall (not necessary 1.2.x).
For instance, on the Mac with nVidia, 1.1.24(!) is still an excellent choice.
Regards,
Jörg Höhle
On 09/28/2011 04:18 AM, Alex Bradbury wrote:
Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them.
If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16. Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old "stable" versions. -Vitaliy
On 09/28/2011 05:57 AM, Vitaliy Margolen wrote:
On 09/28/2011 04:18 AM, Alex Bradbury wrote:
Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them.
If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16.
Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old "stable" versions.
There's a reason I've consistently been advocating for more frequent, or even regular, stable releases. We don't need fancy big features to justify a release, mere apps working is enough. -Scott
On Wed, Sep 28, 2011 at 11:55, Scott Ritchie <scott(a)open-vote.org> wrote:
On 09/28/2011 05:57 AM, Vitaliy Margolen wrote:
On 09/28/2011 04:18 AM, Alex Bradbury wrote:
Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them.
If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16.
Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old "stable" versions.
There's a reason I've consistently been advocating for more frequent, or even regular, stable releases. We don't need fancy big features to justify a release, mere apps working is enough.
There's no reason you (as a package manager) couldn't choose a particular development release and mark it as stable in your distribution. E.g., Fedora does this, currently has wine 1.3.21, unless you enable updates-testing, which has 1.3.29. In any case, I think this topic is best reserved for discussion at Wineconf, especially since it's not that far away ;). -- -Austin
On 09/28/2011 10:10 AM, Austin English wrote:
On Wed, Sep 28, 2011 at 11:55, Scott Ritchie <scott(a)open-vote.org> wrote:
On 09/28/2011 05:57 AM, Vitaliy Margolen wrote:
On 09/28/2011 04:18 AM, Alex Bradbury wrote:
Do correct me if I'm wrong here, but users who don't want regressions in their favourite apps/games should be using the stable release. It doesn't seem fair to complain about regressions being ignored unless 1.4 releases with a significant number of them.
If Wine would release stable versions every 3-4 months sure. But last stable version released on April 8. And only contains small number of fixes since wine-1.2 which was released on July 16.
Many programs don't work with wine-1.2.3 for number of reasons. Besides, everywhere (forum, bugzilla, irc) we tell users to upgrade to latest development version, because we not going to fix any bugs in old "stable" versions.
There's a reason I've consistently been advocating for more frequent, or even regular, stable releases. We don't need fancy big features to justify a release, mere apps working is enough.
There's no reason you (as a package manager) couldn't choose a particular development release and mark it as stable in your distribution. E.g., Fedora does this, currently has wine 1.3.21, unless you enable updates-testing, which has 1.3.29.
In any case, I think this topic is best reserved for discussion at Wineconf, especially since it's not that far away ;).
Yes, I already ship a Wine1.3 package in the install, and it should be the "default" most people find when searching for Wine. But that means users aren't getting the advantage of a real release process here. If that's too involved an effort to do frequently enough for distros to not feel obligated to ship development releases by default, then perhaps we need to discuss a different strategy. In either case, I think we can all agree that more automated continuous testing of git would be a nice thing to have. So I got my daily PPA, Dan's got buildbot, and many of us have been expanding Wine's test suite. I hope to also tie in automated winetricks and winetricks-style application tests to the daily PPA soon as well. Thanks, Scott Ritchie
Vitaliy Margolen wrote:
On 09/27/2011 12:17 PM, Michael Stefaniuc wrote:
On 09/27/2011 03:20 AM, Vitaliy Margolen wrote:
Could we please wait another week (until after the wineconf) before doing these whole sale changes?
Please leave sound system and related winecfg code as-is. Why?
Come to think of it this would be the right time to do it: - We are at the start of the commit period for 1.3.30 - People will be busy traveling to/from WineConf so a regression won't halt their work. - Andrew won't travel so he can fix regressions. - We can directly motivate Andrew to fix those regressions "Oh, regressions still open? No dinner for you tonight!".
Exactly because of all the regressions introduced with such a huge change.
I'm not a big fan of ripping things out and replacing them with new and shiny just because no one understands how it all needs to be done in the New? mmdevapi was introduced with Vista a couple of years ago. Shiny? For an 1:1 (feature wise) backend replacement? A backend that has no UI component to it? Seriously?
first place. It would be much better to see the entire conversion to mmdevapi in a separate tree stabilized before making it's way to main tree. Like in a development tree? The Wine 1.3.x tree is a development tree. Also how many people would you think would use that extra mmdevapi tree? One? Two? So you'll get the same untested code merged at a later time.
Wine is driven by wrong objectives. Most developers here don't give much rip about regressions if the code they've put in is "right". This is Yes, sadly there are Wine developers that consider regressions they have introduced "just normal bugs" which they will fix eventually if they are interested. But there are a lot of other developers that fix the regressions they have introduced with a hight priority. I venture to say that most Wine developers prioritize regression bugs above normal bugs.
And no, Andrew's code is *NOT* "right" by any means! If we preferred the "right" code we would have taken Maarten's code which nuked dsound out of orbit. Andrew's code is a minimally invasive (for a big amount of minimal) that replaces the winmm calls with mmdevapi. His patches didn't even conflict with my COM cleanup and the COM implementation in dsound is not only "wrong code" but also "bad and ugly".
exactly the wrong way to do it. Don't take it from me, take it from the person who knows it much better and knows what he is talking about: http://h30565.www3.hp.com/t5/Feature-Articles/Linus-Torvalds-s-Lessons-on-So...
"[T]he thing that really matters is the users of the code. The code itself is unimportant; the project is only as useful as people actually find it." Exactly! And how did we care about our sound users all this years? By ignoring all their bugs? There are 67 open dsound bugs, the oldest is from 2004.
Again this is an 1:1 backend replacement with feature parity on the "frontend". This is none of the stuff that Linus was targetting: "We replace a 90% working solution with a 60% working solution, but you don't need those 30% we took away", "We know it better", "You are not our targeted audience". The programs that use dsound need to work afterwards, period. Regressions are unavoidable but we do our very best to fix those.
You think that all people who'll find their program broken because of this sound rewrite care about the code? Or that now dsound talks to mmdevapi instead of winmm? Or remarks by Andrew that "he doesn't want to Those people will stay on the old Wine version that worked for them until we fix the regressions. On the other hand the people for which dsound never worked will most likely appreciate that we are finally working to fix their problem.
fix old code because it's going away anyway. And he'd rather fix new code." a good excuse for their game to stop working on Wine? Uh? Logic error... if he doesn't fixes the old code he cannot break it. The new code on the other hand is new so he will fix the regressions in that.
I'd like you guys to think about what really is important users or code? Users. But you seem to prefer the old code...
bye michael
On 09/28/2011 05:31 AM, Michael Stefaniuc wrote:
Vitaliy Margolen wrote:
On 09/27/2011 12:17 PM, Michael Stefaniuc wrote:
first place. It would be much better to see the entire conversion to mmdevapi in a separate tree stabilized before making it's way to main tree. Like in a development tree? The Wine 1.3.x tree is a development tree. Also how many people would you think would use that extra mmdevapi tree? One? Two? So you'll get the same untested code merged at a later time. I'd expect most developers to test it it. Or at least those who interested in the specific area. Some users, especially those who reported errors about sound would be pointed to that tree as well. So it will get testing.
Wine is driven by wrong objectives. Most developers here don't give much rip about regressions if the code they've put in is "right". This is Yes, sadly there are Wine developers that consider regressions they have introduced "just normal bugs" which they will fix eventually if they are My suggestion would be to revert those "fixes" unless said developers willing to fix what they broke. Linus was pretty clear that he won't accept patches from such developers. Complete 180 from Alexandre's view.
interested. But there are a lot of other developers that fix the regressions they have introduced with a hight priority. I venture to say that most Wine developers prioritize regression bugs above normal bugs. Unfortunately no one goes back and fixes those other regressions. Many users quit using Wine because of them. Not because of all other great stuff was added to Wine.
And no, Andrew's code is *NOT* "right" by any means! If we preferred the "right" code we would have taken Maarten's code which nuked dsound out More so reasons to have a separate tree to stabilize it before merging with main line.
Again this is an 1:1 backend replacement with feature parity on the I think not! Andrew's biggest desire was to drop hardware acceleration support. The only part that actually did work and produced best sound.
I'd like you guys to think about what really is important users or code? Users. But you seem to prefer the old code... I prefer working code, regardless of it's age.
What I really like to see is stable Wine versions being released more often if you think that the development tree is the right place to test nuclear options... - Vitaliy
Am 28.09.2011 15:09, schrieb Vitaliy Margolen:
On 09/28/2011 05:31 AM, Michael Stefaniuc wrote:
Vitaliy Margolen wrote:
On 09/27/2011 12:17 PM, Michael Stefaniuc wrote: Wine is driven by wrong objectives. Most developers here don't give much rip about regressions if the code they've put in is "right". This is Yes, sadly there are Wine developers that consider regressions they have introduced "just normal bugs" which they will fix eventually if they are My suggestion would be to revert those "fixes" unless said developers willing to fix what they broke. Linus was pretty clear that he won't accept patches from such developers. Complete 180 from Alexandre's view.
Still Linus isn't our projectleader, but AJ. And AJ was pretty clear he won't do reverts everytime somethings wrong, but will look for a fix. And AJ does his job for Wine nearly as long as Linus does for Linux and look where Wine is today, so i don't see the point for quoting Linus in that discussion. -- Best Regards, André Hentschel
On 09/28/2011 11:04 AM, André Hentschel wrote:
Am 28.09.2011 15:09, schrieb Vitaliy Margolen:
On 09/28/2011 05:31 AM, Michael Stefaniuc wrote:
Vitaliy Margolen wrote:
On 09/27/2011 12:17 PM, Michael Stefaniuc wrote: Wine is driven by wrong objectives. Most developers here don't give much rip about regressions if the code they've put in is "right". This is Yes, sadly there are Wine developers that consider regressions they have introduced "just normal bugs" which they will fix eventually if they are My suggestion would be to revert those "fixes" unless said developers willing to fix what they broke. Linus was pretty clear that he won't accept patches from such developers. Complete 180 from Alexandre's view.
Still Linus isn't our projectleader, but AJ. And AJ was pretty clear he won't do reverts everytime somethings wrong, but will look for a fix. And AJ does his job for Wine nearly as long as Linus does for Linux and look where Wine is today, so i don't see the point for quoting Linus in that discussion.
The part you forgot is Linux (referring to kernel here) being the most successful FOSS project, used on super computers, stock exchanges, banks, etc. While Wine still in it's perpetual alpha-beta state, limited user base, and not recommended for production use. Not saying that AJ's ways are all that bad, but obviously not giving the same results. Don't you think it's time to change things up a bit? - Vitaliy
Vitaliy Margolen <wine-devel(a)kievinfo.com> writes:
The part you forgot is Linux (referring to kernel here) being the most successful FOSS project, used on super computers, stock exchanges, banks, etc. While Wine still in it's perpetual alpha-beta state, limited user base, and not recommended for production use.
Not saying that AJ's ways are all that bad, but obviously not giving the same results. Don't you think it's time to change things up a bit?
So what do you suggest? -- Alexandre Julliard julliard(a)winehq.org
On 09/29/2011 02:11 AM, Alexandre Julliard wrote:
Vitaliy Margolen<wine-devel(a)kievinfo.com> writes:
The part you forgot is Linux (referring to kernel here) being the most successful FOSS project, used on super computers, stock exchanges, banks, etc. While Wine still in it's perpetual alpha-beta state, limited user base, and not recommended for production use.
Not saying that AJ's ways are all that bad, but obviously not giving the same results. Don't you think it's time to change things up a bit?
So what do you suggest?
I can think of few things can be implemented right away and see how it goes: 1. Longer release cycle. Lets start with 3-4 weeks and extend if needed. Allow any new features first week of the release cycle only. Next two weeks are bug fixes and stabilization before release. Or have same 2 week release cycle with every other release being release candidate and code freeze for the second 2 weeks to stabilize it. 2. All major changes (substantial code rewrites, new dlls (excluding stubs), core dll / server changes) should be submitted as a whole series. Alternatively available as an external tree. To not completely stop development of major features it should be ok for small trickle of changes like DIB which one by one replacing existing functionality. While still requiring same level of testing. Such changes should have complete design proposal sent to wine-devel for discussions, preferably prior to codding. Don't need diagrams but at a minimum explanation what is the plan, how it supposed to work, what's wrong with current code that can't be fixed. To not put all weight lifting on one person, person(s) most familiar with the area _have_ to review and approve before continuing. Even tho we don't have official maintainers, this might be the time to assign this responsibility. Example of major changes: dsound rewrites, substantial d3d changes, wineserver/ntdll/kernel/user. 3. All regressions should be treated as blockers. And fixed before next release. If a regression is in some other area then patch introducing regression, no patches should be accepted from anyone else to the area in question until this regression is fixed. Or a work around found. Of course this is just a suggested plan not set in stone. Just wanted to bring this up before Wineconf so people can think about it. Can continue the conversation there as well. -Vitaliy
On 29 September 2011 15:03, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote:
I can think of few things can be implemented right away and see how it goes:
A lot of these seem like a great way to slow wine development down. Honestly I think better investment in automated application testing would be more helpful to the project (I'm just an outside observer of course). I know cxtest didn't really work out, but Scott Ritchie has talked of some very straight-forward scripted testing of apps available in winetricks which seems sensible. Additionally, you could imagine checking a large library of game demos that 1) they don't crash 2) some sort of sound output is produced. It's a weak test, but it could be easily automated.
1. Longer release cycle. Lets start with 3-4 weeks and extend if needed. Allow any new features first week of the release cycle only. Next two weeks are bug fixes and stabilization before release.
Or have same 2 week release cycle with every other release being release candidate and code freeze for the second 2 weeks to stabilize it.
This is actually not a bad idea. I think that currently changes which are likely to break things mostly end up in the first week of the two week cycle, but then not many users test (with some notable exceptions, like GyB the one-person regression-hunting machine). 1.3.odd releases having larger changes with more likelihood of breakage than 1.3.even releases (hopefully fixing any reported issues) does sound worth considering.
3. All regressions should be treated as blockers. And fixed before next release. If a regression is in some other area then patch introducing regression, no patches should be accepted from anyone else to the area in question until this regression is fixed. Or a work around found.
People complaining about the difficulty of getting a patch in to wine already seems to be an issue. This all sounds a little arbitrary to me. I do subscribe to wine-bugs and it seems to me that most bisected regressions get addressed promptly. Alex
Michael Stefaniuc wrote:
- We can directly motivate Andrew to fix those regressions "Oh, regressions still open? No dinner for you tonight!".
I still think Andrew deserves kudos for the vast amount of work he did. mmdevapi, winmm, DSound, ALSA, OSS and CoreAudio are a lot for one person to tackle! Which yields the question of how an open source project can do major changes. It didn't happen within the last 10 years, it happened now with financial backing from a commercial company, that's why his commits say "Andrew Eikum for CodeWeavers". Wine may have a very large user base, but there are very few "key" developers. There are more people at my family's meetings then at WineConf. The sound systems (wine's DSound, but also ALSA etc.) being a can of worms certainly raised the complexity. Any major change one does may reveal something previously hidden by double errors. This is not a pleasant situation and is clearly lowering patch creation rate. Reflecting what happened, the one major flaw in the process I've identified is lack of significant test upfront. The mmdevapi tests are ok for testing a COM component, but not an audio renderer. Had my mmdevapi tests been available earlier, it would have been clear that the current OSS and CoreAudio drivers are not ready for release. See bugs #28056, #28093, #28039, #28047, #27937. Regards, Jörg Höhle
participants (9)
-
Alex Bradbury -
Alexandre Julliard -
Andrew Eikum -
André Hentschel -
Austin English -
Joerg-Cyril.Hoehle＠t-systems.com -
Michael Stefaniuc -
Scott Ritchie -
Vitaliy Margolen