Just as the title says, I've got a couple problems/questions that don't have much in common except for "happening in wine". 1. regedit and long REG_BINARY values: the edit control should either be made resizable or scrollable, cause long values just don't fit in the box; as a temporary solution, I've made a hackish patch, that changes the font the control uses (not sure if that's necesarry, but it's just feels more natural to use monospaced font here), makes sure all glyphs get the same space and once the value wraps, if it's a non-integer divide, the last line is correctly placed; 2. alsa/pulseaudio and stream recovery: as in the past, it's hard to tell if it's wine or the underlaying stuff that fails; the problem I'm hearing is that apps sometimes without any apparent reason (as CPU usage isn't all that different than the average) go into '(snd_pcm_recover) underrun occurred' mode and start playing the sounds on much higher rate and then just as randomly (as it's again seemingly not related to CPU usage) recover; it's the randomness that bothers me: both going into the state *and* not recovering for several minutes; would it be possible, if not outright fix that, then for example add a helper app, that the user could manually trigger to force recovery ? 3. err:ntdll:RtlpWaitForCriticalSection wait timed out in thread <nr>, blocked by <nr>, retrying (60 sec): this is an annoyance, sometimes a major one; namely, it happens that I terminate an app by pressing ^C; usually, that works just fine, but every now and then app goes into that unterminatable state and not for those 60 sec (which is horribly long anyway), but pretty much indefinitelly; it really shouldn't do that; this requires a taskmgr or wineboot intervention to close it 4. (somewhat related to the previous) taskmgr could use a little enhancement: when running several apps with the same executable name, it's very hard to tell (impossible ?) how a line from process tab relates to application tab; usually it's not much of a problem, but if point 3 strikes, there's no more entry in the app tab, but the process is still there and you need to guess, which will often be wrong; perhaps the entries in the process tab should print the app name or have an option in the context menu to retrieve it ?
On Mon, Jan 23, 2017 at 04:26:14PM +0100, Rafał Mużyło wrote:
2. alsa/pulseaudio and stream recovery: as in the past, it's hard to tell if it's wine or the underlaying stuff that fails; the problem I'm hearing is that apps sometimes without any apparent reason (as CPU usage isn't all that different than the average) go into '(snd_pcm_recover) underrun occurred' mode and start playing the sounds on much higher rate and then just as randomly (as it's again seemingly not related to CPU usage) recover; it's the randomness that bothers me: both going into the state *and* not recovering for several minutes; would it be possible, if not outright fix that, then for example add a helper app, that the user could manually trigger to force recovery ?
Are you using PulseAudio via winealsa with the alsa-pulse plugin? Why not just use the winepulse driver? Andrew
On Tue, Jan 24, 2017 at 08:42:12AM -0600, Andrew Eikum wrote:
On Mon, Jan 23, 2017 at 04:26:14PM +0100, Rafał Mużyło wrote:
2. alsa/pulseaudio and stream recovery: as in the past, it's hard to tell if it's wine or the underlaying stuff that fails; the problem I'm hearing is that apps sometimes without any apparent reason (as CPU usage isn't all that different than the average) go into '(snd_pcm_recover) underrun occurred' mode and start playing the sounds on much higher rate and then just as randomly (as it's again seemingly not related to CPU usage) recover; it's the randomness that bothers me: both going into the state *and* not recovering for several minutes; would it be possible, if not outright fix that, then for example add a helper app, that the user could manually trigger to force recovery ?
Are you using PulseAudio via winealsa with the alsa-pulse plugin? Why not just use the winepulse driver?
Well, because reasons... OK, a less tongue-in-cheek answer: while I've been working under pulseaudio for quite awhile (if you recall my older posts/bugs), I'm still of a strong opinion, that barring very specific needs (like audio authoring), anything that works with pure alsa, should just as well work with pulseaudio underneath, unless there's a bug in alsa's pulseaudio plugin or pulseaudio itself - then it's that bug that needs to be adressed (well, at least in the long term). What's more the random nature of the problem (both triggering it - sometimes things work for hours just fine - and getting cleaned up - again, sometimes it gets cleaned up fast enough it's barely noticable; coupled with the trigger *seemingly* not being tied to actual CPU usage, just happening on a whim...) irks me.
On Tue, Jan 24, 2017 at 04:33:58PM +0100, Rafał Mużyło wrote:
On Tue, Jan 24, 2017 at 08:42:12AM -0600, Andrew Eikum wrote:
On Mon, Jan 23, 2017 at 04:26:14PM +0100, Rafał Mużyło wrote:
2. alsa/pulseaudio and stream recovery: as in the past, it's hard to tell if it's wine or the underlaying stuff that fails; the problem I'm hearing is that apps sometimes without any apparent reason (as CPU usage isn't all that different than the average) go into '(snd_pcm_recover) underrun occurred' mode and start playing the sounds on much higher rate and then just as randomly (as it's again seemingly not related to CPU usage) recover; it's the randomness that bothers me: both going into the state *and* not recovering for several minutes; would it be possible, if not outright fix that, then for example add a helper app, that the user could manually trigger to force recovery ?
Are you using PulseAudio via winealsa with the alsa-pulse plugin? Why not just use the winepulse driver?
Well, because reasons...
OK, a less tongue-in-cheek answer: while I've been working under pulseaudio for quite awhile (if you recall my older posts/bugs), I'm still of a strong opinion, that barring very specific needs (like audio authoring), anything that works with pure alsa, should just as well work with pulseaudio underneath, unless there's a bug in alsa's pulseaudio plugin or pulseaudio itself - then it's that bug that needs to be adressed (well, at least in the long term). What's more the random nature of the problem (both triggering it - sometimes things work for hours just fine - and getting cleaned up - again, sometimes it gets cleaned up fast enough it's barely noticable; coupled with the trigger *seemingly* not being tied to actual CPU usage, just happening on a whim...) irks me.
The reason you should use the winepulse driver for a system using PulseAudio is because the ALSA API can't inform the application of latency changes. PA sometimes changes the latency parameters of the stream and informs its clients of this change, which should then compensate. But the ALSA API has no way to communicate this to the application, and things break as we assume the old latency parameters still hold. This particularly presented itself as choppy audio with USB devices, but it can be reproduced with any other latency change. For example, just opening 'pavucontrol' can cause a latency change. I suspect "something" is triggering a latency change on your system. Perhaps PA debug logs could tell you. Also, using winepulse means there's one fewer "part" in the audio system, and so one fewer place to have bugs. Andrew
On Wed, Jan 25, 2017 at 8:16 AM Andrew Eikum <aeikum(a)codeweavers.com> wrote:
On Tue, Jan 24, 2017 at 04:33:58PM +0100, Rafał Mużyło wrote:
On Tue, Jan 24, 2017 at 08:42:12AM -0600, Andrew Eikum wrote:
Are you using PulseAudio via winealsa with the alsa-pulse plugin? Why not just use the winepulse driver?
Well, because reasons...
Also, using winepulse means there's one fewer "part" in the audio system, and so one fewer place to have bugs.
And fewer places to introduce latency as audio data flows between threads that may be fighting for scheduling. -Chris Harrington
2017-01-23 16:26 GMT+01:00 Rafał Mużyło <galtgendo(a)gmail.com>:
1. regedit and long REG_BINARY values: the edit control should either be made resizable or scrollable, cause long values just don't fit in the box; as a temporary solution, I've made a hackish patch, that changes the font the control uses (not sure if that's necesarry, but it's just feels more natural to use monospaced font here), makes sure all glyphs get the same space and once the value wraps, if it's a non-integer divide, the last line is correctly placed;
I guess this is worthy of a bug report.
3. err:ntdll:RtlpWaitForCriticalSection wait timed out in thread <nr>, blocked by <nr>, retrying (60 sec): this is an annoyance, sometimes a major one; namely, it happens that I terminate an app by pressing ^C; usually, that works just fine, but every now and then app goes into that unterminatable state and not for those 60 sec (which is horribly long anyway), but pretty much indefinitelly; it really shouldn't do that; this requires a taskmgr or wineboot intervention to close it
You shouldn't terminate applications like that. You might catch the application in the middle of "something", inside some locked section or similar. There is no way for Wine to fix things afterwards in general.
4. (somewhat related to the previous) taskmgr could use a little enhancement: when running several apps with the same executable name, it's very hard to tell (impossible ?) how a line from process tab relates to application tab; usually it's not much of a problem, but if point 3 strikes, there's no more entry in the app tab, but the process is still there and you need to guess, which will often be wrong; perhaps the entries in the process tab should print the app name or have an option in the context menu to retrieve it ?
This also could be an enhancement bug report.
On Wed, Jan 25, 2017 at 12:26:24AM +0100, Matteo Bruni wrote:
2017-01-23 16:26 GMT+01:00 Rafał Mużyło <galtgendo(a)gmail.com>:
3. err:ntdll:RtlpWaitForCriticalSection wait timed out in thread <nr>, blocked by <nr>, retrying (60 sec): this is an annoyance, sometimes a major one; namely, it happens that I terminate an app by pressing ^C; usually, that works just fine, but every now and then app goes into that unterminatable state and not for those 60 sec (which is horribly long anyway), but pretty much indefinitelly; it really shouldn't do that; this requires a taskmgr or wineboot intervention to close it
You shouldn't terminate applications like that. You might catch the application in the middle of "something", inside some locked section or similar. There is no way for Wine to fix things afterwards in general.
Oh, really ???... The thing is I've seen that happen on closing main app window or even standard app exit. Granted, it's quite rare, still... My point is that when that happens, subsequent ^C has no effect. Would it be possible to (for example) add a generic SIGINT handler to wine sever, so that upon receiving ^C from its terminal the Windows app would go into the standard forced shutdown cycle (that is the one hung apps go upon Windows shutdown) instead of this repeated 60 sec. wait ? As for the regedit patch, it's more of a question, than an answer. I've simply took a few lines from another place in wine (can't recall which anymore), then started thinking out loud. The end result feels a bit messy, even if it solved the problem for me. If you consider it good enough, :shrug: fine by me.
participants (4)
-
Andrew Eikum -
Christopher Harrington -
Matteo Bruni -
Rafał Mużyło