Hi,
The Kernel error messages should be related to the Intel DRM graphics, so I don't care about them (at least for now).
Anyway I don't know if tese warning can in some way be related to my problem:
[ 9.565990] rt5651 i2c-10EC5651:00: ASoC: mux INL1 Mux has no paths [ 9.586586] rt5651 i2c-10EC5651:00: ASoC: mux INR1 Mux has no paths [ 9.586596] rt5651 i2c-10EC5651:00: ASoC: mux INL2 Mux has no paths [ 9.586601] rt5651 i2c-10EC5651:00: ASoC: mux INR2 Mux has no paths [ 12.646035] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 0 doesn't have DAPM widget!!! [ 12.649356] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 1 doesn't have DAPM widget!!! [ 12.652673] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 2 doesn't have DAPM widget!!! [ 12.656323] sst-mfld-platform sst-mfld-platform: Slot control: codec_out tx interleaver slot 3 doesn't have DAPM widget!!! [ 12.659868] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_0 doesn't have DAPM widget!!! [ 12.663456] sst-mfld-platform sst-mfld-platform: Slot control: codec_in rx deinterleaver codec_in0_1 doesn't have DAPM widget!!!
-------------
For your convenience I've extracted the DSDT from Android and Linux, because they seem to differ. Here they are:
DSDT Linux: http://paste.ubuntu.com/16885538/ DSDT Android: http://paste.ubuntu.com/16885557/
And this is the dmesg from android: http://pastebin.com/nY5mtW76
Here are the Firmware Blobs I'm currently using: http://pastebin.com/UKN0c0as (Fw listing) https://drive.google.com/file/d/0By5f76WVVa0Eb3RacGZRbzNGeFU/view?usp=sharin... (Fw blobs)
When I'll return home I'll try to record and play and let you know.
Thanks, Pietro
On Tuesday 31 May 2016 17:26:30 Pierre-Louis Bossart wrote:
On 5/31/16 3:56 PM, Pietro wrote:
Hi, Here are the answers:
- tracing to make sure you are actually on a CHT device The device should be CHT (The processor is an Atom X3-Z8300). Can it be that the processor is an X3 series, but the platform is BT and not a CHT? I know many manifacturers simply upgraded their notebooks series from BT to CHT by changing the CPU and mantaining all the other components the same (For example the Audio codec). How can I trace this?
you see a lot of references to cherrytrail-cr and 22A8, the right ID.
- pastebin dmesg somewhere Here is it: http://pastebin.com/FnpAD1kg
You have lots of errors or warnings in there. Not sure why, i have machines that don't behave as badly.
I am not sure why using the CHT firmware leads to an error, somehow you probably have a combination of issues. I would really start there, if the regular firmware doesn't work for you something is very wrong.
- sudo cat /sys/bus/acpi/devices/10EC5651:01/status Here are the results: /sys/bus/acpi/devices/10EC5651:00/status Returns 15
this matches what the machine driver expects so that's good.
/sys/bus/acpi/devices/10EC5651:01/status Returns 0
- enabling DSP loopbacks to see if the DSP consumes data at the right rate. look at the UCM file and change cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on if you record and loopback on USB output this should play at the right speed. I've changed the value in the HiFi file, but no changes. How can i enable DSP loopbacks? I'm not an alsa developer so I need some help here :)
you need to record to enable the loopback while you play...
Please let me know if you need other informations.
can you extract the DSDT and pastebin it as well?
On Tuesday 31 May 2016 15:27:45 Pierre-Louis Bossart wrote:
the changes look ok
But I still have the same problem: Audio plays slowly.
It seems the DSP is clocked at 19.2, but the system is still clocked for 25, and these changes doesn't seem to have effects...
no, CHT doesn't have a 25 MHz clock at all so that's just not physically possible.
Can you try:
- tracing to make sure you are actually on a CHT device
- pastebin dmesg somewhere
- sudo cat /sys/bus/acpi/devices/10EC5651:01/status
- enabling DSP loopbacks to see if the DSP consumes data at the right
rate. look at the UCM file and change cset "name='pcm1_out mix 0 pcm0_in Switch' off" to on if you record and loopback on USB output this should play at the right speed.
Alsa-devel mailing list Alsa-devel@alsa-project.org http://mailman.alsa-project.org/mailman/listinfo/alsa-devel