Bug 187591 - Sound card sdn-hda-intel not recognized on Intel Bay Trail chipset
Summary: Sound card sdn-hda-intel not recognized on Intel Bay Trail chipset
Status: NEW
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: Intel Linux
: P1 high
Assignee: Jaroslav Kysela
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-11-14 10:03 UTC by Davide Pucci
Modified: 2017-04-30 21:33 UTC (History)
10 users (show)

See Also:
Kernel Version: 4.8.6
Tree: Mainline
Regression: No


Attachments
alsa-info.sh output on linux 4.8.6 (13.28 KB, text/plain)
2016-11-14 11:18 UTC, Davide Pucci
Details
alsa-info.sh output on linux 4.4.0 (56.70 KB, text/plain)
2016-11-16 14:29 UTC, Davide Pucci
Details
dmesg output on linux 4.8.7 (49.43 KB, text/plain)
2016-11-17 09:52 UTC, Davide Pucci
Details
dmesg output on linux 4.4.0 (57.72 KB, text/plain)
2016-11-17 17:37 UTC, Davide Pucci
Details
alsa-info.sh output on linux 4.8.10 (13.47 KB, text/plain)
2016-11-30 08:54 UTC, Davide Pucci
Details
dmesg output on linux 4.8.10 (37.31 KB, text/x-log)
2016-11-30 08:55 UTC, Davide Pucci
Details
dmesg output on linux 4.8.11 (37.75 KB, text/plain)
2016-12-05 08:05 UTC, Davide Pucci
Details
alsa-info.sh output on linux 4.8.11 (13.49 KB, text/plain)
2016-12-05 08:07 UTC, Davide Pucci
Details
alsa-info.sh output on linux 4.8.12 (patched) (13.47 KB, text/plain)
2016-12-10 10:42 UTC, Davide Pucci
Details
dmesg output on linux 4.8.12 (patched) (37.31 KB, text/plain)
2016-12-10 10:42 UTC, Davide Pucci
Details
acpidump (91.82 KB, text/plain)
2016-12-10 10:42 UTC, Davide Pucci
Details
dmesg output on linux 4.9.0 (experimental/codecs) (64.36 KB, text/plain)
2016-12-14 20:18 UTC, Davide Pucci
Details
alsa-info.sh output on linux 4.9.0 (experimental/codecs) (107.46 KB, text/plain)
2016-12-14 20:18 UTC, Davide Pucci
Details
pulseaudio on linux 4.9.0 (experimental/codecs) (207.49 KB, text/x-log)
2016-12-15 09:10 UTC, Davide Pucci
Details
pulseaudio on linux 4.9.0 (experimental/codecs) #2 (13.51 KB, text/plain)
2016-12-15 15:08 UTC, Davide Pucci
Details
pulseaudio on linux 4.9.0 (experimental/codecs) #3 (78.84 KB, text/plain)
2016-12-15 19:09 UTC, Davide Pucci
Details
pulseaudio on audio switch on linux 4.9.0 (experimental/codecs) (210.40 KB, text/plain)
2016-12-15 23:57 UTC, Davide Pucci
Details
dmesg output on switch audio on linux 4.9.0 (experimental/codecs) (1008.13 KB, text/plain)
2016-12-15 23:59 UTC, Davide Pucci
Details
Working audio stuff on 4.4.x (ubuntu based) (11.99 KB, application/gzip)
2016-12-16 11:05 UTC, Davide Pucci
Details
Working pulseaudio on 4.4.x (ubuntu based) (211.26 KB, text/plain)
2016-12-16 13:24 UTC, Davide Pucci
Details
Diff between working Pulseaudio and not working (39.70 KB, text/plain)
2016-12-16 16:09 UTC, Davide Pucci
Details
asound.state patch from the one from stock (not-working) to working one (39.17 KB, patch)
2016-12-17 13:29 UTC, Davide Pucci
Details | Diff
pulseaudio on linux 4.9.0 (experimental/codecs) #4 (206.93 KB, text/plain)
2016-12-29 19:00 UTC, Davide Pucci
Details
pulseaudio on linux 4.9.0 (experimental/codecs) #5 (208.92 KB, text/plain)
2016-12-29 23:26 UTC, Davide Pucci
Details
modified UCM file to set Intel DSP mixers (7.27 KB, text/plain)
2017-01-03 21:12 UTC, Pierre Bossart
Details
pulseaudio on linux 4.9.0 (experimental/codecs) #6 (81.31 KB, text/plain)
2017-01-04 09:26 UTC, Davide Pucci
Details
alsa-info with custom kernel and without pusleaudio (112.86 KB, application/octet-stream)
2017-01-14 21:09 UTC, Nicolas Porcel
Details
Fix byt-max98090 fix for kernel >= 4.5 (1.54 KB, patch)
2017-02-01 22:54 UTC, Nicolas Porcel
Details | Diff
asound.state for byt-max98090 (27.36 KB, application/octet-stream)
2017-02-01 22:55 UTC, Nicolas Porcel
Details
alsa-info.sh output 4.9.6 patched (16.99 KB, application/octet-stream)
2017-02-02 13:29 UTC, Fabrizio Pietrucci
Details
attachment-6285-0.html (2.32 KB, text/html)
2017-02-18 20:36 UTC, Vinod Koul
Details
Patch to allow to build both old and new BYT drivers (5.06 KB, patch)
2017-02-25 15:51 UTC, Takashi Iwai
Details | Diff

