Created attachment 295009 [details] dmesg output from HP Pro Tablet 408 I have a HP Pro Tablet 408 running Arch Linux. It has a 32 bit EFI but a 64 bit baytrail CPU Z3736F I have set up the tablet with a 32bit grub to boot a 64bit kernel. Secureboot is switched off in the BIOS. Currently I do not have working audio or cameras on this device but everything else appears to work. I'm more concerned about getting audio working though. I originally submitted a bug to pipewire at https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/648 But I now believe this could be a issue with the drivers. Trying this following quirk snd_soc_sst_bytcr_rt5640.quirk=0x502f30 got my microphone to work but nothing else. Attached is a dmesg output I grabbed before running with any quirks for the audio enabled. I also noticed in dmesg a crash that seems to be also related?
*** Bug 211481 has been marked as a duplicate of this bug. ***
*** Bug 211483 has been marked as a duplicate of this bug. ***
I'm sorry for the other two bug reports I made. I accidentally got them submitted before I was able to fill out all the information I wanted to.
I found the quirk I mentioned above from https://bugzilla.redhat.com/show_bug.cgi?id=1896924
Created attachment 295049 [details] Dmesg with quirk 0x502f30 enabled Per request of someone from ##linux channel on Freenode IRC I took this dmesg log from when I had the quirk enabled that got the microphone working.
Just some notes... source file: sound/soc/intel/boards/bytcr_rt5640.c 0x502f30 is: 10100000010111100110000 (bit 0 is rightmost, in above) bits set(aka 1): 4,5,8,9,10,11,13,20,22 bit 4(1) and 5(1) aka value 3 (decimal) is BYT_RT5640_JDSRC(quirk) (((quirk) & GENMASK(7, 4)) >> 4) aka jack-detect-source 3 bit 8,9,10,11 is BYT_RT5640_OVCD_TH_1500UA aka over-current-threshold-microamp 1500 bit 13 is BYT_RT5640_OVCD_SF_1P0 aka over-current-scale-factor 1 bit 20 is BYT_RT5640_SSP0_AIF1 aka SSP0_AIF1 bit 22 is BYT_RT5640_MCLK_EN aka MCLK_EN [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=baa2a9e6-8872-4e7f-9887-bf1d30be905f rw loglevel=3 quiet snd_soc_sst_bytcr_rt5640.quirk=0x502f30 ... [ 7.112862] bytcr_rt5640 bytcr_rt5640: Overriding quirk 0x643423 => 0x502f30 [ 7.112917] bytcr_rt5640 bytcr_rt5640: quirk DMIC1_MAP enabled [ 7.112922] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 3 [ 7.112926] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 1500 [ 7.112929] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1 [ 7.112932] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF1 enabled [ 7.112935] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled --------------- your default 0x643423 is: 11001000011010000100011 bits set(aka 1): 0,1,5,10,12,13,18,21,22 bit 0 and 1 is probably BYT_RT5640_IN3_MAP which would be value 3(decimal, 11 binary) aka BYT_RT5640_MAP(quirk) ((quirk) & GENMASK(3, 0)) bit 4(0) and 5(1) aka value 2 (decimal) is BYT_RT5640_JDSRC(quirk) (((quirk) & GENMASK(7, 4)) >> 4) aka jack-detect-source 2 bit 10 and 12 are BYT_RT5640_OVCD_TH_2000UA = (20 << 8), aka 20*2^8 aka over-current-threshold-microamp 2000 bit 13 is BYT_RT5640_OVCD_SF_1P0 aka over-current-scale-factor 1 bit 18 BYT_RT5640_DIFF_MIC BIT(18) /* default is single-ended */ aka DIFF_MIC bit 21 is BYT_RT5640_SSP0_AIF2 aka SSP0_AIF2 bit 22 is BYT_RT5640_MCLK_EN aka MCLK_EN [ 0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux root=UUID=baa2a9e6-8872-4e7f-9887-bf1d30be905f rw loglevel=3 quiet ... [ 7.200047] bytcr_rt5640 bytcr_rt5640: quirk IN3_MAP enabled [ 7.200054] bytcr_rt5640 bytcr_rt5640: quirk realtek,jack-detect-source 2 [ 7.200058] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-threshold-microamp 2000 [ 7.200061] bytcr_rt5640 bytcr_rt5640: quirk realtek,over-current-scale-factor 1 [ 7.200064] bytcr_rt5640 bytcr_rt5640: quirk DIFF_MIC enabled [ 7.200068] bytcr_rt5640 bytcr_rt5640: quirk SSP0_AIF2 enabled [ 7.200071] bytcr_rt5640 bytcr_rt5640: quirk MCLK_EN enabled
Created attachment 295051 [details] dmesg with quirk 0x522F30 Someone suggested on IRC I try the quirk 0x522F30 and that made it seem there was a "mono speaker" but sound still did not work. Microphone still worked though. Here is the dmesg from that.
(In reply to Adjudicator Darren from comment #6) > Just some notes... > > source file: sound/soc/intel/boards/bytcr_rt5640.c > > > > 0x502f30 is: > > 10100000010111100110000 oh so that's translated to the binary and then you look at the bits. I get it now. I'm still not sure which combo would work though
ok good news, after some messing around the quirk snd_soc_sst_bytcr_rt5640.quirk=0x502f30 does work for me to get audio and microphone working. My system seems to suffer the same issues described over here https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/530 If audio isn't playing at s16le format then I hear nothing. Does anyone know what this means exactly? Can the bytcr_rt5640 module not handle anything other than s16le formatting for audio? Or is there a quirk setting I'm overlooking that could help with this? And this might be for a different bug report but I'm curious to know what's causing that crash message I see in the dmesg logs I have reported. The system seems to continue to run despite it. Seems to be referring to the hdmi audio output.
(In reply to Adjudicator Darren from comment #6) > Just some notes... > > source file: sound/soc/intel/boards/bytcr_rt5640.c Ok my system updated to kernel 5.10.15 and I have a new issue. The sound works but I no longer have the microphone working. I haven't changed the quirk in use. I also noticed there is no crash message in dmesg like before. Do you or anyone here happen to know what exactly changed in the kernel?
Created attachment 295213 [details] new dmesg from 5.10.15 kernel This is the dmesg from my system now updated to kernel 5.10.15 Linux hp-408-g1 5.10.15-arch1-1 #1 SMP PREEMPT Wed, 10 Feb 2021 18:32:40 +0000 x86_64 GNU/Linux
Updated the bug report to reflect being on 5.10.15 since the issues have now changed on the newer kernel.
Hi, I came here from your pipewire bugreport. I'm an upstream kernel dev who has been doing hw-enablement work on Bay Trail based devices for the last couple of years now as a side-project, including getting audio to work. So what needs to happen here from the kernel side, is find the correct quirk settings and then add a quirk to the kernel to automatically use that quirk on your model in the future. If you look here: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/sound/soc/intel/boards/bytcr_rt5640.c You will see I've some experience in this area :) The reason why I found your pipewire bug-report is because I have been testing Bay Trail audio with pipewire this weekend and there are several issues there. I was looking for duplicate bugs before filing a bug against pipewire for this. So the first thing you should do is change back to pulseaudio for now, otherwise we are debugging 2 things at once which is not a good idea. After this we need to figure out the right quirk for your device, with which you already have made a good start. First of all, you changed the middle 2 digits from their default value of 34 to 2f. These 2 digits control the OVCD values which are used to differentiate between a headset (so a jack plug with 4 contacts, with mic) and headphones (3 contacts, no mic) being plugged in and to detect the play/pause button being pressed on headsets. The defaults are almost always the best values here. For further testing please use: .quirk=0x503430 Finding / verifying the complete quirks requires multiple steps: 1. Find which interface is used between the Bay Trail SoC and the ALC5640 codec chip, you already have audio working to some degree so you already have figured this out, your device is using the SSP0 AIF1 interface, where as the kernel defaults to SSP0 AIF2 on your device, which is why you need to specify the 5 as the first (directly after the 0x) digit of the quirk=0x503430 value which you are specifying. 2. Specify if your device has 1 or 2 speakers, looking at pictures of it, it has 2 downward firing speakers, which means that the 0 after the 5 as in 0x50.... is also correct. 3. Figure out how the internal mic is connected, you've also already done this, you r device is using DMIC1, this is the last 0 in the 0x503430 quirk which you are specifying. 4. Get jack-detect to work. This is primarily controlled by the second-to-last digit: 0x....3. which atm is 3 as printed by the "quirk realtek,jack-detect-source 3" message in dmesg. AFAICT you have not tested this yet. To test this install evemu and then run "sudo evemu-record" and select the 5640 jack device. After this plug in a pair of headphones or a headset, you should now see events about HEADPHONES and/or HEADPHONES + a MIC being plugged in. If you see these events everything is working as it should. If you don't see these events try changing the 3 to a 2, resulting in a quirk of: 0x503420 . Bonus points if you have both a headset and headphones and you can check that the jack-detect code properly differentiates the 2 (at least most of the times, sometimes you need to replug a headset if the mic part did not get detected, this is unavoidable). So once you've also got jack-detect working, it is time to add a patch to the kernel to use these settings automatically on your tablet model. Do do this I need to have the DMI strings of your device which we use to identify specific models. Please as a normal user run: grep . /sys/class/dmi/id/* 2> /dev/null And copy and paste the output here.
I finally got around to poking at this issue again. I'm terribly sorry for taking so long. Adding the kernel command line quirk "snd_soc_sst_bytcr_rt5640.quirk=0x503430" seems to have completely solved the issue I have. However sound and microphone is a little choppy sometimes. I think that's more to do with pipewire still. I have a pair of headphones with in-line mic and it switches to that just fine including recording from the in-line mic. So it seems to deal with everything as expected switching between internal and external speakers. Testing the left and right audio channels works as expected too for the external speakers and headphones. Below is what I got from the requested information of my tablet. grep . /sys/class/dmi/id/* 2> /dev/null /sys/class/dmi/id/bios_date:10/16/2015 /sys/class/dmi/id/bios_release:15.34 /sys/class/dmi/id/bios_vendor:Insyde /sys/class/dmi/id/bios_version:F.22 /sys/class/dmi/id/board_asset_tag:Type2 - Board Asset Tag /sys/class/dmi/id/board_name:8048 /sys/class/dmi/id/board_serial:PFHDT00WB170BE /sys/class/dmi/id/board_vendor:Hewlett-Packard /sys/class/dmi/id/board_version:N/A /sys/class/dmi/id/chassis_asset_tag:Chassis Asset Tag /sys/class/dmi/id/chassis_serial:Chassis Serial Number /sys/class/dmi/id/chassis_type:11 /sys/class/dmi/id/chassis_vendor:Hewlett-Packard /sys/class/dmi/id/chassis_version:Chassis Version /sys/class/dmi/id/ec_firmware_release:0.0 /sys/class/dmi/id/modalias:dmi:bvnInsyde:bvrF.22:bd10/16/2015:br15.34:efr0.0:svnHewlett-Packard:pnHPProTablet408:pvr0979100000405F00000330107:rvnHewlett-Packard:rn8048:rvrN/A:cvnHewlett-Packard:ct11:cvrChassisVersion:skuL4A36UT#ABA: /sys/class/dmi/id/product_family:103C_5336AN G=N L=SMB B=HP S=408 /sys/class/dmi/id/product_name:HP Pro Tablet 408 /sys/class/dmi/id/product_serial:5CG62409CJ /sys/class/dmi/id/product_sku:L4A36UT#ABA /sys/class/dmi/id/product_uuid:c9dd1648-16ef-4dfe-9c89-b740b94acb8a /sys/class/dmi/id/product_version:0979100000405F00000330107 /sys/class/dmi/id/sys_vendor:Hewlett-Packard /sys/class/dmi/id/uevent:MODALIAS=dmi:bvnInsyde:bvrF.22:bd10/16/2015:br15.34:efr0.0:svnHewlett-Packard:pnHPProTablet408:pvr0979100000405F00000330107:rvnHewlett-Packard:rn8048:rvrN/A:cvnHewlett-Packard:ct11:cvrChassisVersion:skuL4A36UT#ABA:
Oh one extra question. Are you also saying the in-line remote should work too? Currently pressing the single button on the in-line remote my pair of earphones has doesn't do anything with currently playing music although Gnome shows the media controls for it in the notification center.
The aforementioned choppy audio seems to only occur if a application like "pavucontrol" is open, audio otherwise sounds good.
(In reply to Lance G. from comment #15) > Oh one extra question. Are you also saying the in-line remote should work > too? Currently pressing the single button on the in-line remote my pair of > earphones has doesn't do anything with currently playing music although > Gnome shows the media controls for it in the notification center. The in-line remote should send play/pause events in evemu-record when you select the rt5640 device in evemu-record. If these events are present in evemu-record, then from the kernel side everything is working as it should.
As for the choppy ausio, these devices have somewhat underpowered CPUs so sometimes you may get buffer underruns, so this unfortunately is somewhat normal.
I've submitted a patch upstream to automatically apply the right quirk settings on the Hp Pro Tablet 408 from now on: https://lore.kernel.org/alsa-devel/20220427134918.527381-1-hdegoede@redhat.com/