A couple unrelated issues

[Andrew Eikum]

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