On 30.12.2017 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?
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.
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
