On 2017-12-30 10:54, Alexander E. Patrakov wrote:
2017-12-29 20:37 GMT+08:00 Tanu Kaskinen <ta...@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 <ta...@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
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