Description Davide Pucci 2016-11-14 10:03:37 UTC
Audio device not recognized on Toshiba Chromebook 2, shipping with a Intel Bay Trail chipset.
Not working since Linux 4.5, currently on 4.8.6, on every distribution I currenty tried.

Thank  you.
Comment 1 Takashi Iwai 2016-11-14 10:13:01 UTC
Did it work with 4.4 kernel?  There hasn't been so much change about HD-audio functionality recently.  If any, it's likely in other components.

In anyway, give alsa-info.sh outputs on both working (4.4?) and non-working (the recent one) kernels.  Run the script with --no-upload option and attach the outputs.
Comment 2 Davide Pucci 2016-11-14 11:18:32 UTC
Created attachment 244401 [details]
alsa-info.sh output on linux 4.8.6

As requested, alsa-input.sh output run on a linux 4.8.6 installation.
Comment 3 Takashi Iwai 2016-11-14 12:35:40 UTC
The more important bit is the output from the working (4.4.x) kernel.
Comment 4 Davide Pucci 2016-11-16 14:29:48 UTC
Created attachment 244781 [details]
alsa-info.sh output on linux 4.4.0

As requested, alsa-input.sh output run on a linux 4.4.0 installation.
Comment 5 Takashi Iwai 2016-11-16 16:32:16 UTC
Thanks.

So the analog audio part has never been HD-audio.  The HDMI part is HD-audio, but others aren't.  It's Intel ASoC driver, and that seems to get a regression after 4.4.

Vinod, is this something for you?
Comment 6 Vinod Koul 2016-11-17 03:08:26 UTC
can you please send me dmesg after boot. I think some of Pierre's changes made the older byt driver deprecated so audio doesn't work anymore.
Comment 7 Davide Pucci 2016-11-17 09:52:36 UTC
Created attachment 244871 [details]
dmesg output on linux 4.8.7

As requested, boot log over a 4.8.7 installation. Do you need also the one from the 4.4.X?
Comment 8 Davide Pucci 2016-11-17 17:37:00 UTC
Created attachment 244891 [details]
dmesg output on linux 4.4.0

It has not been explicitly requested, but here you have dmesg on 4.4.0.
Comment 9 Davide Pucci 2016-11-28 11:06:08 UTC
Nothing new about this one?
Comment 10 Pierre Bossart 2016-11-29 17:55:14 UTC
the information you provided is somewhat inconsistent

in the 4.4 alas-info.sh, one can see that snd_soc_sst_byt_max98090_mach is loaded - this is encouraging since it's a known hardware setting that has worked for quite some time. In 4.8.6 it is not so you probably didn't have the right KConfig settings and dmesg shows a realtek ALC-892 codec (which makes no sense)

There is a known problem to handle this configuration with the 'regular' atom/sst driver without any config hacks but the code is still there and you can enable byt-max98090 in all existing kernels, see http://lxr.free-electrons.com/source/sound/soc/intel/Kconfig#L111
Comment 11 Davide Pucci 2016-11-30 08:54:25 UTC
Created attachment 246391 [details]
alsa-info.sh output on linux 4.8.10

Executed alsa-info.sh on a 4.8.10 installation, with SND_SOC_INTEL_BYT_MAX98090_MACH enabled.
Comment 12 Davide Pucci 2016-11-30 08:55:15 UTC
Created attachment 246401 [details]
dmesg output on linux 4.8.10

Executed dmesg on a 4.8.10 installation, with SND_SOC_INTEL_BYT_MAX98090_MACH enabled.
Comment 13 Pierre Bossart 2016-11-30 14:26:04 UTC
from dmesg I see that the codec driver is loaded but the machine driver isn't found.

Can you double check that the config allows for the CONFIG_SND_SST_IPC_ACPI config as well

http://lxr.free-electrons.com/source/sound/soc/intel/common/sst-acpi.c#L218
Comment 14 Davide Pucci 2016-12-03 13:51:04 UTC
I can confirm that variable was correctly configured as CONFIG_SND_SST_IPC_ACPI=m.
Comment 15 Davide Pucci 2016-12-05 08:05:14 UTC
Created attachment 246861 [details]
dmesg output on linux 4.8.11

dmesg output on linux 4.8.11, with CONFIG_SND_SST_IPC_ACPI=m.
Comment 16 Davide Pucci 2016-12-05 08:07:08 UTC
Created attachment 246871 [details]
alsa-info.sh output on linux 4.8.11
Comment 17 Pierre Bossart 2016-12-05 14:33:32 UTC
alas-info.sh shows you are still using the new set driver: snd_soc_sst_mfld_platform

