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:
- 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