[pulseaudio-discuss] [PATCH 1/3] alsa: fix infinite loop with Intel HDMI LPE

[Tanu Kaskinen]

On Sat, 2017-12-30 at 13:23 +0100, David Henningsson wrote:
> 
> On 2017-12-30 13:03, Georg Chini wrote:
> > On 30.12.2017 10:54, Alexander E. Patrakov wrote:
> > > 2017-12-29 20:37 GMT+08:00 Tanu Kaskinen <tanuk at iki.fi>:
> > > > On Fri, 2017-12-29 at 11:46 +0800, Alexander E. Patrakov wrote:
> > > > > 2017-12-28 18:09 GMT+08:00 Tanu Kaskinen <tanuk at iki.fi>:
> > > > > > The Intel HDMI LPE driver works in a peculiar way when the HDMI 
> > > > > > cable is
> > > > > > not plugged in: any written audio is immediately discarded and 
> > > > > > underrun
> > > > > > is reported. That resulted in an infinite loop, because PulseAudio 
> > > > > > tried
> > > > > > to keep the buffer filled, which was futile since the written 
> > > > > > audio was
> > > > > > immediately consumed/discarded.
> > > > > > 
> > > > > > This patch adds special handling for the LPE driver: if the active 
> > > > > > port
> > > > > > of the sink is unavailable, the sink suspends itself. A new suspend
> > > > > > cause is added: PA_SUSPEND_UNAVAILABLE.
> > > > > 
> > > > > I think this is not a complete fix. There was a case in the past where
> > > > > some other card started eating samples too quickly (some Radeon?
> > > > > unfortunately, can't find it now). While blacklisting one known bad
> > > > > driver helps, I think it would be better to detect the misbehavior at
> > > > > runtime, based on the number of samples written and the wall-clock
> > > > > time. If the card stalls or eats samples too quickly, set a flag that
> > > > > it misbehaves, accept the xrun, and then set it to off when
> > > > > convenient.
> > > > > 
> > > > > Sorry, I have no time to help with the code :(
> > > > 
> > > > Did that other sample-eating sound card exhibit the behaviour only when
> > > > unplugged? With the LPE driver we know that we can resume once the
> > > > cable is plugged in again. If we don't take the jack state into
> > > > consideration, then we don't know when we should try resuming.
> > > 
> > > Yes, it was only when unplugged. The thread (found it!) starts here:
> > > 
> > > http://mailman.alsa-project.org/pipermail/alsa-devel/2014-September/081365.html 
> > > 
> > > 
> > > David: do you know whether it has been fixed in the kernel in that case?
> > > 
> > > > I can change the patch so that the sink is suspended when both of the
> > > > conditions are fulfilled: too fast sample consumption and jack
> > > > unplugged.
> > > 
> > > I think an "or" condition would be more appropriate here, for
> > > robustness. The real bug here is the CPU overuse (in the worst case,
> > > infinite loop) due to too-fast sample consumption by a misbehaving
> > > soundcard driver (but we accept that this misbehavior happens and we
> > > have to deal with it). The fact that the cable is unplugged is just
> > > one known trigger.
> > 
> > If the sample rate significantly deviates from the nominal value when
> > the jack is plugged, would that not mean that the card (or the driver)
> > is broken and the card is therefore unusable?
> > I think the only situation where the misbehavior is acceptable is when
> > the jack is unplugged, so force-suspending the sink on unplug seems
> > sufficient to me.
> 
> Btw, if there are buffers that need to be filled up beyond our own ALSA 
> buffer, it would be possible that the card fills those buffers first, 
> which might look to us like a "too high sample rate".
> There is already a workaround for this problem in alsa-sink.c (see 
> comment "USB devices on ALSA seem to hit a buffer
> underrun during the first iterations much quicker then we calculate 
> here, probably due to the transport latency.").

Since adding automatic "misbehaviour" detection seems complex and prone
to false positives, I prefer to apply my original patch that is
arguably simpler but more limited. Georg acked the patch, so I pushed
it now.

-- 
Tanu

https://www.patreon.com/tanuk