This codec is not yet supported with the new driver and you need to use the older one. It looks like your Kconfig are not right.
Comment 18 Davide Pucci 2016-12-05 15:34:55 UTC
Is it a matter of time for it to be supported along with the new driver?
What do you suggest?
Comment 19 Pierre Bossart 2016-12-05 15:50:44 UTC
There is already the cht_max98090 driver which is mostly compatible, it just needs to be modified to enable the MCLK for Baytrail which is the only hardware difference.it's a couple of hours tops but people who know how to do it don't have hardware to test.
Comment 20 Takashi Iwai 2016-12-09 13:32:03 UTC
We can try to bind just with the existing cht_max98090 driver as a start.

Davide, could you give the ACPI dump?  You can find it in /sys/firmware/acpi/tables/*, too.
Comment 21 Takashi Iwai 2016-12-09 13:37:57 UTC
(In reply to Takashi Iwai from comment #20)
> We can try to bind just with the existing cht_max98090 driver as a start.

I meant some thing like below.  At least we can check whether the binding works.

--- a/sound/soc/intel/atom/sst/sst_acpi.c
+++ b/sound/soc/intel/atom/sst/sst_acpi.c
@@ -445,6 +445,8 @@ static struct sst_acpi_mach sst_acpi_bytcr[] = {
                                                &byt_rvp_platform_data },
        {"10EC5651", "bytcr_rt5651", "intel/fw_sst_0f28.bin", "bytcr_rt5651", NULL,
                                                &byt_rvp_platform_data },
+       {"193C9890", "cht-bsw-max98090", "intel/fw_sst_0f28.bin", "cht-bsw", NULL,
+                                               &byt_rvp_platform_data },
        {},
 };
Comment 22 Pierre Bossart 2016-12-09 15:46:21 UTC
see my branch on github, it does what Takashi suggested and add support for the MCLK that's needed on Baytrail. in theory you should have sound with that if you set the mixers right

https://github.com/plbossart/sound/tree/experimental/codecs

The branch name means it's compile-tested only and not run on any platform. standard disclaimers apply.
Comment 23 Davide Pucci 2016-12-10 10:42:10 UTC
Created attachment 247361 [details]
alsa-info.sh output on linux 4.8.12 (patched)
Comment 24 Davide Pucci 2016-12-10 10:42:26 UTC
Created attachment 247371 [details]
dmesg output on linux 4.8.12 (patched)
Comment 25 Davide Pucci 2016-12-10 10:42:39 UTC
Created attachment 247381 [details]
acpidump
Comment 26 Davide Pucci 2016-12-10 10:42:54 UTC
Is this [https://github.com/plbossart/sound/commit/768974414bad9c49dae8215ed7be89754031e640] the commit you're talking about? Currently applied it without any success (attachments dedicated for both dmesg and alsa-info).

Anyway, for Takashi, attached acpidump's output.
Comment 27 Davide Pucci 2016-12-13 11:06:16 UTC
Nothing new?
Comment 28 Pierre Bossart 2016-12-13 14:39:39 UTC
please take the entire branch instead of cherry-picking
Comment 29 Davide Pucci 2016-12-14 20:18:11 UTC
Created attachment 247631 [details]
dmesg output on linux 4.9.0 (experimental/codecs)
Comment 30 Davide Pucci 2016-12-14 20:18:43 UTC
Created attachment 247641 [details]
alsa-info.sh output on linux 4.9.0 (experimental/codecs)
Comment 31 Davide Pucci 2016-12-14 20:19:22 UTC
Ok, as you can see, something more promising using the whole branch by Pierre.
Any tip, now?
Comment 32 Pierre Bossart 2016-12-14 21:35:00 UTC
Very cool, thanks for testing.

Now the problem is no longer a kernel issue but a mixer configuration, the 'no backend' thing is normal since the DSP mixers aren't set by default.

Since you are using PulseAudio the best is to create a UCM file.

I can do it for you quickly if you share the mixer settings you used for the different inputs and outputs with the previous driver. 

Or if you are daring and willing to learn you can copy/paste the bytcr-rt5640 directory and modify as needed, only keeping the initial part of the HiFi file for the Intel DSP mixer. see https://github.com/plbossart/UCM/tree/master/byt-rt5640
Comment 33 Davide Pucci 2016-12-14 22:44:32 UTC
It's totally new stuff for me, so I think I'll accept your offer to quickly do it for me. :)
What do you need me to share with you? On which platform? With 'previous driver' you mean the one working (used on 4.4.x), or the updated not working one (used on 4.8.x)?

Thank you for your help, really appreciated!
Comment 34 Pierre Bossart 2016-12-14 22:49:36 UTC
what mixer settings did you use in the previous setup? do you have a file used to initialize the mixers?
Comment 35 Pierre Bossart 2016-12-14 22:52:04 UTC
alternatively there are mixer settings here
https://chromium.googlesource.com/chromiumos/third_party/adhd/+/a32d5028fd2f149e8221e76e4d0699135073803d/ucm-config/rambi/byt-max98090/HiFi.conf
that could be used.

I don't know how different the devices are.
Comment 36 Davide Pucci 2016-12-14 22:54:02 UTC
Sincerely don't know. Previously I needed to patch alsa this way: https://plus.google.com/+JamesFuBEEFCAKE/posts/Tf4Pc5Z8reH .
Comment 37 Pierre Bossart 2016-12-14 23:10:00 UTC
I am afraid there is no generic solution since there are dozens of devices using the same audio hardware but having different settings. 

ChromeOS folks publish all their UCM files here
git clone https://chromium.googlesource.com/chromiumos/third_party/adhd

your 'swanky' device is no longer maintained in ucm-configs, but you can find the data in older branches (git branch -r | grep swanky)

You would need to take this swanky directory, change the name to chtmax98090 and edit the file as needed to reflect changes in mixer names since 2014. You would also need to add the mixers for the DSP (taken from my ucm files)

Once you are done copy the directory to /usr/share/alsa/ucm

It's not complicated but it's painful.
Comment 38 Pierre Bossart 2016-12-14 23:35:32 UTC
well I am too nice so here's a tentative solution

https://github.com/plbossart/UCM/commits/rambi

take the chtmax98090 directory and copy it in /usr/share/alsa/ucm

There are a set of #FIXME that can be dealt with later.

The mixer names may have changed but you'll have to log with pulse audio -vvv which ones fail.
Comment 39 Davide Pucci 2016-12-15 09:10:56 UTC
Created attachment 247671 [details]
pulseaudio on linux 4.9.0 (experimental/codecs)

Thank you for the hints, Pierre.
Now all the interfaces are correctly recognized by the whole system, but still unable to produce sounds.

Actually, it seems that few missing configurations files and instructions in your HiFi.conf do not permitt to correctly load all the configurations you provided.
I faced errors as these ones:
> I: [pulseaudio] (alsa-lib)parser.c: error: could not parse configuration for
> card HDA Intel PCH
> I: [pulseaudio] (alsa-lib)main.c: error: failed to import HDA Intel PCH use
> case configuration -2
[...]
> I: [pulseaudio] (alsa-lib)pcm_hw.c: open '/dev/snd/pcmC0D0c' failed (-2)
> I: [pulseaudio] alsa-util.c: Error opening PCM device hw:0: File o directory
> non esistente
[...]
> I: [pulseaudio] (alsa-lib)main.c: unable to execute cset 'name='HP Left Out
> Switch' off'
> I: [pulseaudio] (alsa-lib)main.c: error: failed to initialize new use case:
> HiFi
> E: [pulseaudio] alsa-ucm.c: Failed to get the verb HiFi
> E: [pulseaudio] alsa-ucm.c: No UCM verb is valid for chtmax98090

Complete log attached.
Comment 40 Pierre Bossart 2016-12-15 13:36:06 UTC
the first part is fine, it'll fallback to normal mode without UCM for HDMI output.

The error I: [pulseaudio] (alsa-lib)main.c: unable to execute cset 'name='HP Left Out Switch' off' is likely due to a control that has changed. You will need to run 
amixer -Dchtmax98090 controls | grep Switch and figure out if this control was renamed or removed. You may need to look at the source code.

If you have a single error then UCM stops, that's not right but that's how it is today.
Comment 41 Takashi Iwai 2016-12-15 13:44:26 UTC
Yeah, UCM parser can be more tolerant.  Below patch to alsa-lib should improve the behavior.

--- a/src/ucm/main.c
+++ b/src/ucm/main.c
@@ -436,7 +436,7 @@ static int execute_sequence(snd_use_case_mgr_t *uc_mgr,
 			err = execute_cset(ctl, s->data.cset, s->type);
 			if (err < 0) {
 				uc_error("unable to execute cset '%s'\n", s->data.cset);
-				goto __fail;
+				/* goto __fail; */
 			}
 			break;
 		case SEQUENCE_ELEMENT_TYPE_SLEEP:
