On 2017-12-30 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? No idea. And I've switched graphics card since, so I can't test either. // David
