On 10/22/17 6:30 PM, Ian W MORRISON wrote:
On 21 October 2017 at 03:53, Takashi Iwai <tiwai@xxxxxxx> 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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
