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

[Alexander E. Patrakov]

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.

But, it's up to you to decide.

-- 
Alexander E. Patrakov