No Sound and no D-Mic on ACER Aspire-VN7-792G with a Skylake-H #24
Comments
|
Hello @Gnoenk, Thanks for the detailed report. That's quite a lot of effort you did there! FYI the "error" messages you see when converting from UCM to BIN are info-messages, really. That is, alsatplg has no knowledge of what "lies ahead" when the dynamic approach is chosen. By dynamic I mean when the FE DAIs are initialized dynamically thanks to the topology plus CPUs are provided by the separate component driver which in this case represents SKL-H. Because it cannot know for sure, it dumps the messages for the user to interpret. Our interpretation: ignore. In regard to Question 1: your kernel is missing the peakvolume module support. The kernel driver encountered unknown/invalid (from its perspective) token so it dumped an error, ignored the file and continued on - HDAudio can be utilized like nothing has happened though. Peakvolume supported is long merged [1] into the Linus' tree, guess your base is simply older and has no support for that feature. In regard to Question 2: SKL-H devices usually default to non-DSP HDAudio stack - the DSP capabilities may be even fused out there. Without: static const struct avs_acpi_boards i2s_boards[] = {
AVS_MACH_ENTRY(HDA_SKL, avs_skl_i2s_machines),
(...)you "only" lose I2S boards i.e.: sound cards where data is streamed over I2S interface. HDAudio/DMIC configurations are left intact. As I'm not aware of any SKL-H + I2C codec configurations available on the market, I believe the entry is not required. Last but not least, Question 3: That's yet another problem that is related to the older kernel base. [1]: https://lore.kernel.org/all/20221214185500.3896902-1-amadeuszx.slawinski@linux.intel.com/ |
Almost forgot, happy New Year to you too @Gnoenk! |
|
Dear @crojewsk-intel Based upon this I have firstly updated my Linux Mint to Mint 21.2 with Linux Kernel 6.5 (which is the highest version offered by the Mint-Updater). Result:
Secondly with your advise that the messages from the UCM to BIN conversion step are "information-only" and can be ignored we have shortened my issue list by three items. Also I understand your answer on my question 2 in a way that the incoming sound is EITHER processed by a soundcard using I2S OR by the DMIC using another routing. So let us assume that my system is not affected by this exclusion described in my question. Now I was hoping for success but again received no functioning system. Repeating the search with the command results in a new output: OutputFeb 04 20:22:52 kernel: snd_soc_avs 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915]) Feb 04 20:22:52 kernel: snd_soc_avs 0000:00:1f.3: cldma_irq_handler sd_status: 0x00000004 Feb 04 20:22:52 kernel: snd_soc_avs 0000:00:1f.3: cldma_irq_handler sd_status: 0x00000004 Feb 04 20:22:52 kernel: avs_dmic avs_dmic: ASoC: Parent card not yet available, widget card binding deferred Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: autoconfig for ALC255: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: mono: mono_out=0x0 Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: dig-out=0x1e/0x0 Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: inputs: Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: Mic=0x1a Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: creating for ALC255 Analog 0 Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: creating for ALC255 Digital 1 Feb 04 20:22:52 kernel: snd_hda_codec_realtek hdaudioB0D0: skipping capture dai for ALC255 Digital Feb 04 20:22:52 kernel: avs_hdaudio avs_hdaudio.0: ASoC: Parent card not yet available, widget card binding deferred Feb 04 20:22:52 kernel: input: hdaudioB0D0 Mic as /devices/platform/avs_hdaudio.0/sound/card2/input13 Feb 04 20:22:52 kernel: input: hdaudioB0D0 Headphone as /devices/platform/avs_hdaudio.0/sound/card2/input14 Feb 04 20:22:52 kernel: snd_hda_codec_hdmi hdaudioB0D2: creating for HDMI 0 0 Feb 04 20:22:52 kernel: snd_hda_codec_hdmi hdaudioB0D2: skipping capture dai for HDMI 0 Feb 04 20:22:52 kernel: snd_hda_codec_hdmi hdaudioB0D2: creating for HDMI 1 1 Feb 04 20:22:52 kernel: snd_hda_codec_hdmi hdaudioB0D2: skipping capture dai for HDMI 1 Feb 04 20:22:52 kernel: snd_hda_codec_hdmi hdaudioB0D2: creating for HDMI 2 2 Feb 04 20:22:52 kernel: snd_hda_codec_hdmi hdaudioB0D2: skipping capture dai for HDMI 2 Feb 04 20:22:52 kernel: avs_hdaudio avs_hdaudio.2: ASoC: Parent card not yet available, widget card binding deferred Feb 04 20:22:52 kernel: avs_hdaudio avs_hdaudio.2: avs_card_late_probe: mapping HDMI converter 1 to PCM 1 (000000005f7c7c45) Feb 04 20:22:52 kernel: avs_hdaudio avs_hdaudio.2: avs_card_late_probe: mapping HDMI converter 2 to PCM 2 (00000000f7376e66) Feb 04 20:22:52 kernel: avs_hdaudio avs_hdaudio.2: avs_card_late_probe: mapping HDMI converter 3 to PCM 3 (000000009e6e6144) Feb 04 20:22:52 kernel: input: hdaudioB0D2 HDMI/DP,pcm=1 as /devices/platform/avs_hdaudio.2/sound/card3/input15 Feb 04 20:22:52 kernel: input: hdaudioB0D2 HDMI/DP,pcm=2 as /devices/platform/avs_hdaudio.2/sound/card3/input16 Feb 04 20:22:52 kernel: input: hdaudioB0D2 HDMI/DP,pcm=3 as /devices/platform/avs_hdaudio.2/sound/card3/input17 So what is still missing to get AVS working? |
|
The log shows.. success : ) Judging by the above, at least 5 endpoints should show up after typing I believe that an UCM is missing without which You can try streaming with alsa-utils apps e.g.: |
|
Dear @crojewsk-intel I tested the commands as per your advice and received the following responses: $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: hdaudioB0D0 [hdaudioB0D0], device 1: HDAudio Analog (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: hdaudioB0D2 [hdaudioB0D2], device 1: HDMI1 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: hdaudioB0D2 [hdaudioB0D2], device 2: HDMI2 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: hdaudioB0D2 [hdaudioB0D2], device 3: HDMI3 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
$ arecord -l
**** List of CAPTURE Hardware Devices ****
card 0: hdaudioB0D0 [hdaudioB0D0], device 1: HDAudio Analog (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: avsdmic [avs_dmic], device 2: Digital Microphone (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
$ aplay -Dhw:0,1 -c2 -r48000 -fS32_LE -vv /dev/urandom
Playing raw data '/dev/urandom' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
aplay: set_params:1416: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 48000
PERIOD_TIME: 125000
PERIOD_SIZE: 6000
PERIOD_BYTES: 48000
PERIODS: 4
BUFFER_TIME: 500000
BUFFER_SIZE: 24000
BUFFER_BYTES: 192000
TICK_TIME: 0
$ arecord -d 10 -f cd -t wav -D hw:3,2 foobar.wav
Recording WAVE 'foobar.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
Warning: rate is not accurate (requested = 44100Hz, got = 48000Hz)
please, try the plug pluginObservations:
So now I hope you have some additional ideas on what to do next. And more question on the UCM files.
As we had to create one symlink for the one BIN file I wonder whether we have do something similar for the related UCM file in order to let PulseAudio find it? |
|
I thought it might be helpful to see what these commands show when using the standard configuration (the one which does not detect the DMIC but all the rest - the one this quest started from...). $ journalctl -k | grep -E 'snd'
Mär 21 21:14:20 kernel: snd_hda_intel 0000:00:1f.3: DSP detected with PCI class/subclass/prog-if info 0x040100
Mär 21 21:14:20 kernel: snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops i915_audio_component_bind_ops [i915])
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC255: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0)
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: dig-out=0x1e/0x0
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: inputs:
Mär 21 21:14:20 kernel: snd_hda_codec_realtek hdaudioC0D0: Mic=0x1a
$ aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC255 Analog [ALC255 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 1: ALC255 Digital [ALC255 Digital]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 3: HDMI 0 [HDMI 0]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 7: HDMI 1 [HDMI 1]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 0: PCH [HDA Intel PCH], Gerät 8: HDMI 2 [HDMI 2]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
$ arecord -l
**** Liste der Hardware-Geräte (CAPTURE) ****
Karte 0: PCH [HDA Intel PCH], Gerät 0: ALC255 Analog [ALC255 Analog]
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0Hope this is useful. Thank you so much for your thoughts and suggestions! |
|
Hello, UCM (file extension: .conf) is a meta language that helps describe use-cases and components of given audio endpoint. It is utilized by ASoC-topology and endpoint-configuration both. These two have totally different purpose though. The former helps describe the layout of an audio stream e.g.: pipelines/modules on the DSP (firmware) side, while the latter tells an audio application/server what kcontrols and switches should be updated to get certain scenario working. Example of such scenario: Let's have two endpoints: headphone and a speaker endpoints which both route to the same BackEnd e.g.: HDAudio BE. Only one of them can be utilized at a time. Thus, an endpoint-configuration (UCM) file would state that in order to open the speaker endpoint, a switch for the headphone must be turned off. In regard to questions, starting from the top:
As UCM area is generally outside of the kernel space and I'm not an expect there. Contacted my friends from the validation team who are more fluent in the UCMs to help here. |
|
Dear @crojewsk-intel Thank you for your explanation of the UCM files. I really hope that your friends can help us finding out what needs to be done here. On your answer 3) referring to my comment on a "failure". $ aplay -Dhw:0,1 -c2 -r48000 -fS32_LE -vv /dev/urandom
Playing raw data '/dev/urandom' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
aplay: set_params:1416: Unable to install hw params:I have interpreted the text Following your advice I have created logfiles per scenario/case. But I am not sure if my result is what you meant exactly with "dmesg/trace" files. I tried to find out how set additional tracing options but was not able to do this. So using I have produced two logfiles for the two cases. Case1: standard settings (base case). Result: sound works, no DMIC (file is dmesg_case1.log.gz). Case2: forced activation of AVS driver by setting In the second logfile I could find only
I hope you can retrieve more useful hints in these logfiles. With some help I am happy to generate more specific ones if needed. |
|
Please do add: on top of whatever you already have in your Are the logs taken from streaming scenario or just the boot up? If the latter is true, please do attach logs from the stream/streaming-attempt scenario. In regard to the NHLT question, entry here means: element of the table e.g.: an entry describing I2S hardware configuration for an I2S endpoint exposed to the userspace or a PDM entry describing hardware configuration needed to stream data over DMIC endpoint exposed to the userspace. NHLT is an array of such entries basically. that follow up these, enumeration of HDAudio and HDMI card completes just fine. I do not see any inputs from DMIC card though. Dynamic debug (dyndbg flags) will help here. I'll refrain from doing any guesses, rather have enriched dmesg attached first. |
|
Dear @crojewsk-intel I have now added the debug instructions as you advised and produced two new logs by applying These two logs are indeed taken from boot up. To cover the streaming scenario I applied the $ LC_ALL=C aplay -Dhw:0,1 -c2 -r48000 -fS32_LE -vv /dev/urandom
aplay: main:831: audio open error: No such file or directoryNow I wondered what to do next - which took some time for me to figure out unfortunately. Using $ aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 2: hdaudioB0D0 [hdaudioB0D0], Gerät 1: HDAudio Analog (*) []
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 3: hdaudioB0D2 [hdaudioB0D2], Gerät 1: HDMI1 (*) []
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 3: hdaudioB0D2 [hdaudioB0D2], Gerät 2: HDMI2 (*) []
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 3: hdaudioB0D2 [hdaudioB0D2], Gerät 3: HDMI3 (*) []
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0So I modified the command to -Dhw:2,1 resulting in the message seen in the earlier attempt: $ LC_ALL=C aplay -Dhw:2,1 -c2 -r48000 -fS32_LE -vv /dev/urandom
Playing raw data '/dev/urandom' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
aplay: set_params:1416: Unable to install hw params:
ACCESS: RW_INTERLEAVED
FORMAT: S32_LE
SUBFORMAT: STD
SAMPLE_BITS: 32
FRAME_BITS: 64
CHANNELS: 2
RATE: 48000
PERIOD_TIME: 125000
PERIOD_SIZE: 6000
PERIOD_BYTES: 48000
PERIODS: 4
BUFFER_TIME: 500000
BUFFER_SIZE: 24000
BUFFER_BYTES: 192000
TICK_TIME: 0Now I did rerun the command Hope it contains helpful info. |
|
Thank you for the logs, The important part (of dmesg_case2d.log): i.e.: this is (was) a known problem that we addressed on upstream before marking the avs-driver as the go-to driver. That is, most commonly used format for streaming over devices offloaded with Intel AudioDSP is 24 valid bit depth in 32 bit depth container, so called 24/32. The closest ALSA comes to that is S24_LE (signed 24 bits in 32 physical bits container, LittleEndian (LE), LeastSignificantBit (LSB) representation) format which, from HDAudio perspective, is unfortunately invalid - HDAudio transfers is data in MostSignificantBit (MSB) manner, chapter 5.3.1 of the public HDAudio specification. No representation for that in ALSA though. The problem was left unaddressed on upstream for years. The team decided to handle this properly by updating alsa-lib [1], alsa-utils [2] and the kernel [3] simultaneously. All the changes have been already merged but that happened quite recently - Nov/Dec 2023 - so my guess it that your environment does not have them. As the configuration of yours is an opt-in one, I do not see a strong argument that I could use to backport the changes onto v6.5 linux-stable. From what I know, v6.8 is the earliest kernel where the changes are available. Of course, there's also an option to backport the kernel changes yourself but that's usually for experts. With those changes present, hda-generic topology that is part of the avs-topology release [4] should work just fine. [1]: alsa-project/alsa-lib#342 |
|
FYI: upstream of the UCM files is conducted on alsa-ucm-conf by Amadeusz [1]. |
|
Given the technical explanation provided above, I do not see any issue left unattended. As there hasn't been any response from author for quite a while, closing the subject. If anything new pops up that is related and unaddressed, please open a new issue. |
|
Dear @crojewsk-intel thank you for your further explanations. Now I have moved to Mint 22 "Wilma" (based on Ubuntu 24.04 LTS) with Kernel 6.8.0.39. I expected all Alsa-Components to be on the latest version as well. But only Alsa-Lib was on version 1.2.11-1build2 whilst Alsa-Utils was still on version 1.2.9-1ubuntu5. So with this new configuration Using $ LC_ALL=C aplay -l
**** List of PLAYBACK Hardware Devices ****
card 1: hdaudioB0D0 [hdaudioB0D0], device 1: HDAudio Analog (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: hdaudioB0D2 [hdaudioB0D2], device 1: HDMI1 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: hdaudioB0D2 [hdaudioB0D2], device 2: HDMI2 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 3: hdaudioB0D2 [hdaudioB0D2], device 3: HDMI3 (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0Using $ LC_ALL=C arecord -l
**** List of CAPTURE Hardware Devices ****
card 1: hdaudioB0D0 [hdaudioB0D0], device 1: HDAudio Analog (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: avsdmic [avs_dmic], device 2: Digital Microphone (*) []
Subdevices: 1/1
Subdevice #0: subdevice #0To cover the streaming scenario we applied the $ LC_ALL=C aplay -Dhw:1,1 -c2 -r48000 -fS32_LE --subformat=MSBITS_24 -vv /dev/urandom
Playing raw data '/dev/urandom' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
Hardware PCM card 1 'hdaudioB0D0' device 1 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S32_LE
subformat : MSBITS_24
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : ENABLE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 24000
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
appl_ptr : 0
hw_ptr : 0
##################################################+| 99%^C
Aborted by signal Interrupt...
##################################################+| 99%
$ LC_ALL=C aplay -Dhw:1,1 -c2 -r48000 -fS32_LE -vv /dev/urandom
Playing raw data '/dev/urandom' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
Hardware PCM card 1 'hdaudioB0D0' device 1 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : ENABLE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 24000
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
appl_ptr : 0
hw_ptr : 0
##################################################+| 99%^C
Aborted by signal Interrupt...
##################################################+| 98%So real progress made! Unfortunately under normal operation there is still no sound and no microphone functionality. So again I run the command Then I tried additionally (after a reboot) $ arecord -l
**** Liste der Hardware-Geräte (CAPTURE) ****
Karte 1: hdaudioB0D0 [hdaudioB0D0], Gerät 1: HDAudio Analog (*) []
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
Karte 3: avsdmic [avs_dmic], Gerät 2: Digital Microphone (*) []
Sub-Geräte: 1/1
Sub-Gerät #0: subdevice #0
$ LC_ALL=C arecord -Dhw:3,2 -c2 -r48000 -fS32_LE -vv recording.pcm
Hardware PCM card 3 'avs_dmic' device 2 subdevice 0
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : S32_LE
subformat : STD
channels : 2
rate : 48000
exact rate : 48000 (48000/1)
msbits : 32
buffer_size : 24000
period_size : 6000
period_time : 125000
tstamp_mode : ENABLE
tstamp_type : MONOTONIC
period_step : 1
avail_min : 6000
period_event : 0
start_threshold : 1
stop_threshold : 24000
silence_threshold: 0
silence_size : 0
boundary : 6755399441055744000
appl_ptr : 0
hw_ptr : 0
Recording WAVE 'recording.pcm' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo
#+ | 00%^C
Aborted by signal Interrupt...
$ hexdump -C recording.pcm
00000000 52 49 46 46 e4 d9 10 00 57 41 56 45 66 6d 74 20 |RIFF....WAVEfmt |
00000010 10 00 00 00 01 00 02 00 80 bb 00 00 00 dc 05 00 |................|
00000020 08 00 20 00 64 61 74 61 c0 d9 10 00 00 00 00 00 |.. .data........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
0010d9e0 00 00 00 00 00 00 00 00 00 00 00 00 |............|
0010d9ecwhich only created a file containing nullbytes only. Repeating the command Hope that this provides useful information for further analysis. |
Dear @crojewsk-intel
it is me again.
After sometime I could continue to work on my computer trying to enable DMIC functionality on my ACER Aspire-VN7-792G with a Skylake-H (ID: 0xa170) running under Linux Mint 21.1 now with Linux Kernel 6.2.
According to your advice in our conversation under https://gist.github.com/crojewsk/4e6382bfb0dbfaaf60513174211f29cb I have updated my Linux to Kernel 6.20 under MINT. My understanding was that the new AVS driver, which are now part of Kernel 6.x should then be part of the system and get activated automatically. As this did not happen I tried to force the activation by setting
snd_intel_dspcfg.dsp_driver=4in/etc/modprobe.d/alsa-base.conf.Result: I had no sound at all.
Finding this issue #5 in GitHub my next assumption was that despite the Kernel update performed the
linux-firmwarepackage was not up to date. Thus I manually downloaded the/lib/intel/avs/skl/*firmware from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/ and installed it in/lib/firmware.Next step was to manually convert and install all the topology files from https://github.com/thesofproject/avs-topology-xml according to your instructions given there.
So I installed
alsa-utilsforalsatplgand builtavstplgmanually from thesofproject/avsdk@999b25e.Step 1: Conversion from XML to UCM by using
avstplgworked fine.Note: I had to use DOTNET 6 as I encountered error messages while using DOTNET 7 first.
Step 2: Conversion from UCM to BIN by using
alsatplgshowed some messages.Should I be using a newer version of
alsatplgthan the one provided by MINT?Error Messages
Then I also faced the issue with the missing
hda-10ec0255-tplg.binfile mentioned in #20 thus I created a symlink according to your advice.This is shown by the
treecommandNow I had completed all steps described but still no succes.
The command
results in:
Output
Question 1: as the log reports that
dmic-tplg.binfailed to load - does this means that the file conversion to bin failed?In parallel I searched for further errors.
In our former conversation you have written, that Skylake-H with ID 0xa170 has been added to the AVS driver.
I did some research and could find that this ID got mentioned in your patch for the
core.cfile.https://lore.kernel.org/alsa-devel/20221010121955.718168-8-cezary.rojewski@intel.com/
Here I could read that you have added 0xa170 to
avs_ids(the list of supported boards?) incore.c.This file got modified a bit and the ID got moved into https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/pci_ids.h and gets refered to by the Symbol
HDA_SKL.https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/intel/avs/core.c
I can now find in row 757 a similar section using the symbols but no device ids.
So
core.cappears to be complete.The descripton page of https://github.com/thesofproject/avs-topology-xml has this note:
Thus I checked
board_selection.cin https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/intel/avs/board_selection.c and I find in row 293 only a line with the symbolHDA_SKL_LPwhich targets the low power version only.Question2: Does this still prevents SKL-H platforms from being included?
(Working Note: for the sake of completeness I have crosschecked the linux kernel source files under 6.2 and current main. Only difference is the shift to using symbols and addin the PCI-ID into the header file pci_ids.h).
Question 3: Additionally when shutting down the machine with the activated AVS-Driver I experienced issues at the end of the shutdown process. These disappeared when deactiving the option in
alsa-base.config.Grateful for your assistance in resolving this issue. Have a happy New Year!
The text was updated successfully, but these errors were encountered: