[pulseaudio-discuss] [PATCH 0/3] Fix jack detection for Intel HDMI LPE

[Tanu Kaskinen]

On Sat, 2017-07-15 at 11:24 +0530, Arun Raghavan wrote:
> 
> On Mon, 12 Jun 2017, at 09:15 PM, Tanu Kaskinen wrote:
> > These patches hopefully fix jack detection (and ELD information
> > querying too) for Intel HDMI LPE. I don't have the hardware myself, so
> > further testing would be very welcome. Hans, Takashi and Pierre, you're
> > in Cc, because you indicated in this[1] thread that you have the
> > hardware.
> > 
> > Testing instructions:
> > 
> > First, before installing the modified PulseAudio version, check if you
> > still suffer from the problem that the kernel kills PulseAudio. I don't
> > know if these patches are sufficient to fix that problem, but it's worth
> > trying.
> > 
> > Next, apply the patches on top of the current PulseAudio master branch
> > and install the modified version. After installing, set
> > "realtime-scheduling = no" in daemon.conf to prevent the kernel from
> > killing PulseAudio.
> > 
> > Then, start pulseaudio and check if jack detection is working.
> > "pactl list cards" will show the cards, their profiles and the port
> > status. The HDMI card should only list HDMI profiles in the "Profiles:"
> > section (check that there are no analog profiles listed), and the port
> > status should change between "available" and "unavailable" in the
> > "Ports:" section as you plug the HDMI cable in and out.
> > 
> > If the jack detection seems to work, try setting
> > "realtime-scheduling = yes" in daemon.conf to see if the kernel still
> > kills PulseAudio.
> 
> I don't have the hardware to test this, so just a plain review
> follows...
> 
> The code looks fine, but I'm a bit concerned by adding such specific
> configuration parameters to the mapping files. This is just increasing
> complexity w.r.t. what we have to maintain more or less forever.
> 
> In my mind, it seems like it would be much nicer to have a way to signal
> the ELD device from the driver, rather than all this mucking around in
> configuration.
> 
> Takashi, Hans, Pierre: would it be possible to get such a mechanism?
> 
> I'm guessing that even if such a mechanism were to exist, we're going to
> have to wait for it to happen and be widely available, so let's go ahead
> and get Tanu's patches in, so that the hardware works ootb.

The driver already signals the ELD device. It's just that alsa-lib kind
of loses track of that information (or maybe it doesn't, maybe
snd_pcm_info_get_device() is more reliable than I think).

It would be nice to have a function in alsa-lib for returning the
underlying hw device number. snd_pcm_info_get_device() already does
that at least in some cases, but it's not documented how it behaves
when there are additional layers on top of the hw PCM. Takashi said
that it should work fine for the "hdmi:" devices, but can it always be
relied to either return the correct device number or an error? What
does the function do if there are multiple hw PCM devices behind a
plugin PCM? Hopefully it returns an error in that case. If it's
reliable enough, then we can query the hw device number for every
mapping, so we don't need special handling for HDMI.

Another option for avoiding the "query_hw_device" option would be to
query the device number automagically when a mapping's device string
starts with "hdmi:", but I don't really like that kind of magic.

-- 
Tanu

https://www.patreon.com/tanuk