How many more RCs are you planning before wine-1.2?

James_Huk · Post by **James_Huk** » Fri Jul 09, 2010 2:24 pm

Hello again.

Question as in topic.

Thanks in advance.

John Drescher · Post by **John Drescher** » Fri Jul 09, 2010 2:31 pm

Question as in topic.

I believe it is not about how many rcs but it will not be released
until the regressions fall below an acceptable number.

John

Post by **dimesio** » Fri Jul 09, 2010 2:34 pm

James_Huk wrote:Hello again.

Question as in topic.

Thanks in advance.

The announcement for today's release (1.2-rc7) says that barring any last minute problems, this is probably the last one.

eps · Post by **eps** » Fri Jul 09, 2010 2:36 pm

On Sat, Jul 10, 2010 at 5:24 AM, James_Huk <[email protected]> wrote:

Question as in topic.

I believe Wine will not be releasing until I have time to finish the
next WWN. I'm sorry to disappoint but I've got text to write and
assignments to get done first. I'd give it another two months and
everything should be set for release along side the newsletter.

Hopefully you understand the importance of WWN and the reasons for
delaying the entire Wine project as a result.

James_Huk · Post by **James_Huk** » Fri Jul 09, 2010 3:44 pm

No problem - I am not pushing anyone ;]

I asked because I wanted to know how much time is left for testing existing bugs with current RCs (there are probably many bugs that are resolved already and just needs to be retested and closed)

However now I am a bit confused - @eps do you mean that there will be about 8 more RCs (assuming 4 RCs per month) or that @dimesio is right, and today's release will be the last one, and we will have to wait for two months before next (stable wine-1.2) release?

eps · Post by **eps** » Fri Jul 09, 2010 4:52 pm

On Sat, Jul 10, 2010 at 5:36 AM, Edward Savage <[email protected]> wrote:

I believe Wine will not be releasing until I have time to finish the
next WWN. I'm sorry to disappoint but I've got text to write and
assignments to get done first. I'd give it another two months and
everything should be set for release along side the newsletter.

Hopefully you understand the importance of WWN and the reasons for
delaying the entire Wine project as a result.

This was a jestful way of saying "it'll be done when it's done".
Thanks for your concern though people who mailed me.

James Mckenzie · Post by **James Mckenzie** » Fri Jul 09, 2010 4:53 pm

James:

This week. That's all, unless a serious bug is found, this is the LAST RC. AJ plans on releasing next week. We have to pick a time and that is the one he picked (read the Announcement.)

That means that you have to get really busy or convince him that there is a real good reason to hold the release (like some really popular game/productivity program does not function at all or an important function is not working.)

I have two patches that are waiting for release as well. These affect many programs. Thay should have been in 1.2, but did not make it.

I'll have to get 'busy' myself this weekend and get the programs I support tested and updated.

James McKenzie

-----Original Message-----

From: James_Huk <[email protected]>
Sent: Jul 9, 2010 1:44 PM
To: [email protected]
Subject: [Wine] Re: How many more RCs are you planning before wine-1.2?

No problem - I am not pushing anyone ;]

I asked because I wanted to know how much time is left for testing existing bugs with current RCs (there are probably many bugs that are resolved already and just needs to be retested and closed)

However now I am a bit confused - @eps do you mean that there will be about 8 more RCs (assuming 4 RCs per month) or that @dimesio is right, and today's release will be the last one, and we will have to wait for two months before next (stable wine-1.2) release?

tpreitzel · Post by **tpreitzel** » Fri Jul 09, 2010 4:59 pm

James Mckenzie wrote:James:

This week. That's all, unless a serious bug is found, this is the LAST RC. AJ plans on releasing next week. We have to pick a time and that is the one he picked (read the Announcement.)

That means that you have to get really busy or convince him that there is a real good reason to hold the release (like some really popular game/productivity program does not function at all or an important function is not working.)

I have two patches that are waiting for release as well. These affect many programs. Thay should have been in 1.2, but did not make it.

I'll have to get 'busy' myself this weekend and get the programs I support tested and updated.

James McKenzie

-----Original Message-----
From: James_Huk <[email protected]>
Sent: Jul 9, 2010 1:44 PM
To: [email protected]
Subject: [Wine] Re: How many more RCs are you planning before wine-1.2?