Comment 42 Davide Pucci 2016-12-15 15:08:01 UTC
Created attachment 247711 [details]
pulseaudio on linux 4.9.0 (experimental/codecs) #2

Pulseaudio logged with latest kernel, alsa-lib with latest patch you provided.
Actually, no more audio interfaces detected by system.
Comment 43 Pierre Bossart 2016-12-15 17:22:56 UTC
This is getting hairy.
The only difference I see with other UCM files is that it's missing

Value {
		CaptureChannels 2
	}

Value {
		PlaybackChannels 2
	}


Maybe look at the examples from bytcr_rt5640 and try out.
Comment 44 Davide Pucci 2016-12-15 19:09:17 UTC
Created attachment 247741 [details]
pulseaudio on linux 4.9.0 (experimental/codecs) #3

Ok, actually I think it's the best configuration I could apply.
So: 
> taken UCM files from chromium source code
> (https://chromium.googlesource.com/chromiumos/third_party/adhd/+/f11e4d0d1e288faa3635203c9ebf9891008e4802/ucm-config/swanky/byt-max98090)
> taken asound.state from confirmed working area
> (https://github.com/fascinatingcaptain/CBFixesAndTweaks/blob/master/asound.state)

Even the pulseaudio log seems to be little bit cleaner, but actually still no sounds (but interfaces are correctly recognized systemwide).
Comment 45 Pierre Bossart 2016-12-15 19:48:16 UTC
did you go in the sound control panel and select the speaker output? Can you provide pulse audio and dmesg logs when you do so?
Comment 46 Davide Pucci 2016-12-15 23:57:33 UTC
Created attachment 247761 [details]
pulseaudio on audio switch on linux 4.9.0 (experimental/codecs)
Comment 47 Davide Pucci 2016-12-15 23:59:15 UTC
Created attachment 247771 [details]
dmesg output on switch audio on linux 4.9.0 (experimental/codecs)
Comment 48 Davide Pucci 2016-12-15 23:59:34 UTC
Here you have them, my dear.
Comment 49 Pierre Bossart 2016-12-16 01:22:50 UTC
I don't know how you enabled all these logs in dmesg, it's quite verbose.
It's really hard to test remotely. The only advice I can give at this point is to recheck the UCM configuration. If there are some switches that weren't understood by alsamixer maybe the controls were renamed and the output is still switched off? 
You could also try to load the previous alsa state to see if this makes a difference and actually you can do a diff: dump the state in a file, load the previous one see if it works and dump the state again in another file so that we can see what changed.
Comment 50 Davide Pucci 2016-12-16 11:05:00 UTC
Created attachment 247821 [details]
Working audio stuff on 4.4.x (ubuntu based)

This package contains stuff as UCM configuration files and asound.state files from a audio-working 4.4.x installation.
Actually, as you can see, in UCM we don't see any max98090 associated config.
Comment 51 Davide Pucci 2016-12-16 13:24:55 UTC
Created attachment 247841 [details]
Working pulseaudio on 4.4.x (ubuntu based)

Also, here you have a working pulseaudio instance, on the same installation.
Comment 52 Pierre Bossart 2016-12-16 14:24:43 UTC
i am not able to tell you what's wrong based on the entire asound.state, you'd have to provide the difference between what worked and what doesn't to guide the discussion. I don't have any data to work from at the moment.
Comment 53 Davide Pucci 2016-12-16 16:09:52 UTC
Created attachment 247851 [details]
Diff between working Pulseaudio and not working

I just understood that modifying asound.state will not help us (that specific asound.state is needed to get speakers working, every other function should be working out-of-box).

Attached you can read about the lines involved in the diff between pulseaudio on not-working installation (4.9.0, first comparing element) and the one on working installation (4.4.x, latter comparing element).

Let me know if you find something more useful than I do.
Thank you :)
Comment 54 Pierre Bossart 2016-12-16 19:09:01 UTC
no I was talking about the differences in asound.state, what mixer values are changed and what do they impact.
Comment 55 Davide Pucci 2016-12-17 13:29:15 UTC
Created attachment 247931 [details]
asound.state patch from the one from stock (not-working) to working one

As I really do not understand how these things work, neither do know how to interpret this patch. Your help would be really appreciated, as till now.
Comment 56 Pierre Bossart 2016-12-19 16:19:17 UTC
the patch is totally cryptic to me as well. The problem is that the controls are renumbered and we are not comparing the same states. It's a generic problem I have with asound.state is that I'd like to see the difference between default values and things that have been set-up explicitly (in short having a diff state would be a lot more useful).
Comment 57 Davide Pucci 2016-12-19 16:40:37 UTC
The problem is that the working asound.state is currently taken from ChromeOS, not from someone who additions upon it, so I have no idea how to do it.
Comment 58 Davide Pucci 2016-12-22 23:15:39 UTC
Hey Pierre. You currently made lot of stuff to help me figuring out to solve problems, making me reach important steps into fixing audio.
Two questions and I'll let you be free:
1. Will your kernel changes (the ones from experimental/codecs) ever be included in official mainstream branch?
2. Do you know someone to address me to, that can help me to fix last things with UCM/asound.state and whatever else is needed to be touched?
Comment 59 Davide Pucci 2016-12-29 11:28:27 UTC
Ping...
Comment 60 Fabrizio Pietrucci 2016-12-29 11:34:02 UTC
Hi i'm on 4.4.0. If you need, I can do any test you currently need to debug what ever is wrong with new kernel versions.
Waiting for updates. :)
Comment 61 Davide Pucci 2016-12-29 13:15:19 UTC
Thank you, Fabrizio.

