[alsa-devel] HDMI LPE audio on Intel Compute Stick 2nd Gen (CHT)

[Pierre-Louis Bossart]

On 10/22/17 6:30 PM, Ian W MORRISON wrote:
> On 21 October 2017 at 03:53, Takashi Iwai <tiwai at suse.de> wrote:
> 
>> On Fri, 20 Oct 2017 17:54:45 +0200,
>> Pierre-Louis Bossart wrote:
>>>
>>> On 10/20/17 8:45 AM, Ian W MORRISON wrote:
>>>>> I've just noticed that non of the kernels from v4.13 and up run on my
>>>>>> Intel Compute Stick (2nd gen Cherry Trail STK1AW32SC) unit and have
>>>>>> HDMI LPE audio working.
>>>>>>
>>>>>
>>>>> I have not tested HDMI in a while but I am not aware of any issues
>> either.
>>>>> There were some patches recently to fix PulseAudio problems and I
>> suppose
>>>>> some folks used a recent kernel?
>>>>>
>>>>>
>>>> It actually happened since v4.12 as now I get three HDMI LPE Audio
>> devices
>>>> show up with 'aplay -l' rather than just one. Only 'device 2' works so
>> if I
>>>> change the sink to use that device I get sound. So basically it can be
>>>> fixed in userland however I'm seeing others with different devices also
>>>> complaining how audio is broken and I think it is something that many
>> users
>>>> don't know to fix. Is it worth looking into further or just leaving it
>> as a
>>>> known issue?
>>>
>>> I don't think it's a bug, it's a feature...
>>> The jack information tells you which device is connected/active, so
>>> userspace has all the data needed to select the right routing.
>>
>> Right, it's a new feature that was recently added, for supporting
>> multiple HDMI/DPs.  The latest PA should be able to check the jack
>> detection of each port, so that it can switch to the actually
>> connected one.
>>
>>
>> Takashi
>>
> 
> Thanks for the explanation. The PA package for Ubuntu is a bit behind (v8
> for 16.04 LST and v10 for latest 17.10) so it will be easier for users just
> to edit /etc/pulse/default.pa in the interim. But is there a way to stop
> the multiple and repeating "Audio Port: ASoC: no backend DAIs enabled for
> Audio Port" messages in dmesg from occurring without modifying the distro's
> kernel?

That issue comes from the mixer configuration (or lack thereof) or 
missing UCM files, it's not really a kernel issue.
We've talked in the past of moving existing UCM files to a new repo 
(with a clarified license) and adding the ones I maintained, it's likely 
to happen after we are done with the open-source firmware (SOF) 
integration which requires some plumbing to the life of distros easier.