No problem - I am not pushing anyone ;]

I asked because I wanted to know how much time is left for testing existing bugs with current RCs (there are probably many bugs that are resolved already and just needs to be retested and closed)

However now I am a bit confused - @eps do you mean that there will be about 8 more RCs (assuming 4 RCs per month) or that @dimesio is right, and today's release will be the last one, and we will have to wait for two months before next (stable wine-1.2) release?

Frankly, there's plenty of good reasons for holding the release of WINE 1.2.

The FACT that many applications (games) are suddenly losing the audio after several minutes of play and then crashing to the desktop shortly thereafter is a pretty good reason for holding the release of WINE 1.2.

Post by **dimesio** » Fri Jul 09, 2010 5:24 pm

tpreitzel wrote: Frankly, there's plenty of good reasons for holding the release of WINE 1.2.

The FACT that many applications (games) are suddenly losing the audio after several minutes of play and then crashing to the desktop shortly thereafter is a pretty good reason for holding the release of WINE 1.2.

As I pointed out in the other thread, the only bug I could find that matches the behavior you describe is one that was closed as invalid because it is not a Wine bug, so that is not a reason to hold up the next stable release.

James McKenzie · Post by **James McKenzie** » Fri Jul 09, 2010 8:31 pm

tpreitzel wrote:

James Mckenzie wrote:

James:

This week. That's all, unless a serious bug is found, this is the LAST RC. AJ plans on releasing next week. We have to pick a time and that is the one he picked (read the Announcement.)

That means that you have to get really busy or convince him that there is a real good reason to hold the release (like some really popular game/productivity program does not function at all or an important function is not working.)

I have two patches that are waiting for release as well. These affect many programs. Thay should have been in 1.2, but did not make it.

I'll have to get 'busy' myself this weekend and get the programs I support tested and updated.

James McKenzie

-----Original Message-----

From: James_Huk <[email protected]>
Sent: Jul 9, 2010 1:44 PM
To: [email protected]
Subject: [Wine] Re: How many more RCs are you planning before wine-1.2?

No problem - I am not pushing anyone ;]

I asked because I wanted to know how much time is left for testing existing bugs with current RCs (there are probably many bugs that are resolved already and just needs to be retested and closed)

However now I am a bit confused - @eps do you mean that there will be about 8 more RCs (assuming 4 RCs per month) or that @dimesio is right, and today's release will be the last one, and we will have to wait for two months before next (stable wine-1.2) release?

Frankly, there's plenty of good reasons for holding the release of WINE 1.2.

The FACT that many applications (games) are suddenly losing the audio after several minutes of play and then crashing to the desktop shortly thereafter is a pretty good reason for holding the release of WINE 1.2.

Repeatable example?

Most of the problems are caused by pulseaudio crashing, not Wine, BTW.
The driver may not fail, but it is causing Wine to crash. That is not a
Wine problem but a poor implemenation of an unneeded driver.

James McKenzie

James McKenzie · Post by **James McKenzie** » Fri Jul 09, 2010 8:32 pm

Edward Savage wrote:

On Sat, Jul 10, 2010 at 5:36 AM, Edward Savage <[email protected]> wrote:

I believe Wine will not be releasing until I have time to finish the
next WWN. I'm sorry to disappoint but I've got text to write and
assignments to get done first. I'd give it another two months and
everything should be set for release along side the newsletter.

Hopefully you understand the importance of WWN and the reasons for
delaying the entire Wine project as a result.

This was a jestful way of saying "it'll be done when it's done".
Thanks for your concern though people who mailed me.

Ok. That's the same thing for Wine. It ain't ready, we ain't releasing....

James McKenzie

tpreitzel · Post by **tpreitzel** » Fri Jul 09, 2010 8:41 pm

James McKenzie wrote:tpreitzel wrote:
James Mckenzie wrote:

James:

This week. That's all, unless a serious bug is found, this is the LAST RC. AJ plans on releasing next week. We have to pick a time and that is the one he picked (read the Announcement.)

That means that you have to get really busy or convince him that there is a real good reason to hold the release (like some really popular game/productivity program does not function at all or an important function is not working.)

I have two patches that are waiting for release as well. These affect many programs. Thay should have been in 1.2, but did not make it.

I'll have to get 'busy' myself this weekend and get the programs I support tested and updated.

James McKenzie

-----Original Message-----

Frankly, there's plenty of good reasons for holding the release of WINE 1.2.

The FACT that many applications (games) are suddenly losing the audio after several minutes of play and then crashing to the desktop shortly thereafter is a pretty good reason for holding the release of WINE 1.2.

Repeatable example?

Most of the problems are caused by pulseaudio crashing, not Wine, BTW.
The driver may not fail, but it is causing Wine to crash. That is not a
Wine problem but a poor implemenation of an unneeded driver.

James McKenzie

Ahem ... this forum has 3 different people experiencing premature and random audio failure on 3 different applications after several minutes... and the problem isn't PulseAudio or outdated OpenAL ...

James McKenzie · Post by **James McKenzie** » Fri Jul 09, 2010 10:29 pm

tpreitzel wrote:

James McKenzie wrote:

tpreitzel wrote:

James Mckenzie wrote:

Frankly, there's plenty of good reasons for holding the release of WINE 1.2.

The FACT that many applications (games) are suddenly losing the audio after several minutes of play and then crashing to the desktop shortly thereafter is a pretty good reason for holding the release of WINE 1.2.

Repeatable example?

Most of the problems are caused by pulseaudio crashing, not Wine, BTW.
The driver may not fail, but it is causing Wine to crash. That is not a
Wine problem but a poor implemenation of an unneeded driver.

James McKenzie

Ahem ... this forum has 3 different people experiencing premature and random audio failure on 3 different applications after several minutes... and the problem isn't PulseAudio or outdated OpenAL ...

Bug report numbers?

Without them, the release is going to happen. With them, the release
may be delayed....

And if the problem is outside of Wine, there realistically is nothing we
can nor should do (other than report the problem to the affected Linux
distribution forums.)

James McKenzie

doh123 · Post by **doh123** » Sat Jul 10, 2010 12:44 am

don't worry... kinda like 1.0.1 there will probably be a 1.2.1

Post by **DanKegel** » Sat Jul 10, 2010 7:13 pm

See http://bugs.winehq.org/show_bug.cgi?id=23588

Looks like Scott got a bit fancy with the gcc options, and needs
to revert back to the plain old ones.

tpreitzel · Post by **tpreitzel** » Sat Jul 10, 2010 11:59 pm

doh123 wrote:don't worry... kinda like 1.0.1 there will probably be a 1.2.1

The WINE developers can pretty much bet that 1.2 won't be used much if this particular bug (audio dropping) remains.

oiaohm · Post by **oiaohm** » Sun Jul 11, 2010 12:20 am

As long as we don't get to rc 99 or something else insane its fine.

Wine 1.0.0 had 5 rc before release. If we want to be binary worring to future release it would be funny if it ends up a round 10 rc's.

But as always by wine policies stables are only released as such when they are done to the selection criteria.

This is not the Wine Lead Maintainers rules. This is rules of wine. Yes it annoys the hell out code-weavers who pays the Wine lead maintainers wage.

Yep the poor Wine Lead Maintainer does not need any more back set people saying are we there yet. He has enough pressure.

tpreitzel we(ie people doing support for wine) are not exactly sure where that audio bug is. Wine running on pure ALSA no pulseaudio it does not appear happen. Suspect scheduler issues where wine takes the lion share of CPU leaving nothing for pulseaudio.

Sven · Post by **Sven** » Sun Jul 11, 2010 4:25 am

Please try to upgrade to "wine1.2 1.2~rc7-0ubuntu2" from the Ubuntu ppa. It should be fixed there. This was not a wine bug, but a packaging bug for Ubuntu users only.

Post by **dimesio** » Sun Jul 11, 2010 9:15 am

tpreitzel wrote:
doh123 wrote:don't worry... kinda like 1.0.1 there will probably be a 1.2.1
The WINE developers can pretty much bet that 1.2 won't be used much if this particular bug (audio dropping) remains.

The development branch is not going to end with the release of 1.2.0.

James McKenzie · Post by **James McKenzie** » Sun Jul 11, 2010 11:05 am

oiaohm wrote:

As long as we don't get to rc 99 or something else insane its fine.

Wine 1.0.0 had 5 rc before release. If we want to be binary worring to future release it would be funny if it ends up a round 10 rc's.

But as always by wine policies stables are only released as such when they are done to the selection criteria.

This is not the Wine Lead Maintainers rules. This is rules of wine. Yes it annoys the hell out code-weavers who pays the Wine lead maintainers wage.

Yep the poor Wine Lead Maintainer does not need any more back set people saying are we there yet. He has enough pressure.

tpreitzel we(ie people doing support for wine) are not exactly sure where that audio bug is. Wine running on pure ALSA no pulseaudio it does not appear happen. Suspect scheduler issues where wine takes the lion share of CPU leaving nothing for pulseaudio.

oiaohm:

It is AJs opinion (and many of the other wine developers) that
pulseaudio is completely unnecessary. I agree. Add a layer to the
audio subsystem, and delay will develop. The community, outside of the
few folks that love pulseaudio, are looking towards openal. Yes, it is
coming back and it will be the audio equivalent of opengl. This will
reduce the number of layers needed to support audio.

As to the Direct Sound support in Wine, it will plug into openal when
all is done. Then it will be up to the vendors to build in this type of
support in hardware.

As to the 'skip to my lou' problems, this will NOT hold up Wine 1.2 as
it has been stated, "This is not a Wine problem. Disable and junk
pulseaudio and the problem goes away. WE are not going to fix other
people's brokenness." This has been demonstrated with the broken
Catalyst drivers from AMD/ATI (and we do have support from them to fix
it, they just don't know where to start.)

This problem is not Wine's as Sound works just fine on my Mac, and it
has the most crappy audio drivers known. I can and do play games on
this system as well as develop on it.

So, come Friday, unless there is a major show stopper, Wine 1.2 will be
released. Crappy sound drivers will not stop it. Switch to ALSA or OSS
or CoreAudio and ditch pulseaudio.

James McKenzie

James_Huk · Post by **James_Huk** » Sun Jul 11, 2010 5:24 pm

@James McKenzie:

I see we are going a little off topic, but I must ask few things:

1. Do I understand correctly that you are planning OpenAL back-end in place of (or in addition to) current ALSA/OSS/JACK/NAS sound back-ends?

2. Again - if I understand correctly, this back-end will work with ALSA,OSS4,DirectSound and CoreAudio (and probably with any other audio subsystem that have support for OpenAL)?

3. As for PulseAudio - I don't want to start flame here but... is it really that hard to implement (I mean - as I understand it, there already is a patch that adds support for it so...) Or you are not implementing it because you don't like PulseAudio, and don't want it to spread?

I say again - I don't want to start a war here, I am not a fan of current PA myself (however, I must say that I really like the idea of one API for all systems - from the programmer point of view), but since it is spreading (we like it or not) maybe you should reconsider support for it?

Thanks in advance for the answers.

Gert van den Berg · Post by **Gert van den Berg** » Sun Jul 11, 2010 6:51 pm

On Mon, Jul 12, 2010 at 00:24, James_Huk <[email protected]> wrote:

3. As for PulseAudio - I don't want to start flame here but... is it really that hard to implement (I mean - as I understand it, there already is a patch that adds support for it so...) Or you are not implementing it because you don't like PulseAudio, and don't want it to spread?

There was some really long discussions on wine-devel... Between
http://www.winehq.org/pipermail/wine-devel/ and
http://www.google.co.za/search?q=site%3 ... pulseaudio
you should be able to get an nice overview of the history... (The
"Fate of PulseAudio in WINE" thread seem to be the most recent one...)

As far as I can figure out, the planned architecture might be quite a
bit different than the current one, and might not leave room for
another driver.

AFAIK Windows OpenAL is already passed through to native OpenAL. (The
new driver should get the rest working as well...)

Gert

Usurp · Post by **Usurp** » Sun Jul 11, 2010 7:19 pm

James McKenzie wrote:oiaohm wrote:
As long as we don't get to rc 99 or something else insane its fine.

Wine 1.0.0 had 5 rc before release. If we want to be binary worring to future release it would be funny if it ends up a round 10 rc's.

But as always by wine policies stables are only released as such when they are done to the selection criteria.

This is not the Wine Lead Maintainers rules. This is rules of wine. Yes it annoys the hell out code-weavers who pays the Wine lead maintainers wage.

Yep the poor Wine Lead Maintainer does not need any more back set people saying are we there yet. He has enough pressure.

tpreitzel we(ie people doing support for wine) are not exactly sure where that audio bug is. Wine running on pure ALSA no pulseaudio it does not appear happen. Suspect scheduler issues where wine takes the lion share of CPU leaving nothing for pulseaudio.

oiaohm:

It is AJs opinion (and many of the other wine developers) that
pulseaudio is completely unnecessary. I agree. Add a layer to the
audio subsystem, and delay will develop. The community, outside of the
few folks that love pulseaudio, are looking towards openal. Yes, it is
coming back and it will be the audio equivalent of opengl. This will
reduce the number of layers needed to support audio.

As to the Direct Sound support in Wine, it will plug into openal when
all is done. Then it will be up to the vendors to build in this type of
support in hardware.

As to the 'skip to my lou' problems, this will NOT hold up Wine 1.2 as
it has been stated, "This is not a Wine problem. Disable and junk
pulseaudio and the problem goes away. WE are not going to fix other
people's brokenness." This has been demonstrated with the broken
Catalyst drivers from AMD/ATI (and we do have support from them to fix
it, they just don't know where to start.)

This problem is not Wine's as Sound works just fine on my Mac, and it
has the most crappy audio drivers known. I can and do play games on
this system as well as develop on it.

So, come Friday, unless there is a major show stopper, Wine 1.2 will be
released. Crappy sound drivers will not stop it. Switch to ALSA or OSS
or CoreAudio and ditch pulseaudio.

James McKenzie

Lets take Average Joe overview having this problem:
"This isn't even able to play sound in my game??
Lets go back to 1.0.1 and spray the word."

And since PA is in more and more distros today, you'll have a ton of average joes...

Post by **DanKegel** » Sun Jul 11, 2010 7:50 pm

The sudden audio problems in rc7 are well understood and a fix
is already available - it was in the ubuntu packaging, not in wine.
See http://bugs.winehq.org/show_bug.cgi?id=23588

James McKenzie · Post by **James McKenzie** » Sun Jul 11, 2010 8:00 pm

James_Huk wrote:

@James McKenzie:

I see we are going a little off topic, but I must ask few things:

1. Do I understand correctly that you are planning OpenAL back-end in place of (or in addition to) current ALSA/OSS/JACK/NAS sound back-ends?

Not I, another developer has been working on Wine<->OpenAL. It would be
best to address this in the wine-devel list AFTER Wine 1.2 is released.
It appears that he has great plans.

2. Again - if I understand correctly, this back-end will work with ALSA,OSS4,DirectSound and CoreAudio (and probably with any other audio subsystem that have support for OpenAL)?

Hopefully. The problem is OpenAL<->hardware support in audio devices.
We were here about ten years ago with OpenGL<->video.

3. As for PulseAudio - I don't want to start flame here but... is it really that hard to implement (I mean - as I understand it, there already is a patch that adds support for it so...) Or you are not implementing it because you don't like PulseAudio, and don't want it to spread?

The problem is not how hard, but if it is really needed. Pulseaudio
sits on top of ALSA/OSS and really introduces delays. There are 'fixes'
for it. Again, I'm not the one that made this decision, the Wine
maintainer did after reading through the code for pulseaudio.

I say again - I don't want to start a war here, I am not a fan of current PA myself (however, I must say that I really like the idea of one API for all systems - from the programmer point of view), but since it is spreading (we like it or not) maybe you should reconsider support for it?

Again, there is one API, really, for video, openGL. The same should
exist for audio devices. Moving device operation from software to
hardware drops the load on the main CPU and actually improves quality
and fidelity. Without GPUs, we might still be looking at VGA.

Lastly, I don't make decisions. The Wine maintainer did in coordination
with the Wine Development team. If PA ever reaches the quality of
current/future ALSA/OSS implementations, then the project MIGHT take
another look at it. I don't think this is going to happen. PA will
have to pickup in/out MIDI stream and MIDI device support as well.

For now, Wine is concentrating on ALSA/OSS/OpenGL. That is from reading
through the wine-devel mailing list.

James McKenzie