Pierre, just to know: what is the pro to switch to the CHR driver, instead of the old - and working - BYT one? Why changing to the CherryTrail's one, on a BayTrail chipset?
Comment 62 Pierre Bossart 2016-12-29 15:41:35 UTC
The old driver is not compatible with the new one, and that means the old one is disabled in most distributions now. So you can keep the old as long as you manually run make menuconfig at every release. 
Or you can help us remove this legacy so that audio just works with the new driver and you can can move on with your hardware natively supported.
Comment 63 Davide Pucci 2016-12-29 15:49:27 UTC
OK, then. I'm available to do whatever you want me to check, using your 'experimental/codecs' branch.
I think Fabrizio, could help us on the other side getting informations on a working environment.

Let us know what you need.
Comment 64 Davide Pucci 2016-12-29 19:00:03 UTC
Created attachment 249181 [details]
pulseaudio on linux 4.9.0 (experimental/codecs) #4

Actually pulled another pulseaudio daemon start log, in the following environment:
 - kernel 4.9.0 (from Pierre's branch experimental/codecs)
 - chtmax98090's UCM (pulled from https://chromium.googlesource.com/chromiumos/third_party/adhd/+/214263e2eb29f8a003876a4b2dbe17e6ca5d62cf/ucm-config/swanky/byt-max98090/HiFi.conf, changing 'cdev "hw:bytmax98090"' with 'cdev "hw:chtmax98090"')
 - /etc/modprobe.d/alsa-base.conf, where inserted 'options snd_hda_intel index=1,0' to set chtmax98090 as primary audio device.

Also, I must say: when I attach headphones, I'm currently able to listen something like a little noise. Also when I play with 'alsamixer' command, unmuting random stuff, I can listen again noises both from the speaker and the headphones and from the mic on the headphones.

Can you please take a look at it, Pierre?
Comment 65 Pierre Bossart 2016-12-29 22:47:21 UTC
(In reply to Davide Pucci from comment #64)
> Created attachment 249181 [details]
> pulseaudio on linux 4.9.0 (experimental/codecs) #4
> 
> Actually pulled another pulseaudio daemon start log, in the following
> environment:
>  - kernel 4.9.0 (from Pierre's branch experimental/codecs)
>  - chtmax98090's UCM (pulled from
> https://chromium.googlesource.com/chromiumos/third_party/adhd/+/
> 214263e2eb29f8a003876a4b2dbe17e6ca5d62cf/ucm-config/swanky/byt-max98090/HiFi.
> conf, changing 'cdev "hw:bytmax98090"' with 'cdev "hw:chtmax98090"')
>  - /etc/modprobe.d/alsa-base.conf, where inserted 'options snd_hda_intel
> index=1,0' to set chtmax98090 as primary audio device.
> 
> Also, I must say: when I attach headphones, I'm currently able to listen
> something like a little noise. Also when I play with 'alsamixer' command,
> unmuting random stuff, I can listen again noises both from the speaker and
> the headphones and from the mic on the headphones.
> 
> Can you please take a look at it, Pierre?

the UCM file I generated is pretty much the same as the one from Chromium, but with different settings for the Intel DSP mixers. Did you look at the differences? I remember there was a change at some point with switch off becoming switch on...
Comment 66 Davide Pucci 2016-12-29 23:26:47 UTC
Created attachment 249221 [details]
pulseaudio on linux 4.9.0 (experimental/codecs) #5

Ok, retried with your UCM config: now with this I can listen noises even on switching audio interface (between speaker and headset).

Log attached. Do you notice something evidently wrong?
Comment 67 Pierre Bossart 2016-12-30 16:38:04 UTC
It's impossible to debug audio quality issues with logs.

Can you try this:
0. play once with the speakers.
1. save the current asound state. kill pulseaudio (and make sure it doesn't restart with the autospawn disabled in /etc/pulse/client.conf)
2. override the asound state with the previous one from Chrome OS
3. comment out all the codec configuration parts in the UCM file but keep the initial DSP mixers
4. restart pulseaudio and report the changes.
Comment 68 Davide Pucci 2017-01-03 08:23:16 UTC
I think I need your help modifying UCM file. I'm not able to identify which lines to comment out. Thank you!
Comment 69 Pierre Bossart 2017-01-03 21:11:15 UTC
(In reply to Davide Pucci from comment #68)
> I think I need your help modifying UCM file. I'm not able to identify which
> lines to comment out. Thank you!

It's not complicated, just remove everything tied to codec. see attachment.
Comment 70 Pierre Bossart 2017-01-03 21:12:16 UTC
Created attachment 249991 [details]
modified UCM file to set Intel DSP mixers

use asound.state to load the codec parts and see what works.
Comment 71 Davide Pucci 2017-01-04 09:26:03 UTC
Created attachment 250181 [details]
pulseaudio on linux 4.9.0 (experimental/codecs) #6

Commented out the lines you suggested from UCM.
No interface detected due to this failure:
> I: [pulseaudio] alsa-ucm.c: UCM available for card chtmax98090
> I: [pulseaudio] alsa-ucm.c: Set UCM verb to HiFi
> W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or
> 'CaptureChannels'for device Mic, assuming stereo duplex.
> D: [pulseaudio] alsa-ucm.c: No _conflictingdevs for device Mic
> D: [pulseaudio] alsa-ucm.c: No _supporteddevs for device Mic
> W: [pulseaudio] alsa-ucm.c: UCM file does not specify 'PlaybackChannels' or
> 'CaptureChannels'for device Headphone, assuming stereo duplex.
> D: [pulseaudio] alsa-ucm.c: No _conflictingdevs for device Headphone
> D: [pulseaudio] alsa-ucm.c: No _supporteddevs for device Headphone
> I: [pulseaudio] module-alsa-card.c: Found UCM profiles
> E: [pulseaudio] alsa-ucm.c: No sink and source at HiFi: Mic
> E: [pulseaudio] alsa-ucm.c: No sink and source at HiFi: Headphone

Extended log attached.

Used both asound.state from ChromeOS and from my distro.
Comment 72 Pierre Bossart 2017-01-04 16:04:44 UTC
just look at the example here https://github.com/plbossart/UCM/blob/master/bytcr-rt5640/HiFi
and add the values for PlaybackChannels and CaptureChannels
Comment 73 Davide Pucci 2017-01-05 11:20:03 UTC
Tried: still no luck, not working.
Comment 74 Fabrizio Pietrucci 2017-01-05 21:35:53 UTC
I installed the patched kernel and tried all the fixes, sound still not working though.
Comment 75 Nicolas Porcel 2017-01-14 21:09:33 UTC
Created attachment 251611 [details]
alsa-info with custom kernel and without pusleaudio

The kernel module seems to work as the card is recognized. Thanks for your work!

I am using alsa without pulseaudio. However, I have 291 controls in alsamixer, and speaker-test doesn't work. I attached the output of alsa-info.sh. I have different errors. For most interfaces, I get:

Unable to set hw params for playback: Invalid argument
Setting of hwparams failed: Invalid argument

For dmix, I get:

ALSA lib pcm_direct.c:1054:(snd1_pcm_direct_initialize_slave) unable to install hw params
ALSA lib pcm_dmix.c:1053:(snd_pcm_dmix_open) unable to initialize slave
Playback open error: -22,Invalid argument

Finally, for dsnoop, I have:
                     
ALSA lib pcm_dsnoop.c:556:(snd_pcm_dsnoop_open) The dsnoop plugin supports only capture stream
Playback open error: -22,Invalid argument

Also, running speaker-test generated some kernel error. I added them at the end of the alsa-info output.
Comment 76 Pierre Bossart 2017-01-16 00:15:51 UTC
the no back-end error is because the DSP mixers are not configured. You need to use the UCM file i provided, use the fix indicated above and help debug the differences with your previous setting.
Comment 77 Davide Pucci 2017-01-20 09:03:17 UTC
Hey Pierre. Just for informational purpose: why on bytmax98090 driver we needed no custom UCM configurations and on chtmax98090 isn't that way?
Comment 78 Pierre Bossart 2017-01-20 14:02:49 UTC
because the older firmware/driver had hard-coded assumptions such as use of SSP2, which precludes its use in platforms where SSP0 is needed. With the new you can do both but need a configuration step.
One might argued that choosing a default would have been nice but that wasn't the case so the configuration is needed.
Comment 79 Nicolas Porcel 2017-02-01 22:54:41 UTC
Created attachment 253811 [details]
Fix byt-max98090 fix for kernel >= 4.5
Comment 80 Nicolas Porcel 2017-02-01 22:55:26 UTC
Created attachment 253821 [details]
asound.state for byt-max98090
Comment 81 Nicolas Porcel 2017-02-01 22:59:00 UTC
It seems that the 4.10 kernel has a regression as I don't have any input / output driver loading, making my chromebook only usable via ssh which is not practical for sound driver debugging. It took me a while to figure out but it's now almost certainly due to the upstream kernel, and thus it affects your experimental/codec branch based on 4.10-rc3. I will submit a proper bug report once I've bisected the source. 
I the meanwhile, I managed to make the old byt-max98090 driver work on a vanilla 4.9.6 kernel (latest stable). I attached the patch and the full asound.state. The speakers, headphone and microphone are working, although the mic has a very poor quality (tested with arecord).
Comment 82 Fabrizio Pietrucci 2017-02-02 13:16:45 UTC
compiled 4.9.6 kernel with patch applied and installed the provided asound.state, audio still not working. The audio interface disappeared again. Am i missing something?
Comment 83 Fabrizio Pietrucci 2017-02-02 13:29:39 UTC
Created attachment 253881 [details]
alsa-info.sh output 4.9.6 patched
Comment 84 Pierre Bossart 2017-02-02 15:02:20 UTC
you are not providing any details on what branch this is so there's no way I can help. use the latest experimental/codecs branch so that I least I know what code this is. The 4.9 branches are for backport of known solutions, not for development.
Comment 85 Fabrizio Pietrucci 2017-02-02 15:14:08 UTC
Read Nicolas' post. I compiled on the stable brach (which i assume corresponds to "vanilla kernel") applying the patch he provided before compiling without any result. More precisely i compiled on elementary os 'Loki' whith the elementary default config for kernel 4.4.
Comment 86 Nicolas Porcel 2017-02-02 17:09:20 UTC
Vanilla kernel is the official kernel source from kernel.org.

@Pierre: I can't use your branch because of the I/O problem I mentioned. I will try again next week, but first I need to find the change that broke the kernel. Also, please note that we are talking about the old driver (byt-max98090). Although I don't know the details of kernel development cycle, I guess this fix is applicable for stable branch of the kernel as this is a regression appearing in kernel 4.5.

@Fabrizio: Same remark, this is the old driver. It is not compatible with sound drivers using the newer driver. For that, you need to disable all other drivers present in "Device Drivers" -> "Sound card support" -> "Advanced Linux Sound Architecture". You can also have a look to my kernel configuration (https://github.com/Nicop06/dotfiles/blob/master/kernel_netbook), especially the section entitled "Common SoC Audio options for Freescale CPUs". Please don't use this configuration directly as its optimized for my laptop to reduce compilation time and thus have most drivers disabled.
Comment 87 Fabrizio Pietrucci 2017-02-03 22:18:28 UTC
I confirm that compiling 4.9.6 stable with the instructions provided by Nicolas brings back the audio. Thank you for your work Nicolas!
Comment 88 Julia Cartwright 2017-02-18 20:26:43 UTC
@Nicolas: if you're running into the same problem I was running into, see commit 49c03096263871a68c9dea3e86b7d1e163d2fba8 upstream to fix it.
Comment 89 Vinod Koul 2017-02-18 20:36:34 UTC
Created attachment 254829 [details]
attachment-6285-0.html

Thanks for your email

I am attending ELC-NA
Please expect delayed response.

Regards
--
~Vinod
Comment 90 Julia Cartwright 2017-02-20 19:26:09 UTC
Okay, I was able to get the codecs/experimental tree booting with the above bay trail fixed (which has sense landed in v4.10).  Then, I placed the HiFi.conf file in /usr/share/alsa/ucm/chtmax98090/HiFi.conf, and made a /usr/share/alsa/ucm/chtmax98090/chtmax908090.conf which lists "HiFi" as a default usecases.  I am able to successfully run 'alsaucm -c chtmax98090 set _verb HiFi', however, I am still unable to get audio from this device.

Attempts to use 'aplay' result in the same error shown above:

ALSA lib pcm_dmix.c:1052:(snd_pcm_dmix_open) unable to open slave
aplay: main:788: audio open error: No such file or directory

Please advise on what the next step might be for debugging this further.  It'd be nice to get this new driver up and working.  On the off chance anyone is at ELC this week, I'll be around with a laptop which has the problem.
Comment 91 Pierre Bossart 2017-02-20 20:53:36 UTC
Vinod is at ELC, hint hint wink wink...

I am supposed to received one of those Rambi devices sometime this month, in the mean time I also need to check how well this driver works with a Cyan CHT-based Chromebook. Maybe there is something wrong with the driver in the first place...
Comment 92 Julia Cartwright 2017-02-24 21:49:53 UTC
Well, I tried to find Vinod at ELC and failed, so any further debugging tips that can help us move forward on this is most appreciated.
Comment 93 Pierre Bossart 2017-02-25 00:08:15 UTC
What would really help is for someone to take the 'old' driver and build a matching UCM file that is known to work for headphone, speaker, headset and internal mic endpoints. I am unable to figure out based on the asound.state what is or is not required to configure the codec and for what endpoint. A shell script is fine as well as long as there are clear indication as to which configuration does what. I created an UCM file based on the ChromeOS reference but I have no idea if it works in the first place.

If/when we have control settings that are known to work, then we can debug clocks/connections settings and make progress. the same settings should work both on Rambi and Cyan since it's the same codec and the hardware configuration is identical (SSP2+I2S 16 bits)
Comment 94 Takashi Iwai 2017-02-25 15:50:14 UTC
For your convenience: the patch below allows to build both the new and the old drivers when you set CONFIG_SND_SOC_INTEL_LEGACY_MACH=y.  By passing snd-soc-sst-dsp.bind_legacy=1 option, the old driver will be bound.  As default when ACPI is set, the new driver is bound.  (Note: only compile-tested, so far!)
Comment 95 Takashi Iwai 2017-02-25 15:51:02 UTC
Created attachment 254917 [details]
Patch to allow to build both old and new BYT drivers
Comment 96 Davide Pucci 2017-03-02 08:00:25 UTC
Hey Takashi, how do I pass "snd-soc-sst-dsp.bind_legacy = 1" option?
Comment 97 Dean 2017-03-13 11:34:10 UTC
(In reply to Takashi Iwai from comment #95)
> Created attachment 254917 [details]
> Patch to allow to build both old and new BYT drivers

Hi.  I'm gonna see if I can build with this patch on my archlinux system, but I noticed a small typo, I assume SND_SOC_TINTEL_BAYTRAIL is supposed to be SND_SOC_INTEL_BAYTRAIL
regards
Comment 98 Dean 2017-03-13 12:38:45 UTC
Failing to patch.  Guess I'm too much kernel noob.
--
patching file sound/soc/intel/Kconfig
Hunk #1 FAILED at 93.
Hunk #2 succeeded at 110 with fuzz 2 (offset 4 lines).
1 out of 2 hunks FAILED -- saving rejects to file sound/soc/intel/Kconfig.rej
--
Comment 99 Dean 2017-04-30 21:33:08 UTC
Ok, I came back to this, finally figured what was wrong.  Compiled a fresh arch kernel with this patch (patched fine, added the new legacy option), compiled ok, installed it, added the snd-soc-sst-dsp.bind_legacy=1 kernel option, rebooted.  Got the same old "dummy output".  Only hdmi detected.  Same problems as with default kernels.

Note You need to log in before you can comment on or make changes to this bug.