On Sat, 2017-12-30 at 13:23 +0100, David Henningsson wrote: > > 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."). Since adding automatic "misbehaviour" detection seems complex and prone to false positives, I prefer to apply my original patch that is arguably simpler but more limited. Georg acked the patch, so I pushed it now. -- Tanu https://www.patreon.com/tanuk
