It was reported[1] on alsa-devel that PulseAudio gets killed when trying to use the Intel HDMI LPE driver that was introduced in kernel version 4.11. That probably happens due to excessive CPU use in the IO thread. It's not known what causes the high CPU use, but the discussion revealed some definite shortcomings in PulseAudio when HDMI's underlying hw device is hw:x,0.
There are two bugs:
1) PulseAudio assumes that if the front:x device doesn't work but hw:x,0 does, then hw:x,0 is an analog stereo device.
2) PulseAudio assumes that HDMI devices are always mapped to certain hw:x,y devices, the first one being hw:x,3. When this assumption doesn't hold, jack detection and ELD reading don't work.
For the first bug, I propose trying hw:x,0 for analog stereo only if everything else fails, so if e.g. hdmi:x,0 is successfully opened, hw:x,0 won't be used.
For the second bug, I propose removing the hardcoded device numbers, and instead query the device number from an open PCM handle. That's not reliable for all PCM devices, but Takashi expects it to work for HDMI devices.
It's not obvious what would be the best way to modify the profile and path configuration syntax to support the new features. I'll prepare a more detailed proposal when I get around to it.
My impression is that the HDMI LPE driver will be widely used, so I think this should be fixed with high priority (I'll mark this as a release blocker).
It was reported[1] on alsa-devel that PulseAudio gets killed when trying to use the Intel HDMI LPE driver that was introduced in kernel version 4.11. That probably happens due to excessive CPU use in the IO thread. It's not known what causes the high CPU use, but the discussion revealed some definite shortcomings in PulseAudio when HDMI's underlying hw device is hw:x,0.
There are two bugs:
1) PulseAudio assumes that if the front:x device doesn't work but hw:x,0 does, then hw:x,0 is an analog stereo device.
2) PulseAudio assumes that HDMI devices are always mapped to certain hw:x,y devices, the first one being hw:x,3. When this assumption doesn't hold, jack detection and ELD reading don't work.
For the first bug, I propose trying hw:x,0 for analog stereo only if everything else fails, so if e.g. hdmi:x,0 is successfully opened, hw:x,0 won't be used.
For the second bug, I propose removing the hardcoded device numbers, and instead query the device number from an open PCM handle. That's not reliable for all PCM devices, but Takashi expects it to work for HDMI devices.
It's not obvious what would be the best way to modify the profile and path configuration syntax to support the new features. I'll prepare a more detailed proposal when I get around to it.
My impression is that the HDMI LPE driver will be widely used, so I think this should be fixed with high priority (I'll mark this as a release blocker).
[1] http:// mailman. alsa-project. org/pipermail/ alsa-devel/ 2017-March/ 118903. html