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

[David Henningsson]

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.").

// David